Most people are arguing that a password shouldn't ever be recoverable and that "even root level access should not grant you passwords".
This feels like shaky logic though. Hashing is a good defence against DB harvesting but it doesn't stop a root level admin from listening to inbound unencrypted logins. Prolonged root access is therefore still a viable attack vector. The question is only how quickly you can harvest those passwords.
Other people are arguing that with sufficient decoupling and safeguards between the encryption key and the database there is an acceptable risk associated with storing a password.
Since services like Yodlee clearly do store passwords this is something that companies do address. Could someone who really knows this area well please describe how this is done in a way to minimise risk and how the risk compares to a traditional 1-way hashing?
What I find interesting about the debate regarding password storage ethics is the question, "What is a website's ethical responsibility in regards to a user's password?"
On the face of it, one could argue that the extent of a site's ethical responsibility ends at their IP address -- i.e. a site is only responsible for protecting one's password to the extent that it reasonably protects the user from harm resulting from someone else using their credentials on the site. For example, under this scenario, HN's responsibility would be to take reasonable steps to protect my password in accordance with the level of harm I would experience should my account be compromised. HN's "reasonable steps" are different from those of Bank of America, and emailing my password in plaintext would not shock me (even if unlikely).
However, there is a tendency for people to argue that the extent of a site's ethical responsibility is to protect the user from harm elsewhere on the internet - the logic of course being that many people use the same password for HN and BOA. In some sense, this argument is premised on websites having some level responsibility for general welfare of their users (i.e. a website's responsibility towards users extends across the entire internet to some degree).
A weakness of that argument is that once general welfare of the user is the standard, plaintext storage of a password may promote the user's general welfare to a greater extent than more secure measures - security is just one criteria in regards to utility. A house with few windows is usually more secure but often less healthy for its occupants.
Although technical considerations are important, the issues surrounding password security methods for most sites are social: trivial passwords, password reuse, and "lost" passwords. Holding all sites to the standards which apply to sites with fiduciary responsibility such as banks or corporate IT centers is, in my opinion, somewhat asinine. Every web service does not need to be locked down, and good architecture will balance security with commodity and delight.
How do people try to justify storing passwords in recoverable form? So that they can remind users of the old password.
How do they actually send the reminder? By email.
But email is not secure, you should always assume that someone is eavesdropping on your email. Far too many users reuse a password from one service on others, so sending a password in email is a huge violation of trust.
> Hashing is a good defence against DB harvesting but it doesn't stop a root level admin from listening to inbound unencrypted logins.
Forgive my ignorance of web authentication, but aren't passwords hashed in the browser before being sent to the server for authentication?
If not, why? It seems to me that it would be just as easy to hash on the browser side as on the server side, but passwords are less exposed if you do it on the browser side.
(Apologies for hijacking your thread, but I'm interested in the technical details here.)
For the vast majority of sites storing passwords in the clear is a bad idea.
However sometimes you need to store sensitive data. Generally this is done with hardware security modules which rotate encryption keys in a periodic basis. Access to the sensitive data is also audited.
Risk can be minimized. It just comes down to if it is worth if for your business. PCI DSS is just one example of minimizing risk.
I can't believe that this is still common practice in some large-scale businesses. In my imagination of a perfect world I would never get in touch with a user's plain text password at all.
It's never (almost) acceptable to be storing a users password in plaintext or encrypted. Time and time again we see this and I'm glad most of the time there is public outcry and the developers mostly respond with some variant of "We're using <buzzword> now!".
The day we move away from simple username password authentication as a whole is the day I can start feeling safe about my online accounts. Until that day there will always be the one crypto 'expert' attempting to dissuade the angry masses with his custom XES scheme which is super secure due to high amount of buzziness.
Being able to provide you with your password in plain text doesn't mean it's stored in plain text. There are very efficient and secure encryption algorithms that are reversible, out there.
Of course, sending passwords in an unencrypted email is bad practice, but that's another story.
'plain text' here includes encrypted non-hashed formats. Passwords should always be stored hashed so the original site (or any attacker who gets them) can get access to the password.
And if it's possible to automatically reverse the encryption, then it's not far off plain text.
What do you mean by secure encryption algorithms which are reversible? Encryption implies an operation in reverse order to exist, otherwise it is in essence, digesting.
It's always (almost) completely unnecessary to store encrypted passwords.
While it's possible that this is true, it's still exceptionally bad practice. Reversible encryption, particularly when stored server-side, which is almost always going to be the case, and even if using a HSM, isn't entirely different from plaintext when the attacker holds the keys.
Had a similar experience with Dreamhost about 2 years ago. I sent them an email pointing out the insecurity of sending passwords in an unencrypted email, but they seemed to feel that their customers "appreciated" the ease of password recovery over security.
I remember reading an idea of a "login via email" link. This would be probably be even more convenient than a password reminder and just as secure as a reset link (assuming it only works once and has a time limit).
Exactly, as the admin you see a potential vulnerability, as the end user, you just don't want to remember a password and as an attacker, you see an opportunity.
They can still have some kind of encryption algorithm in place to encrypt/decrypt passwords in their database. That said, sending the passwords out in plain-text via Email isnt particularly secure either.
As was discussed here over and over: That basically results in the same thing.
There should be no feasible way to read the passwords of your users, ever. If you store them 'secure' in a reversible way it doesn't matter much if you use rot13 or state of the art crypto. Anyone getting access to the database can probably get the key as well.
While sending passwords in plain text via e-mail is something that should be frowned upon, the e-mail itself is not evidence that they store your password in plain text.
How about playing the devils advocate. How many people here own homes without a security system or don't use that system every day? It can be a pain turning the system off and on every time you leave the house.
If you were in the physical security business and knew of all the violence that occurs in society you would think it's crazy to not own a security system and not use it every day.
Now put yourself in the shoes of a non technical person and you can see how convenience sometimes trumps security.
Sidenote: I love asking people in the computer security business about what kind of physical security system they use at home. Most don't use one.
The reasons these are not the least bit comparable are
a) Economies of scale - breaking into houses happens one at a time. Breaking into unsecured computer systems often lets you affect millions of people at once.
b) Jurisdiction - if a thief breaks into your house, he's local, and your cops can find and prosecute him. With computers, this is almost never true.
c) Personal Choice - You can choose whether or not to use an alarm in your home. When you use somebody's service, you have no choice over whether they use a level of security you agree with.
d) Personal Impact - When you choose to use an alarm in your home or not, that is a decision that affects -you-. When a service chooses to be insecure or not, that is a decision that affects -their customers-.
In short, they are nowhere near equivalent. If you want to make decisions for yourself on convenience vs security, that's cool, but don't equate that to a company making decisions on behalf of their customers.
This is not a good analogy -- a more apt comparison to a network admin not taking correct precautions with user data is a storage facility not activating it's security system every day. These organizations are dealing with other people's security, not just their own.
The worst thing that can happen here is that somebody connects to your wifi. If someone can read your email and is in the vicinity to connect to your wifi, the least of your problems is that he or she does connect to your wifi.
Also, as pointed out by others, this doesn't mean it's stored in plain text. Any time you set a password it travels in plain text (typically - and hopefully - via a secure connection) and it arrives to their server in plain text. You are never sure they are immediately storing it properly encrypted in a DB. They can also be doing things like sending it in emails or storing it elsewhere. If you cannot trust your password to whoever is storing it you are basically f*ed. BTW, what do you think they might do whenever you enter the wrong password in the wrong site? (for instance, your email password).
Garbage. The problem is not the transport-layer security. Transport-layer attacks are very difficult to implement. What is risky is what happens when someone gets access to the database and does "SELECT * FROM user". This is a very realistic threat, and with properly hashed passwords, gives an attacker no useful information. With plain-text passwords, though, they now have carte blanche to try the credentials at other sites, and steal someone's entire identities.
Yes, it's bad if you use the same password everywhere. Yes, it's bad if someone man-in-the-middles you. Yes, it's bad that arbitrary web users can run arbitrary database queries. But the point of robust engineering is to protect a system from many failures. If your passwords are stored in cleartext, your system is less safe overall than one that stores the passwords hashed. And because it's so easy to hash passwords, and because it's so damaging to your users to leak their password, it's generally considered Pretty Fucking Incompetent to keep passwords around in cleartext.
The worst thing that can happen here is that somebody connects to your wifi.
Unless a negligible amount of the 4 million users accidentally reused the password for other services as well. Which probably makes 3.9 million victims.
Also, as pointed out by others, this doesn't mean it's stored in plain text.
That does not matter much. If FON can extract it, an attacker can extract it as well, thus rendering it insecure.
> The worst thing that can happen here is that somebody connects to your wifi.
No, the worst thing that can happen is that someone you trust uses the same password for this service and their google account, then the attacker who hates you uses their latitude access to find where your kids are and kidnaps them for money.
Sorry... went to far. A more sane version is: someone uses the same password for their {online retailer} account. Attacker uses that to login and buy themselves a $X000 present using your saved CC details.
[+] [-] petenixey|14 years ago|reply
This feels like shaky logic though. Hashing is a good defence against DB harvesting but it doesn't stop a root level admin from listening to inbound unencrypted logins. Prolonged root access is therefore still a viable attack vector. The question is only how quickly you can harvest those passwords.
Other people are arguing that with sufficient decoupling and safeguards between the encryption key and the database there is an acceptable risk associated with storing a password.
Since services like Yodlee clearly do store passwords this is something that companies do address. Could someone who really knows this area well please describe how this is done in a way to minimise risk and how the risk compares to a traditional 1-way hashing?
[+] [-] brudgers|14 years ago|reply
What I find interesting about the debate regarding password storage ethics is the question, "What is a website's ethical responsibility in regards to a user's password?"
On the face of it, one could argue that the extent of a site's ethical responsibility ends at their IP address -- i.e. a site is only responsible for protecting one's password to the extent that it reasonably protects the user from harm resulting from someone else using their credentials on the site. For example, under this scenario, HN's responsibility would be to take reasonable steps to protect my password in accordance with the level of harm I would experience should my account be compromised. HN's "reasonable steps" are different from those of Bank of America, and emailing my password in plaintext would not shock me (even if unlikely).
However, there is a tendency for people to argue that the extent of a site's ethical responsibility is to protect the user from harm elsewhere on the internet - the logic of course being that many people use the same password for HN and BOA. In some sense, this argument is premised on websites having some level responsibility for general welfare of their users (i.e. a website's responsibility towards users extends across the entire internet to some degree).
A weakness of that argument is that once general welfare of the user is the standard, plaintext storage of a password may promote the user's general welfare to a greater extent than more secure measures - security is just one criteria in regards to utility. A house with few windows is usually more secure but often less healthy for its occupants.
Although technical considerations are important, the issues surrounding password security methods for most sites are social: trivial passwords, password reuse, and "lost" passwords. Holding all sites to the standards which apply to sites with fiduciary responsibility such as banks or corporate IT centers is, in my opinion, somewhat asinine. Every web service does not need to be locked down, and good architecture will balance security with commodity and delight.
[+] [-] jedbrown|14 years ago|reply
How do they actually send the reminder? By email.
But email is not secure, you should always assume that someone is eavesdropping on your email. Far too many users reuse a password from one service on others, so sending a password in email is a huge violation of trust.
[+] [-] pingswept|14 years ago|reply
Forgive my ignorance of web authentication, but aren't passwords hashed in the browser before being sent to the server for authentication?
If not, why? It seems to me that it would be just as easy to hash on the browser side as on the server side, but passwords are less exposed if you do it on the browser side.
(Apologies for hijacking your thread, but I'm interested in the technical details here.)
[+] [-] jtchang|14 years ago|reply
However sometimes you need to store sensitive data. Generally this is done with hardware security modules which rotate encryption keys in a periodic basis. Access to the sensitive data is also audited.
Risk can be minimized. It just comes down to if it is worth if for your business. PCI DSS is just one example of minimizing risk.
[+] [-] ch0wn|14 years ago|reply
[+] [-] dekz|14 years ago|reply
The day we move away from simple username password authentication as a whole is the day I can start feeling safe about my online accounts. Until that day there will always be the one crypto 'expert' attempting to dissuade the angry masses with his custom XES scheme which is super secure due to high amount of buzziness.
[+] [-] JTxt|14 years ago|reply
I first reported a similar issue to Rackspace Cloud 2/2/2010:
http://feedback.rackspacecloud.com/forums/71021-product-feed...
They still email new vps ROOT passwords with IP addresses. (At least they said they would fix it about 2 months ago.)
Perhaps there's not enough people that are bothered by this? There is this site: http://plaintextoffenders.com/
[+] [-] Nicolas___|14 years ago|reply
Of course, sending passwords in an unencrypted email is bad practice, but that's another story.
[+] [-] rmc|14 years ago|reply
And if it's possible to automatically reverse the encryption, then it's not far off plain text.
[+] [-] madflo|14 years ago|reply
[+] [-] dekz|14 years ago|reply
It's always (almost) completely unnecessary to store encrypted passwords.
[+] [-] davidu|14 years ago|reply
[+] [-] johnnygoods|14 years ago|reply
[+] [-] unknown|14 years ago|reply
[deleted]
[+] [-] simonbrown|14 years ago|reply
[+] [-] agilebyte|14 years ago|reply
[+] [-] kayoone|14 years ago|reply
[+] [-] darklajid|14 years ago|reply
There should be no feasible way to read the passwords of your users, ever. If you store them 'secure' in a reversible way it doesn't matter much if you use rot13 or state of the art crypto. Anyone getting access to the database can probably get the key as well.
[+] [-] pr0filer_|14 years ago|reply
[+] [-] gokhan|14 years ago|reply
[+] [-] Kesty|14 years ago|reply
Still not the best solution, hashed password (with a salt) are way more secure if your password happens to be 12345.
[+] [-] alvarosm|14 years ago|reply
[+] [-] tsycho|14 years ago|reply
[+] [-] va_coder|14 years ago|reply
If you were in the physical security business and knew of all the violence that occurs in society you would think it's crazy to not own a security system and not use it every day.
Now put yourself in the shoes of a non technical person and you can see how convenience sometimes trumps security.
Sidenote: I love asking people in the computer security business about what kind of physical security system they use at home. Most don't use one.
[+] [-] pkteison|14 years ago|reply
a) Economies of scale - breaking into houses happens one at a time. Breaking into unsecured computer systems often lets you affect millions of people at once.
b) Jurisdiction - if a thief breaks into your house, he's local, and your cops can find and prosecute him. With computers, this is almost never true.
c) Personal Choice - You can choose whether or not to use an alarm in your home. When you use somebody's service, you have no choice over whether they use a level of security you agree with.
d) Personal Impact - When you choose to use an alarm in your home or not, that is a decision that affects -you-. When a service chooses to be insecure or not, that is a decision that affects -their customers-.
In short, they are nowhere near equivalent. If you want to make decisions for yourself on convenience vs security, that's cool, but don't equate that to a company making decisions on behalf of their customers.
[+] [-] jiaaro|14 years ago|reply
[+] [-] muyuu|14 years ago|reply
The worst thing that can happen here is that somebody connects to your wifi. If someone can read your email and is in the vicinity to connect to your wifi, the least of your problems is that he or she does connect to your wifi.
Also, as pointed out by others, this doesn't mean it's stored in plain text. Any time you set a password it travels in plain text (typically - and hopefully - via a secure connection) and it arrives to their server in plain text. You are never sure they are immediately storing it properly encrypted in a DB. They can also be doing things like sending it in emails or storing it elsewhere. If you cannot trust your password to whoever is storing it you are basically f*ed. BTW, what do you think they might do whenever you enter the wrong password in the wrong site? (for instance, your email password).
[+] [-] jrockway|14 years ago|reply
Yes, it's bad if you use the same password everywhere. Yes, it's bad if someone man-in-the-middles you. Yes, it's bad that arbitrary web users can run arbitrary database queries. But the point of robust engineering is to protect a system from many failures. If your passwords are stored in cleartext, your system is less safe overall than one that stores the passwords hashed. And because it's so easy to hash passwords, and because it's so damaging to your users to leak their password, it's generally considered Pretty Fucking Incompetent to keep passwords around in cleartext.
[+] [-] ge0rg|14 years ago|reply
Unless a negligible amount of the 4 million users accidentally reused the password for other services as well. Which probably makes 3.9 million victims.
Also, as pointed out by others, this doesn't mean it's stored in plain text.
That does not matter much. If FON can extract it, an attacker can extract it as well, thus rendering it insecure.
[+] [-] viraptor|14 years ago|reply
No, the worst thing that can happen is that someone you trust uses the same password for this service and their google account, then the attacker who hates you uses their latitude access to find where your kids are and kidnaps them for money.
Sorry... went to far. A more sane version is: someone uses the same password for their {online retailer} account. Attacker uses that to login and buy themselves a $X000 present using your saved CC details.