Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Just a theoretical question:

If I had ideal users, who all provide fully random 128-bit passwords, And also, I invalidate every password shorter than 128 bits.

Then would I still need a slow hash function to store these passwords?

share|improve this question
To clarify, only the entropy of the password matters. The actual length of the password is irrelevant. That is correct horse battery staple is ~44 bits of entropy despite being 28 bytes (224-bits) long when encoded in plain ASCII. When the entropy is significantly longer than about ~80 bits, you don't really have to worry it being brute-forcing. (2^80 ~ 10^23; brute forcing a billion hashes per second would require 38 million computer-years to break; and every additional bit doubles the required time). – dr jimbob May 4 '14 at 20:43
up vote 7 down vote accepted

If users could be relied upon to provide truly random passwords, there would be no need to use a slow hash function. But you can never rely on users for that.

share|improve this answer

If users provided random passwords with the equivalent of 128+ bits of entropy that are never used elsewhere, there's no need for a slow hash function like bcrypt, scrypt, sha256crypt, sha512crypt or PBKDF. Similarly, there would be no need for a salt on the hash.

Why? Brute forcing is simply unfeasible when the expected time is O(2128); e.g., even with billions of computers trying billions of hashes per millisecond, you won't be able to brute force a 128-bit entropy hash in millions of years (precisely you'd have about a 1 in 10000 chance of breaking it). Granted there's no reliable method to test the strength of user-created passwords, as entropy is highly model dependent. E.g., a password like: Qwertyuiopasdfghjklzxcvbnm will appear as 132 bits despite being the order of keyboard keys and being rather low entropy. Or if my password to was that calculator says 147 bits of entropy (when its extremely weak). On the other hand, knowing the method of password generation you can reliably calculate the passwords entropy; so if you force all your users to learn a 128-bit random password you generated you can ensure their passwords are reasonably strong.

There would still be a need for a hash function though as you should never store passwords in plaintext. An attacker should not be able to find a list of plaintext passwords in the database from some other compromise (e.g., finding an old backup, SQL injection, memory leak, etc). A simple hash (e.g., SHA-2) would work to prevent that.

share|improve this answer

You have two more aspects you should take into account 1- Is your user input 'random enough'?

At the moment, bruteforcing 128 bits is unfeasible. Why use a hash function at all if the bits are random? 128 random bits will be stronger than the hashed output of the same. Two different passwords may produce a colision in a hash function, the bigger the space to hash, the greater probability there will be collisions, while a random password would not have this issue.

2- How will someone remember 128 random bits? Would anyone change their 128 random bit password after memorizing it?

It looks like a pain in the ass solution.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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