You should have ≈128 bits or more entropy in any password you want to remain secure regardless of the password hashing function.

Rationale: slow password hashing functions only add a constant-time factor to brute-force search. Since you don’t know the processing capabilities of any potential attacker, the only date path is to use a very high-entropy password Such a password would be securely stored even if hashed with a single iteration of MD5 without salt.

So what do fancy iterated, “memory hard” functions buy us?

They help against, but do not prevent, attacks on low entropy passwords, the sort that humans can actually memorize. In effect, they increase the work factor required for a dictionary, brute-force, or hybrid search by a fixed amount. You could view this as “extra bits of security”, but you’ll only know how many bits you still need “to be secure” if you know with fair certainty the computational abilities of your attacker.

If your adversary is a nation-state’s security apparatus, the number of “bits of entropy you need” in the password differs vastly from that when your adversary is me. So the only truly safe thing to do is to always use a high-entropy input password, which renders the fancy hash function pointless.

Slow password hashes are implemented to mitigate the costs to users of a breach of the password hash database. They cannot make low-entropy passwords “always secure” unless they themselves utilize 2^100 operations, making them completely impractical.

You should have ≈128 bits or more entropy in any password you want to remain secure regardless of the password hashing function.

Rationale: slow password hashing functions only add a constant-time factor to brute-force search. Since you don’t know the processing capabilities of any potential attacker, the only safe path is to use a very high-entropy password Such a password would be securely stored even if hashed with a single iteration of MD5 without salt.

So what do fancy iterated, “memory hard” functions buy us?

They help against, but do not prevent, attacks on low entropy passwords, the sort that humans can actually memorize. In effect, they increase the work factor required for a dictionary, brute-force, or hybrid search by a fixed amount. You could view this as “extra bits of security”, but you’ll only know how many bits you still need “to be secure” if you know with fair certainty the computational abilities of your attacker.

If your adversary is a nation-state’s security apparatus, the number of “bits of entropy you need” in the password differs vastly from that when your adversary is me. So the only truly safe thing to do is to always use a high-entropy input password, which renders the fancy hash function pointless.

Slow password hashes are implemented to mitigate the costs to users of a breach of the password hash database. They cannot make low-entropy passwords “always secure” unless they themselves utilize 2^100 operations, making them completely impractical.

You should have ≈128 bits or more entropy in any password you want to remain secure _regardless of the password having function.

Rationale: slow password hashing functions only add a constant-time factor to brute-force search. Since you don’t know the processing capabilities of any potential attacker, the only date path is to use a very high-entropy password Such a password would be securely stored even if hashed with a single iteration of MD5 without salt.

So what do fancy iterated, “memory hard” functions buy us?

They help against, but do not prevent, attacks on low entropy passwords, the sort that humans can actually memorize. In effect, they increase the work factor required for a dictionary, brute-force, or hybrid search by a fixed amount. You could view this as “extra bits of security”, but you’ll only know how many bits you still need “to be secure” if you know with fair certainty the computational abilities of your attacker.

If your adversary is a nation-state’s security apparatus, the number of “bits of entropy you need” in the password differs vastly from that when your adversary is me. So the only truly safe thing to do is to always use a high-entropy input password, which renders the fancy hash function pointless.

Slow password hashes are implemented to mitigate the costs to users of a breach of the password hash database. They cannot make low-entropy passwords “always secure” unless they themselves utilize 2^100 operations, making them completely impractical.

You should have ≈128 bits or more entropy in any password you want to remain secure regardless of the password hashing function.

Rationale: slow password hashing functions only add a constant-time factor to brute-force search. Since you don’t know the processing capabilities of any potential attacker, the only date path is to use a very high-entropy password Such a password would be securely stored even if hashed with a single iteration of MD5 without salt.

So what do fancy iterated, “memory hard” functions buy us?

They help against, but do not prevent, attacks on low entropy passwords, the sort that humans can actually memorize. In effect, they increase the work factor required for a dictionary, brute-force, or hybrid search by a fixed amount. You could view this as “extra bits of security”, but you’ll only know how many bits you still need “to be secure” if you know with fair certainty the computational abilities of your attacker.

If your adversary is a nation-state’s security apparatus, the number of “bits of entropy you need” in the password differs vastly from that when your adversary is me. So the only truly safe thing to do is to always use a high-entropy input password, which renders the fancy hash function pointless.

Slow password hashes are implemented to mitigate the costs to users of a breach of the password hash database. They cannot make low-entropy passwords “always secure” unless they themselves utilize 2^100 operations, making them completely impractical.