# Password length versus hash length?

If a system hashes passwords with a 256-bit long hash, are passwords (which are not necessarily alphanumeric, can be any value per byte (0-255)) longer than 32 bytes useless under the context in which an attacker with a VERY fast machine brute forces passwords?

• Hash functions are always functions from an unlimited domain into a fixed range. But that doesn't mean that longer inputs can't be matched, or that it is useless to have longer inputs. All it says is that at least one hash value has an infinite number of preimages. And in real constructions it is very likely that all hash values have an infinite number of preimages. When talking about cryptographic hash functions, that still doesn't mean it is easy to find preimages or even collisions. Considering very fast machines: Brute force is not a thread for any serious cryptosystem per se. – tylo Apr 27 '15 at 11:32

The entropy of passwords is not universally distributed. So hashing can be used to concentrate the input of a hash.

The concentration of entropy from another source is called extraction by HKDF, which is a key based key derivation function (which should not be used for passwords). This is from the introduction of RFC 5869, which defined HKDF:

Thus, the goal of the "extract" stage is to "concentrate" the possibly dispersed entropy of the input keying material into a short, but cryptographically strong, pseudorandom key.

Now the problem with passwords it that they usually does not contain enough entropy or randomness. The size of a password is an important part of estimating the strength of a password. If a password has enough entropy then you could even use a KBKDF such as HKDF or a hash directly. But the table on the same Wikipedia page shows that you would need 20 fully random printable ASCII characters to accomplish a 128 bit security level.

Instead what is used is a Password Based Key Derivation Function or PBKDF. The usage of such a function is often called password hashing to distinguish it from directly applying a hash over the password. Common implementations are PBKDF2, bcrypt and scrypt. The PBKDF uses password stretching to accomplish password strengthening. It adds at least two input variables besides the password: a salt and a work factor.

So to get back to your question:

• don't use a normal hash for password hashing, use a password hash/PBKDF;
• the more randomness in the password, the better - this usually means longer hashes not shorter ones;
• the size of the password is not in any way limited by the (password) hash function.

A human will never - in real life scenarios - remember a password or care to type in a password that contains enough randomness to reach the security level provided by even the least of the hash functions (MD5).

In the end it doesn't really make sense to limit the size of passwords unless for backwards compatibility reasons. The minimum size should be controlled however, and as many possible additional measures should be taken to protect the password as passwords are inherently weak.

No, since passwords are usually far from uniformly distributed.

If the passwords are uniformly randomly generated among all possible byte sequences of the chosen length, then there is no point in having a password that's longer than min(hash length, brute force resistance) where brute force resistance is the number of brute force attempts that you want to resist. Picking a 32-byte password gives you a huge safety margin on the brute force length — all the computers in the world today (~1 billion) running for the lifetime of the universe (~1 billion billion seconds, ~1 billion attempts per second) amount to about 15 bytes ($2^{120}$) of entropy.

Sometimes you may want to have a safety margin, if the setting in which the password is used leaks some information, but not the whole password, through a limited-bandwidth side channel. In this case, it can make sense for the password to be longer than the hash. However this is usually not a concern with a purely random password if implemented at all correctly.

If the password is something that can be remembered and typed by a human being, this is a whole different matter. Human passwords are limited to printable characters, but that's only the tip of the iceberg. Human passwords have very low entropy per byte, because humans are not good at memorizing purely random data. Humans are better at remembering a string of dictionary words (let's say 12 bits per word) than a string of arbitrary characters (let's say 6 bits per byte if you stick to ASCII alphanumerics and two punctuation signs), but it takes more byte to write out a 12-bit-entropy word than a 12-bit-entropy alphanumeric sequence.

For a human password, the length does not give a good indication of the entropy. There is no reason to limit the password to 32 characters, though hardly anyone will pick such a long password if they have to remember it. If the password is automatically generated, it's better to encode it using printable characters that are easy to tell apart (such as base32, making it longer for the same entropy.

Don't forget to use a password hash a.k.a. salted key stretching function (e.g. PBKDF2, bcrypt, scrypt), as opposed to an ordinary cryptographic hash like SHA-2, for human passwords.

I did not quite understand the question. Specially the part that says under the context.

The answer is no. because,

The output of a hash is a fixed value, for any given input of any length (If the length of the input is shorter than the block size, depending on the HASH algorithm being used, an appropriate padding scheme is present).

So whether the passwords were 32 bytes, or more, or even less. It makes no difference. Although it is much better to use longer passwords as the short and common ones can be retrieved using a pre-calculated look-up hash table.

One point worth mentioning is, as long as a developer is storing passwords in the database as the hashes of the passwords rather than the plain passwords themselves, it is of no value to limit the maximum length of the password. In fact, the longer, the better. BUT, in the end, they all wind up (in your case) to a 256 bit chunk.

• why is the downvotes ? can you elaborate please? – tony9099 Apr 26 '15 at 17:41
• In this case it's probably less the content than the way it is written up. Currently I have trouble understanding it. And starting with "I did not quite understand the question" is never a good plan. Finally, you didn't distinguish between hashes and password hashes, but as that wasn't part of the question it should not be a reason to downvote. PS I did not downvote. – Maarten Bodewes Apr 27 '15 at 13:01
• Thanks for your feedback @MaartenBodewes. I think if we really want to make this community stronger, we should be more communicative rather than blunt. I appreciate your time dropping those 2 lines and your remarks are duly noted. – tony9099 Apr 27 '15 at 16:15