I am no crypto expert in any way so please bear with me if my question is kind of stupid.

We use OpenSSH key pairs on a regular basis and due to the asymmetric nature of key pairs, as far as I understood the concept, giving out your public key to the ... well ... "public" - is considered a safe thing to do since it can only be used to verify that you are really you. Creating content or authenticating yourself works against the private key which never leaves your machine, hence the strong security.

Now, given the above mentioned situation as a comparison, can it be considered secure if I created a password hash with the unix tool mkpasswd and a salted SHA512 hash and gave THAT out to the public?

My guess would be that it is not a smart idea to do, same as you would do with hashed passwords in a user database of a website. However, since this is only a guess I'd like some expert opinions.


  • I think your understanding is right; hashing your passwords adds some security, but less secure than a public key. Jul 20, 2018 at 16:27

3 Answers 3


The key difference here (no pun intended) is that the key includes a significant amount of entropy (i.e. it is random). Passwords are often quite terrible, commonly having under 30 bits of entropy. 30 bits is easily brute-forceable, so password hashes are designed to be slow (you specified salted SHA512, but you omitted the number of rounds), making the brute-force take longer. Despite this mitigation poor passwords will still be broken quickly.

Without a salt an attacker could use precomputation in the form of a rainbow table. That way, they could spend a bunch of time doing work so that when they do discover the hash value they can break it very quickly. The use of a (sufficiently long and random) salt prevents this, so that the attack can only begin the moment the hash is exposed.

So you are correct, this is a bad idea unless it is your password and you generated it with over 100 bits of entropy (in which case it's more like a key than a password).

It should also be noted that SHA-512 with the default of 5,000 rounds is not very good. It's not nearly as bad as a single round of MD5, but most computers nowadays can do over 2,000,000 rounds in under a second. You could expect a motivated attacker targeting a 5,000 round SHA-512 password to do millions to billions of guesses per second.

  • well, as far as I understood mkpasswd uses a default 5000 rounds. Does that add to the entropy or is it a different topic? I get that brute forcing bad passwords is always a danger, but would making the hash public increase that risk anyhow?
    – ArSeN
    Jul 20, 2018 at 19:43
  • @ArSeN With 30 bits of entropy an attacker would have a 50% chance of guessing it after 2^29 hashes. Using a slow hash doesn't change that, it just means that each of the 2^29 hashes takes longer, so it increases the time to bruteforce it even though the password is poor. Jul 20, 2018 at 20:08
  • @ArSeN It can be described as increasing effective entropy (with every doubling of iterations increasing the effective entropy by one bit), but it does not actually change the entropy in the information theory sense.
    – forest
    Jul 21, 2018 at 8:27

The key factor here turns out to be how difficult the password in question is to guess. If the password is weak—and most passwords by far are terrible—then giving out the hash gives the attacker a means to perform yes/no guesses on password guesses, and the cost of trying out lots of such guesses is much lower than that of finding a preimage for the hash (an input that produces the same output that was revealed).

With correctly generated private keys this isn't a concern because there are no efficient methods for guessing a private key. But note that with incorrectly generated private keys it's another story—there have been many incidents of buggy software that produces RSA keys that fit easy-to-guess patterns and therefore can be cracked.

Conversely, if a password is selected uniformly at random from a sufficiently large set, releasing a hash of it would be safe. For example, a 19-character uniform random printable ASCII password has about 126 bits of entropy—about as hard to guess as an AES-128 key.


First and foremost, you would have no way to authenticate yourself. If you send the hash, you proved nothing as everyone knows your hash. If you send plaintext password, the party now not only knows it, but other parties may not know you used it. So it is one-time use at best and completely insecure at worst.

As for the security of hashing a password, it can be secure if the password is long, generated randomly and hashed with a strong hash function. But for human created passwords, dictionary attacks would make it questionably secure even for good long passwords like correct horse battery staple.

There are actual applications that outright rely on the content not being retrievable from the hash other than password protection. A notable use is a secure coin flip. Therefore, it was presumably studied and determined safe for random passwords/keys.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .