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 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
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.
"- 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?
The tool is probably for decrypting the passwords. The Passwords are probably hashed for verification to their website, etc, and then encrypted to a key which is encrypted to each tech's password as they hire new techs.
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.
Anyone that's ever logged into their control panel knows the control panel can show you your password with a button click.
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.)
Oh, it's atrocious to give employees access to your passwords, if not unforgivable. However, if we're going to challenge the big guys like Rackspace, we have to do it without making unfounded accusations.
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 password to one of my boxes.
And, BTW, Softlayer does ask for your machine's root password in their support ticket form.
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 more room for such errors.
Seems similar to http://news.ycombinator.com/item?id=1148328. The internals of any VPS aren't really secure from the hosting provider, although I don't why that means CSRs should have plaintext access to the root password.
Does the author of this article not know about 2-way encryption? It can be used to store encrypted passwords in a database and the original value can be retrieved.
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.
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 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.
1password uses 128-bit AES, based on your master password. Intelligently, they didn't write their own encryption.
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 used a password manager, and I have a different password for every single service that I'm signed onto.
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.
You could use a password scheme for sites you don't really care much about and stronger separate passwords for important and often used sites.
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.
While the idea that Rackspace, a hardware and VM hosting provider, is really jeopardizing customers with passwords is pretty silly, it's still mostly a myth that you can use "2-way encryption" to securely store passwords in a database.
Anything the good guys can do to decrypt a password, assume the bad guys can too.
The change password code could also encrypt it in two places - a one-way hash all systems can read for authentication purposes and a second, through one-way link (think crippled RS-232), that stores it in a way only the second system, the one that has no network access, can retrieve using its secret (embedded in hardware) ludicrously large key and only after being enabled by a certain user action and proper multi-human authorization.
But it doesn't matter how ridiculously complex the password recovery system is, allowing meatware to gain access to passwords is a no-no.
Ironically, I was just now on the phone on-hold with Rackspace waiting to activate my account, when I tabbed over to HN to see this post at the #1 spot. I tipped off the customer rep that they might want to come on over to HN and reply. Looking forward to seeing how they officially respond...
It's disconcerting to hear that a CSR can see this. But, the bottom line is that a hosting company's quality is typically inversely proportional to their size. After a certain number of customers, the company's main business is automating hosting support and maintenance for the masses.
Gigenet.com stores the passwords in clear text. You can see this in their support system HTML source. You have to supply the root password each time you create a support ticket and the password remains visible even in closed tickets from months ago.
"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."
They may have been a RS customer for a while, but they are nonetheless mistaken: at least for Cloud customer service, they can see your account password, and with that password anyone can log into your account, change your contact information, and change your server root passwords.
They would need to be able to see passwords to login to your server to fix stuff anyway, unless you'd prefer for them to backdoor every machine they install with their ssh key. What's the big deal here?
My favorite cheap PHP host is Bluehost. I like everything about them except that they ask for passwords over the phone, and mention that every time I talk to them. Not only is a secure password a pain to say over the phone ("amersand backslash carrot capital-H comma...") but I don't like the idea of a disgruntled employee trying out the same password on my email accounts, even if I don't use the same password.
- 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.