Reversible encryption on passwords?
Hi all, I've been thinking about the pros and cons of using encrypted passwords, and I've realized that there are actually some additional choices. Normally "encrypted password" means you run a secure hash (non-reversible) on a password and then you actually compare the hashes. But there are drawbacks: 1) You can't remind the user of their password, because you don't have it. 2) Certain password-checking schemes (design for plain-text may not be easily implemented this way. But then I started thinking about *actual* encryption and things like GnuPG encryption and signing. Suppose I use a private key to encrypt/decrypt the password data for storage in the database. The key might be stored on the server's filesystem or be retrieved from a more secure computer, but it would be used to encrypt the data for storage and then to decrypt it for authentication. You could do this with public-key cryptography, too, but it's not clear to me that there is an advantage to that. Anyway, in the authentication process, the password would posted in "plain text" -- but if the connection is via SSL (HTTPS), then it is actually encrypted on the way to the server. So, in this scenario, my database contains password fields which can only be read with the right key, but can be decrypted, and the connection to the user is protected by SSL's public-key cryptography. (The idea being that should the database be compromised, the passwords would not be exposed -- at least not in plain text, you'd need to get both the database and the key(s)). It seems to me that this offers most of the security of normal encrypted passwords, but with fewer drawbacks. It does mean that the site owner can read the passwords, but that's supposed to be the advantage. Presumeably I'm not the first person to think of this -- is it used by some sites or not? If not, why not? I'm wondering what the faults are and whether it'd be a good strategy for us. Thanks for any comments, Terry -- Terry Hancock ( hancock at anansispaceworks.com ) Anansi Spaceworks http://www.anansispaceworks.com
Terry Hancock wrote:
Hi all,
I've been thinking about the pros and cons of using encrypted passwords, and I've realized that there are actually some additional choices.
Normally "encrypted password" means you run a secure hash (non-reversible) on a password and then you actually compare the hashes. But there are drawbacks:
1) You can't remind the user of their password, because you don't have it.
2) Certain password-checking schemes (design for plain-text may not be easily implemented this way.
But then I started thinking about *actual* encryption and things like GnuPG encryption and signing.
Suppose I use a private key to encrypt/decrypt the password data for storage in the database. The key might be stored on the server's filesystem or be retrieved from a more secure computer, but it would be used to encrypt the data for storage and then to decrypt it for authentication. You could do this with public-key cryptography, too, but it's not clear to me that there is an advantage to that. [scenario snipped]
It's the other way around, PGP-type encryption of the credentials with the public key would be _the_ solution to what you want. Think about it, you create a privat/public key pair, store the private key on a disk which you lock up in a safe. Store the public key and the passwords (encrypted with that key) on the server. Now you have just a "special" kind of hash, reversible only by breaking in your safe in stealing the private key. The drawback is that asymetric encryption is computationally quite expensive. The idea of storing the decryption key for retrieval on a "secure" server is not a security enhancement, unless you consider added obscurity as more security. Because if someone cracks open your server he will be able to retrieve the decryption key anyway. cheers, oliver
Keeping private keys on connected servers is an all-around bad idea. All I need to do is break into your box. Can do. ;-) Also, password garbling schemes are intentionally one-way. Otherwise you won't gain much in terms of security. Some explanations of the issues involved can be found here: <http://www.gnu.org/manual/glibc-2.2.5/html_node/crypt.html> HTH, Stefan --On Donnerstag, 20. März 2003 09:15 -0800 Terry Hancock <hancock@anansispaceworks.com> wrote:
Suppose I use a private key to encrypt/decrypt the password data for storage in the database. The key might be stored on the server's filesystem or be retrieved from a more secure computer, but it would be used to encrypt the data for storage and then to decrypt it for authentication. You could do this with public-key cryptography, too, but it's not clear to me that there is an advantage to that.
-- Those who write software only for pay should go hurt some other field. /Erik Naggum/
participants (3)
-
Oliver Bleutgen -
Stefan H. Holek -
Terry Hancock