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