I'm developing a web application for which final users have to create an account. This part is very easy: I'll hash their passwords with SHA-256 so that nobody, except the user himself, knows the password. Now comes the difficult part. After the user creates an account, he/she has to provide the password of his/her email server. Now the question is: how can I protect this password decently (the password will be stored in a database)? If I encrypt the password with TripleDES, any developer or system administrator would be able to decrypt the password and see it. What is the usual way to deal with such a problem? Many Thanks.
+8
A:
The usual way to do this is to use an symmetric encryption key which is derived from the user's password. The standard way to do this is using the algorithm specified in RFC2898, which generates a set of cryptographically secure bytes you can use as a key and IV. It's probably supported by a library for your language, .NET for example, which is what I use has the Rfc2898DeriveBytes class.
Of course when your user changes their password you will have to decrypt any existing cipher text and then derive the new key and re-encrypt.
blowdart
2010-02-22 12:35:45
The link to the class is http://msdn.microsoft.com/en-us/library/system.security.cryptography.rfc2898derivebytes.aspx.
Obalix
2010-02-22 12:39:01
Caveat: this means you need to transmit the user's password from the client to the server, so the connection must be secure. One of the advantages of hashing passwords is that you can hash the user's entry on the client machine, and then transmit only the hash to the server. But, assuming a secure connection, blowdart's suggestion has the tremendous advantage of using a different encryption key for each user's data, greatly reducing the threat of compromise.
Adam Liss
2010-02-22 12:40:15
Well usually you *are* transmitting the user's password from the client to the server, but once it reaches the server you are then hashing it for the comparison. So what you'd do is at the same time as hashing for password checks you'd derive the key and place it in session state on the server so you can use it throughout the user's session.
blowdart
2010-02-22 12:43:09
Why would you use symmetric encryption instead of a cryptographic hash? During login, you rehash the provided input and compare it to the stored salted hash; if there's a match, you approve login. Then a sysadmin or developer can't decrypt a user's password, but it can be changed.
Adam Musch
2010-02-22 14:46:24
Never mind, I just figured it out; I didn't read closely enough that the OP needs the original cleartext for accessing a third-party account. Ignore me.
Adam Musch
2010-02-22 14:47:12