Rackspace passwords are visible to customer service
rondam.blogspot.com
rondam.blogspot.com
- 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 thief would not have access to convenient info like email/username/cleartext password. (However if a customer service rep is the bad guy, you're still in trouble since they have access to the tool.)
- at some point, Rackspace intends to "removing CSR access for SAS-70 purposes and moving to something like a challenge/response like the Managed division uses." AFAIK SAS-70 is some kind of audit regulation, but the wikipedia article put me to sleep after reading the first sentence.
- set a separate password for over-the-phone stuff
- N specified letters from the password are requested by the customer service (3 <= N << len(password))
- customer service puts them into the system and gets a yes/no response
I don't reveal the root password to the person, they get good enough proof that I know the over-the-phone secret.
Alternatively, set a separate phone password and just verify it against the hash. I don't see any excuse for anyone to know my root password in full.
Sorry, but I think this is the phone equivalent of insisting that you set a password using uppercase, lowercase, digits, symbols, at least 20 characters long and changing every 3 days. People are just going to start using obvious things or writing them down.
True story: A few months ago, I took out a new credit card. During the application process, including activating phone and Internet access, I was asked for something like sixteen different pieces of personal/security information. The first time I wanted to call them a few days later to check something was now ready, I was asked for my "pass code". I had no idea which of those pieces of information that was, so Call Centre Guy says not to worry, he can verify me via other details. He runs through a series of questions, at least one of which makes no sense in the circumstances (in fact, that was the reason I was calling). At the end, he says he's sorry but I've failed security and he has to hang up now. All he can say is that I haven't provided the required answer to all of the questions. I tried to go on-line, and was asked to enter some memorable information. Apparently, I gave them three different things during sign-up and any one of them would do. No doubt I chose someone's birthday, etc., but of course I had no idea who and there was no kind of prompt. So I couldn't get in over the Internet either. Finally, I gave up and went back into the branch, where the staff had been helpful and efficient while I was setting things up to start with. They called through to a special number... which transferred to the same call centre and resulted in the same series of security questions, even though I was sitting in a secure area of one of their branches, with an employee who had already authenticated themselves, and who had seen my passport and driving licence two minutes earlier (which means they had access to two photos, two signatures, and my current address as a minimum). I gave exactly the same answers I had given to the previous guy, explained in exactly the same way why one question didn't make sense, and was told that was fine and how could he help?
When I call my other credit card company, they ask for my six-digit DoB and typically my current credit limit to verify before doing anything significant.
My business account needs a single password for everything, and for extra security provides a device where you push a button to generate a six-digit code that changes every few seconds.
Two of these have the right approach. The one that uses separate security information for everything and all kinds of different types of validation is not one of them.
"- 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?
I'm sorry, I should say, this is how I imagine a good way to do it would be, not that it's how they do it.
This way though everything could be stolen and it wouldn't give up clear text passwords.
If you're a Rackspace customer, you trust them run your network fabric and your hardware. They don't need your password to see what you're doing, but you may as well trust them with that too.
Speaking of trust -- if your machine password gives a Rackspace CSR access to your app's private data, you're just as guilty as you're accusing them of being. You're not storing your private data in the clear, are you?
(As for why they might do this: Most users aren't sophisticated enough to use a password generator and manager, making "What's my password again?" a common support question. Providing the "Show me my password" function in the web control panel means a CSR doesn't have a job reason to look at it. And even if they do, cloud customers already trust Rackspace support with the reboot switch, and for that matter, with the "delete this whole image and all its backups" button.)
If you're using the same password for more than one account/login, then seriously, that's not a good idea. Don't do it. Ever.
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 password to one of my boxes.
And, BTW, Softlayer does ask for your machine's root password in their support ticket form.
No matter the policy or level of security behind internal tools, it still potentially can leave more room for such errors.
And if you're running code on someone else's hardware then they pretty much implicitly have access to all your stuff, password or not.
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 them in one file), using the same one, having a password scheme (like usualpwd_HN, usualpwd_gmail, ...) or ... ?
Edit: what I started doing is setting random password that I will not remember and just requesting a reset when I get logged out.
I do this and it works out well and if you use the important sites enough you will and do remember your strong passwords but for the ones you don't you always can reset your password by email which isn't that inconvenient if you think about how often you are accessing the website that you cannot remember your password.
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
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.
If you're using similar passwords for all the services you're signed onto, it's pure hypocrisy to turn around and criticise Rackspace for "poor security". The single point of failure is you.
But it doesn't matter how ridiculously complex the password recovery system is, allowing meatware to gain access to passwords is a no-no.
Anything the good guys can do to decrypt a password, assume the bad guys can too.
"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.
You: My password is "foo" Random person: Yes, that's exactly what the screen says.
Little do you know, there is no screen.