Ask HN:Benefits Of Storing Passwords In Plain Text?
4 comments
I've been surprised by how poorly users in general deal with password resets rather than sending the password in plain text. Our website does password resets, and while it works reliably, and is roughly the same as any other password reset form (give it your username or email address, check email, click link; it's the standard Drupal password reset form, which is used by thousands of sites). Nonetheless, about once a week, I get an email from a user that can't figure it out; usually the reset email got filtered, but sometimes they just won't go through the form to reset their password...they'd rather send off an email to support@.
I don't understand it, but it definitely happens. So, maybe the folks who are choosing to save passwords in plain text are accepting the tradeoff in order to avoid having to answer as many support emails.
We actually save plain text passwords within our management apps for a few circumstances; but not for emailing to users and never on world-facing web applications. We offer the user the ability to use passwords in place of SSH keys for hooking up to managed systems in our cloud computing management product and in our cluster modules (though we generally recommend keys and SSL certificates); we also store MySQL passwords on behalf of users so they can manage their own databases from the control panel (this is akin to having MySQL passwords stored in configuration files for web apps, though it's a bit safer since only root can read them directly from the file system). Our webmail client stores user passwords for authenticating to IMAP/POP3 services (much like Thunderbird or Outlook do, only we do it server-side). So, it isn't "benefits" per se, in our case, it's that there's functionality that users want that can be done no other way. They could be two-way hashed, but if an attacker has obtained root, they would have access to the key needed to decrypt the hashed passwords, anyway, so it seems pretty silly to pretend like something is encrypted if the attacks needed to be able to access the plain text would also grant access to the keys for decrypting.
I don't understand it, but it definitely happens. So, maybe the folks who are choosing to save passwords in plain text are accepting the tradeoff in order to avoid having to answer as many support emails.
We actually save plain text passwords within our management apps for a few circumstances; but not for emailing to users and never on world-facing web applications. We offer the user the ability to use passwords in place of SSH keys for hooking up to managed systems in our cloud computing management product and in our cluster modules (though we generally recommend keys and SSL certificates); we also store MySQL passwords on behalf of users so they can manage their own databases from the control panel (this is akin to having MySQL passwords stored in configuration files for web apps, though it's a bit safer since only root can read them directly from the file system). Our webmail client stores user passwords for authenticating to IMAP/POP3 services (much like Thunderbird or Outlook do, only we do it server-side). So, it isn't "benefits" per se, in our case, it's that there's functionality that users want that can be done no other way. They could be two-way hashed, but if an attacker has obtained root, they would have access to the key needed to decrypt the hashed passwords, anyway, so it seems pretty silly to pretend like something is encrypted if the attacks needed to be able to access the plain text would also grant access to the keys for decrypting.
Indeed. It's worth emphasizing that this feature (password encryption) has a real cost in terms of usability. Remember that for every user who emails you asking for their password, there's several that didn't bother and just went somewhere else.
I get the feeling password encryption is a feature that's mostly implemented as appeasement (if you do send passwords in clear, every once in a while you will get someone mailing you about it, and most of those people have blogs so you can't brush them off or ignore them, unless you like negative publicity).
I get the feeling password encryption is a feature that's mostly implemented as appeasement (if you do send passwords in clear, every once in a while you will get someone mailing you about it, and most of those people have blogs so you can't brush them off or ignore them, unless you like negative publicity).
First of all, just because they email you your password doesn't mean they store it in plain text. It could be reversibly encrypted.
Conversely, just because they email you a password reset link, doesn't mean they encrypt your password. It could still be stored in plain text.
"Development" doesn't exist in isolation. You can't look at just the "development benefits", you have to look at the "product benefits".
The product benefit of storing a password with reversible encryption is obvious: a simplified "forgot password" feature. If your users are all hardcore geeks, that's not much use, but if you have many users who are not very tech-savvy, that can make a pretty big difference. After all, if a user can't figure out how to log on to the site because they are too confused to use the reset password link, you've lost that user - and for all you know, maybe that user is a 60-year-old director at a potentially huge client of yours, who then will decide not to bother with your product because he can't log in.
The question you might also ask, perhaps, is whether there is a real security benefit to you if the site you're using does encrypt your password non-reversibly. Assuming that the people running the site are honest, the benefit there would be that if someone hacks into that provider, they won't get the password that you use for all your other accounts on the web.
My answer to that would be: if you use the same password for multiple service, you have no business getting all uppity about password encryption policy, because the security failure is you. If you care about security, use a different password for each service (a tool like 1Password makes that process easy). If you don't use a different password for each service, don't complain about security. I wish more people would realise the inherent hypocrisy of complaining that "you should encrypt my password because I use the same password on many sites". Fewer sites would have to encrypt passwords to appease those users.
Conversely, just because they email you a password reset link, doesn't mean they encrypt your password. It could still be stored in plain text.
"Development" doesn't exist in isolation. You can't look at just the "development benefits", you have to look at the "product benefits".
The product benefit of storing a password with reversible encryption is obvious: a simplified "forgot password" feature. If your users are all hardcore geeks, that's not much use, but if you have many users who are not very tech-savvy, that can make a pretty big difference. After all, if a user can't figure out how to log on to the site because they are too confused to use the reset password link, you've lost that user - and for all you know, maybe that user is a 60-year-old director at a potentially huge client of yours, who then will decide not to bother with your product because he can't log in.
The question you might also ask, perhaps, is whether there is a real security benefit to you if the site you're using does encrypt your password non-reversibly. Assuming that the people running the site are honest, the benefit there would be that if someone hacks into that provider, they won't get the password that you use for all your other accounts on the web.
My answer to that would be: if you use the same password for multiple service, you have no business getting all uppity about password encryption policy, because the security failure is you. If you care about security, use a different password for each service (a tool like 1Password makes that process easy). If you don't use a different password for each service, don't complain about security. I wish more people would realise the inherent hypocrisy of complaining that "you should encrypt my password because I use the same password on many sites". Fewer sites would have to encrypt passwords to appease those users.
Are there any major benefits to storing a password in plain text (from a development standpoint)?
Not unless you want to use your users' passwords to impersonate them on other sites... or to allow anyone who breaks into your servers to do the same.
Don't use MD5 either -- that's far too weak. Use a real key derivation function: Ideally scrypt, but failing that, bcrypt or PBKDF2.
Not unless you want to use your users' passwords to impersonate them on other sites... or to allow anyone who breaks into your servers to do the same.
Don't use MD5 either -- that's far too weak. Use a real key derivation function: Ideally scrypt, but failing that, bcrypt or PBKDF2.
From a development standpoint, no. But I used to work for a company that did this because they wanted to make it as easy as possible for their users to recover their passwords... by emailing it to them...
If an app seems sketchy to me in this regard I use a non-standard password and then do a password request to see how this is handled. Most of the time I will get emailed a link to reset my password but more often than I had expected I'm just getting my password emailed to me. (of course I understand getting a reset link doesn't necessarily mean the password is encrypted either)
This happened today with the new version of Hootsuite.com - I forgot I had an account and when I filled in the 'forgot password' form I got an email with one line "Password: XXXXXXXXX'
From all work I've done and developers I've talked with it's best to use some kind of protection on the passwords - even if it's just md5'ing it. Are there any major benefits to storing a password in plain text (from a development standpoint)?