How should I ethically approach user password stor

Question

As I continue to build more and more websites and web applications I am often asked to store user's passwords in a way that they can be retrieved if/when the user has an issue (either to email a forgotten password link, walk them through over the phone, etc.) When I can I fight bitterly against this practice and I do a lot of ‘extra’ programming to make password resets and administrative assistance possible without storing their actual password.

When I can’t fight it (or can’t win) then I always encode the password in some way so that it, at least, isn’t stored as plaintext in the database—though I am aware that if my DB gets hacked it wouldn't take much for the culprit to crack the passwords, so that makes me uncomfortable.

In a perfect world folks would update passwords frequently and not duplicate them across many different sites—unfortunately I know MANY people that have the same work/home/email/bank password, and have even freely given it to me when they need assistance. I don’t want to be the one responsible for their financial demise if my DB security procedures fail for some reason.

Morally and ethically I feel responsible for protecting what can be, for some users, their livelihood even if they are treating it with much less respect. I am certain that there are many avenues to approach and arguments to be made for salting hashes and different encoding options, but is there a single ‘best practice’ when you have to store them? In almost all cases I am using PHP and MySQL if that makes any difference in the way I should handle the specifics.

Additional Information for Bounty

I want to clarify that I know this is not something you want to have to do and that in most cases refusal to do so is best. I am, however, not looking for a lecture on the merits of taking this approach I am looking for the best steps to take if you do take this approach.

In a note below I made the point that websites geared largely toward the elderly, mentally challenged, or very young can become confusing for people when they are asked to perform a secure password recovery routine. Though we may find it simple and mundane in those cases some users need the extra assistance of either having a service tech help them into the system or having it emailed/displayed directly to them.

In such systems the attrition rate from these demographics could hobble the application if users were not given this level of access assistance, so please answer with such a setup in mind.

Thanks to Everyone

This has been a fun question with lots of debate and I have enjoyed it. In the end I selected an answer that both retains password security (I will not have to keep plain text or recoverable passwords), but also makes it possible for the user base I specified to log into a system without the major drawbacks I have found from normal password recovery.

As always there were about 5 answers that I would like to have marked as correct for different reasons, but I had to choose the best one--all the rest got a +1. Thanks everyone!

Also, thanks to everyone in the Stack community who voted for this question and/or marked it as a favorite. I take hitting 100 up votes as a compliment and hope that this discussion has helped someone else with the same concern that I had.

Answer 1

What about emailing the plaintext password upon registration, before getting it encrypted and lost? I've seen a lot of websites do it, and getting that password from the user's email is more secure than leaving it around on your server/comp.

Answer 2

You could encrypt the password + a salt with a public key. For logins just check if the stored value equals the value calculated from the user input + salt. If there comes a time, when the password needs to be restored in plaintext, you can decrypt manually or semi-automatically with the private key. The private key may be stored elsewhere and may additionally be encrypted symmetrically (which will need a human interaction to decrypt the password then).

I think this is actually kind of similar to the way the Windows Recovery Agent works.

• Passwords are stored encrypted
• People can login without decrypting to plaintext
• Passwords can be recovered to plaintext, but only with a private key, that can be stored outside the system (in a bank safe, if you want to).

Answer 3

Michael Brooks has been rather vocal about CWE-257 - the fact that whatever method you use, you (the administrator) can still recover the password. So how about these options:

1. Encrypt the password with someone else's public key - some external authority. That way you can't reconstruct it personally, and the user will have to go to that external authority and ask to have their password recovered.
2. Encrypt the password using a key generated from a second passphrase. Do this encryption client-side and never transmit it in the clear to the server. Then, to recover, do the decryption client-side again by re-generating the key from their input. Admittedly, this approach is basically using a second password, but you can always tell them to write it down, or use the old security-question approach.

I think 1. is the better choice, because it enables you to designate someone within the client's company to hold the private key. Make sure they generate the key themselves, and store it with instructions in a safe etc. You could even add security by electing to only encrypt and supply certain characters from the password to the internal third party so they would have to crack the password to guess it. Supplying these characters to the user, they will probably remember what it was!

Answer 4

Just came across this interesting and heated discussion. What surprised me most though was, how little attention was payed to the following basic question:

• Q1. What are the actual reasons the user insists on having access to plain text stored password? Why is it of so much value?

The information that users are elder or young does not really answer that question. But how a business decision can be made without proper understanding customer's concern?

Now why it matters? Because if the real cause of customers' request is the system that is painfully hard to use, then maybe addressing the exact cause would solve the actual problem?

As I don't have this information and cannot speak to those customers, I can only guess: It is about usability, see above.

Another question I have seen asked:

• Q2. If user does not remember the password in first place, why does the old password matter?

And here is possible answer. If you have cat called "miaumiau" and used her name as password but forgot you did, would you prefer to be reminded what it was or rather being sent something like "#zy*RW(ew"?

Another possible reason is that the user considers it a hard work to come up with a new password! So having the old password sent back gives the illusion of saving her from that painful work again.

I am just trying to understand the reason. But whatever the reason is, it is the reason not the cause that has to be addressed.

As user, I want things simple! I don't want to work hard!

If I log in to a news site to read newspapers, I want to type 1111 as password and be through!!!

I know it is insecure but what do I care about someone getting access to my "account"? Yes, he can read the news too!

Does the site store my "private" information? The news I read today? Then it is the site's problem, not mine! Does the site show private information to authenticated user? Then don't show it in first place!

This is just to demonstrate user's attitude to the problem.

So to summarize, I don't feel it is a problem of how to "securely" store plain text passwords (which we know is impossible) but rather how to address customers actual concern.

Answer 5

How about a halfway house?

Store the passwords with a strong encryption, and don't enable resets.

Instead of resetting passwords, allow sending a one-time password (that has to be changed as soon as the first logon occurs). Let the user then change to whatever password they want (the previous one, if they choose).

You can "sell" this as a secure mechanism for resetting passwords.

Answer 6

You can not ethically store passwords for later plaintext retrieval. It's as simple as that. Even Jon Skeet can not ethically store passwords for later plaintext retrieval. If your users can retrieve passwords in plain text somehow or other, then potentially so too can a hacker who finds a security vulnerability in your code. And that's not just one user's password being compromised, but all of them.

If your clients have a problem with that, tell them that storing passwords recoverably is against the law. Here in the UK at any rate, the Data Protection Act 1998 (in particular, Schedule 1, Part II, Paragraph 9) requires data controllers to use the appropriate technical measures to keep personal data secure, taking into account, among other things, the harm that might be caused if the data were compromised -- which might be considerable for users who share passwords among sites. If they still have trouble grokking the fact that it's a problem, point them to some real-world examples, such as this one.

The simplest way to allow users to recover a login is to e-mail them a one-time link that logs them in automatically and takes them straight to a page where they can choose a new password. Create a prototype and show it in action to them.

Here are a couple of blog posts I wrote on the subject:

• http://jamesmckay.net/2009/09/if-you-are-saving-passwords-in-clear-text-you-are-probably-breaking-the-law/
• http://jamesmckay.net/2008/06/easy-login-recovery-without-compromising-security/

Update: we are now starting to see lawsuits and prosecutions against companies that fail to secure their users' passwords properly. Example: LinkedIn slapped with $5 million class action lawsuit; Sony fined £250,000 over PlayStation data hack. If I recall correctly, LinkedIn was actually encrypting its users' passwords, but the encryption it was using was too weak to be effective.