Why do websites store passwords' hashes not their ciphertexts?

Question

Every time we discuss passwords and hashing functions posters immediately bring up how hashing functions can be cracked and we should avoid MD5 .. etc Hence we have use strong passwords and salt and other measures to avoid brute force and rainbow tables .. etc

In the same time every time we discuss TLS people point out that it's almost impossible to break the encryption used and how secure TLS is..

Why do we need hashing functions to store the passwords in the database then? let's just have them encrypted instead? since it's was safer and let the user enjoy using weak passwords.

Assuming that we use an asymmetric encryption algorithm, securely generate public and private keys, then discard the private key.

Answer 1

My understanding is that you feel that passwords would be safer if they were stored by having the site:

1. Generate a unique public/private key pair.
2. Immediately dispose of the private key in a secure manner.
3. Encrypt the password with the public key.
4. Store the public key and the encrypted password in the database, similar to the common practice of storing the salt and hashed password.

Your statement that this storage model for passwords would be safer than modern techniques is false. While this approach does have the irreversibility quality that is essential for password storage and has adequate pre-computation defenses, it lacks the performance defenses needed to prevent even a simple dictionary attack.

Modern password storage hashing algorithms like bcrypt and scrypt are designed to be slow to execute even in the face of specialized hardware. On the other hand, encryption algorithms are designed to be as performant as possible. So an offline dictionary attack to crack passwords that were encrypted with a public key will be much faster (likely many orders of magnitude) than a similar attack trying to crack bcrypt or scrypt hashes.

Answer 2

TLS uses a public and private key to encrypt a session. The clients have only the certificate containing the public key, but in order to use it, the server contains the private key. Outside the server, this communication is safe. Inside the server, an attacker could learn the key and decrypt the communications.

If we use public/private key encryption to encrypt a password and an attacker gets onto the server, they can learn the private key, then decrypt all the passwords.

Hashing has no key (although it may use "salt".) It is often called a one-way function, so unlike encryption it has no "reverse" algorithm. If you hash data you can't easily un-hash it. You can still brute-force attack a hash by trying every password you can think of, and if the hashes match, you've guessed it. But there is no magic value that will recover all the passwords. That's why hashing stores passwords more securely than encryption.

Regarding flaws in MD5, SHA-1, etc., remember that there are several uses for cryptographic hash functions, and that the vulnerabilities each exposes differs by use case. One use for a hash is to generate a message digest, which is a unique number that helps validate a piece of text is unchanged (such as the data contained on a certificate.) If a second document can be forged with the same digest value, then an attacker could create a false certificate and perform a man-in-the-middle attack on all users of the server. But if a collision is found between two passwords in a database, it risks leaking only the information that both Ulkoma and JohnDeters chose the same password. That carries risk to only two people instead of every user of the system, which is overall a less severe problem.

The proposal to generate a unique public key for each user (discarding the private key), then encrypt and store the password, results in a system functionally equivalent to using a salted hash. The attacker doesn't have to crack the public key, they just have to try encrypting a bunch of passwords with the public key until they get a match.

Answer 3

Generating a key pair takes time - even with modern computers, it takes several seconds. It wouldn't take that much effort to cause issues with server performance if you have to generate a large number of key pairs.

Furthermore, storing an encrypted password and a key for each would take up more storage than storing a hash or a hash plus a salt for each. For small sites, this might not be a major concern, but when you have millions of users, it becomes a potential issue.

Effectively, the process suggested is a hash process, just less efficient than using a routine designed to hash inputs.

We have better tools for this - the cryptographic hash function - so this could be considered as using a power drill as a hammer. It works, and is a much better tool for some jobs, but has a lot more moving parts and a higher cost than the hammer, which will do a fantastic job of getting nails in!

Answer 4

If the key for the cyphertext is exposed it will leave your db compromised. These passwords can be decrypted and used to login to your site or any other site where the user used the same (or similar) password immediately.

Secure cryptographic hashing algorithms are not reversible and allow more time to manage a breach as they will need to be brute-forced.

I don't understand TLS enough to comment on it but the idea remains the same. With hashing, you're limited to brute-force techniques and with encryption you only need the access to the key.

Edit: Another benefit to hashing is it protects better passwords better. In an instance where the majority of your users use very complex and lengthy passwords, it's going to be much more difficult to breach many accounts. Encryption leaves all passwords exposed.