What would typically be considered an acceptable string entropy for passwords?

Question

I have gained interest in creating a way to check password strength (think password strength meters - yes - another one). I've found many ways to award a score on a policy driven approach (one capital, special character - you get it), but I've also begun to look into string entropy. Specifically, I've found this JavaScript implementation of Shannon entropy

In their example, "1223334444" awards 1.8464393446710154 in bits of entropy per character. I assume, then, the entropy for the string is the character count multiplied by the length - then being 18.464393446710154

My question is, though, in real-world terms, what does this value mean? Is it decent? poor? Where does the poor/decent/strong acceptability rate begin and end for values such as this? Likewise, whats considered "overkill" for an acceptable user expectation?

Answer 1

As I understand it, the amount of entropy in a password represents the number of guesses required to know what that password is. Each bit is a single yes-or-no decision, and ideally, the attacker would either get a "correct password" or "incorrect password" result (so, they have to guess the whole thing, all at once). For n bits of entropy, that requires 2^n guesses.

The desired strength depends on what sort of threat you expect to face. In particular, it depends on how fast the attacker can make guesses, and how long you expect the attacker to keep trying.

Once you have those numbers, your target minimum entropy (in bits) should be:

n = log_2(totalGuesses) = log_2(guesses/sec * durationInSeconds)

The persistence of the attacker is something which I don't know how to estimate. For the sake of argument, let's assume that you want your password to be secure for 1 week after the attacker starts guessing.

Number of guesses per second depends on how the password is protected, and what sort of access the attacker has. For an online attack (i.e., trying the login form of a website), you could rate-limit it to a fairly low value; 10 per second would be achievable. For unsalted MD5, it's safer to assume billions of guesses per second. For a strong hashing algorithm like bcrypt, it will be somewhere in-between (MUCH slower than MD5, in any case).

So, at 1 billion hashes per second (offline MD5 cracking), you would need to defend against about 6*10^14 guesses total, requiring about 49 bits of entropy. At 10 guesses per second (online, rate-limited attack), you need to defend against about 6*10^6 guesses, so you need about 22. bits of entropy.

Of course, per-character estimates of Shannon entropy will not accurately estimate the difficulty of cracking a password, and the percentage error will vary wildly depending on various factors. The approach you're taking will only give reasonably accurate results for computer-generated passwords, NOT for human-generated passwords.

Answer 2

This NIST recommendation is 80 bits of entropy for passwords.

At 350 billion guesses/sec, such a password will take a maximum of 109,528 Years to crack, 54,764 years on average.

Although you can ensure your own passwords are of such a strength, you can only guide your users to select such a password.

Password strength checkers such as zxcvbn can help, however these are only as good as their preloaded word lists, or checking methods (such as Shannon Entropy). In a targeted attack, it may already be known that the password generation method is a non-standard method only used by the victim. In that case, password strength meters cannot help - the entropy here is based upon the number of possibilities that that particular method can encode, and not those that the password strength meter is based upon.