31–40 of 41 posts
No matter the policy or level of security behind internal tools, it still potentially can leave more room for such errors.
I asked a Rackspace rep about this. Here is the real deal: - passwords are NOT stored in cleartext - however, passwords are visible to customer service via a "secure, non-public tool" - the reason for this is because "people generally prefer to give out a password to authenticate themselves [over the phone] than portions of the billing information" - so if a user account database is stolen somehow, the malicious thie…
"- however, passwords are visible to customer service via a "secure, non-public tool"" "- so if a user account database is stolen somehow, the malicious thief would not have access to convenient info like email/username/cleartext password." What if the secure, non-public tool is also stolen?
Earlier quoted context omitted.
Good idea in theory. Unfortunately every serious person doing programming / administration / ... will have at least 20 accounts on the internet (probably underestimated!: email, other email, HN, sourceforge, github, facebook, own pc, own pc admin, vps, stackoverflow, etc. etc.) At some point it's not possible to remember them all anymore... You have a choice of storing them with master password (now I can get all of…
...or... writing a simple script that given a key, generates you a password based on it. I probably have 50+ passwords at least, and every one is different. I just run my little script with a "key" and it tells me the password. And of course browsers remember them anyway. eg ./get_my_password.sh mygmail ./get_my_password.sh server_1_mysql_root I think 1password etc do similar things though.
Of course, we wanted to avoid writing this code in the Agile Keychain and elected to use the OpenSSL function PKCS5_PBKDF2_HMAC_SHA1 to generate the keys. Key generation is simply too important a step to not rely directly on the experts. In order to thwart would-be attackers and strengthen the key, we elected to use 1000 iterations in the PBKDF2 algorithm.
"I've been a rackspace customer for a while, and I've only ever used that password to verify my identity over the phone. A different password is used to log into the web interface to access data and tickets."
It's a verification phrase, not a password.
First off, Rackspace's cloud services has totally different CS staff than their managed hosting services. I'm a managed customer and this has never happened. In fact, I had to deal with their cloud CS people regarding a DNS issue and got the run around. Anyway, the managed folks ask for your portal password and a challenge question (high school mascot). In the 4 years I've used them, they have never asked for a root…
Read the comments there: "I've been a rackspace customer for a while, and I've only ever used that password to verify my identity over the phone. A different password is used to log into the web interface to access data and tickets." It's a verification phrase, not a password.
Reminds me of an incident I had with my account at NeSol some years ago. I used to get promotional cards in the mail from them, always in pairs, one addressed to my login account name and the other addressed to my password. It seemed inconceivable and I could never get them to actually believe me, even with scanned proof. No matter the policy or level of security behind internal tools, it still potentially can leave…
Earlier quoted context omitted.
Letting a random employee to see your password on demand is just as bad as storing it in plaintext. Now the employee knows you and knows your password - for most people that means free access to their mail account, which means free access to all their accounts.
security 101 - use different passwords for everything.