How should I ethically approach user password storage for later plaintext retrieval?

Answer 1

The only way to allow a user to retrieve their original password, is to encrypt it with the user's own public key. Only that user can then decrypt their password.

So the steps would be:

1. User registers on your site (over SSL of course) without yet setting a password. Log them in automatically or provide a temporary password.
2. You offer to store their public PGP key for future password retrieval.
3. They upload their public PGP key.
4. You ask them to set a new password.
5. They submit their password.
6. You hash the password using the best password hashing algorithm available (e.g. bcrypt). Use this when validating the next log-in.
7. You encrypt the password with the public key, and store that separately.

Should the user then ask for their password, you respond with the encrypted (not hashed) password. If the user does not wish to be able to retrieve their password in future (they would only be able to reset it to a service-generated one), steps 3 and 7 can be skipped.

Answer 2

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 3

I think the real question you should ask yourself is: 'How can I be better at convincing people?'

Answer 4

From the little that I understand about this subject, I believe that if you are building a website with a signon/password, then you should not even see the plaintext password on your server at all. The password should be hashed, and probably salted, before it even leaves the client.

If you never see the plaintext password, then the question of retrieval doesn't arise.

Also, I gather (from the web) that (allegedly) some algorithms such as MD5 are no longer considered secure. I have no way of judging that myself, but it is something to consider.

Answer 5

Don't give up. The weapon you can use to convince your clients is non-repudiability. If you can reconstruct user passwords via any mechanism, you have given their clients a legal non-repudiation mechanism and they can repudiate any transaction that depends on that password, because there is no way the supplier can prove that they didn't reconstruct the password and put the transaction through themselves. If passwords are correctly stored as digests rather than ciphertext, this is impossible, ergo either the end-client executed the transaction himself or breached his duty of care w.r.t. the password. In either case that leaves the liability squarely with him. I've worked on cases where that would amount to hundreds of millions of dollars. Not something you want to get wrong.

Answer 6

Make the answer to the user's security question a part of the encryption key, and don't store the security question answer as plain text (hash that instead)