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.

  • 3
    encryption is reversible, hashing is slower, MD5 is not the only hashing algorithm, encryption keys need to be stored, and on and on – schroeder Nov 10 '15 at 22:55
  • 1
    @schroeder theoretically hashing is irreversible while encryption is. How is that good in real life when the hash can be cracked while the ciphertexts is almost impossible to crack? – Ulkoma Nov 10 '15 at 22:59
  • 1
    I would assume if we used a secure asymmetic encryption algorithm, securely generated public and private keys, and discarded the private key, then this would be effectively irreversible. – emory Nov 10 '15 at 22:59
  • 2
    @Ulkoma I suspect that if you use the best available hashing algorithm it will be effectively irreversible and that some other properties will make it superior to encryption. Among other things, the size of the encrypted password would give an attacker information about the size of the users password. – emory Nov 10 '15 at 23:03
  • 1
    @Ulkoma you assume hashes can be cracked more easily than cyphertext – schroeder Nov 10 '15 at 23:05

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.


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.

  • Excellent description of the differences between hashing passwords to create authentication verifiers vs. encryption of password plaintext. – Andrew Philips Nov 11 '15 at 5:33
  • The OP is suggesting that we create a unique public/private key for each user, dispose of the private key, encrypt the password with the public key, and store the encrypted password and the public key for each password. Thus they can learn the private key is false. – Neil Smithline Nov 11 '15 at 8:08

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!

  • The OP didn't specifiy the algorithm used, but for RSA at least the ciphertext length is based on the modulus used, not the plaintext. So a 2048 bit modulus would produce 2048 bit ciphertext, regardless of the plaintext encrypted. RSA isn't a block cipher. – Steve Sether Nov 11 '15 at 15:19
  • Good point - corrected – Matthew Nov 11 '15 at 15:36

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.

  • The OP is suggesting that we create a unique public/private key for each user, dispose of the private key, encrypt the password with the public key, and store the encrypted password and the public key for each password. Thus Encryption leaves all passwords exposed is not obviously true. – Neil Smithline Nov 11 '15 at 8:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.