

Ask HN:Benefits Of Storing Passwords In Plain Text? - mikeyur

I don't know what's been going on lately but I'm finding that more and more webapps are just storing my password in plain text.<p>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)<p>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'<p>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)?
======
SwellJoe
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.

~~~
swombat
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).

------
swombat
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.

------
cperciva
_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.

------
bdmac97
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...

