The README suggests that instead of this, you should check entropy. That's a little tricky! Entropy in the traditional information-theoretic sense is a property of a random variable. You need to know what distribution a user drew it from. You can make educated guesses (e.g. if long, probably using password manager, if using password manager, probably fixed length) but that usually only tells you something useful about the _good_ passwords, and not the bad. You don't care about the good passwords. If the user entered "correct horse battery staple" but the user _always_ uses that password, a sufficiently informed attacker experiences 0 bits of entropy.
So, entropy estimation is pretty bad, and we end up with imperfect password rules. Here are some ideas:
1. Make an educated guess about the distribution. Is it "correct horse battery staple"-like? Because then maybe don't tell people to add special characters if it's long enough. Relaxing requirements when people add numbers is tricky; turns out people are really likely to add those numbers at the end, and then it's probably a bad reused password like sparky1 or whatever.
2. Filter extremely common passwords, and things directly linked to usernames.
3. 8 <= len <= 70 or so (otherwise you'll get probably-bogus Hackeroni submissions about DoS).
4. No scheme will save your user from shitty passwords. bcrypt, scrypt, argon2, whatever -- not an excuse for not protecting your password database.
5. If you wanna be really fancy, use your guesstimate about the source distribution to produce an entropy estimation. Entropy is the nerd-proof answer, but most consumers don't know what it is. Whether or not telling users something like "try making your password longer" or adding a new class of special characters is friendly UX and whether that actually makes them use significantly better passwords versus the moral equivalent of sparky1 is an open question; I don't think it's an unreasonable assumption that both work out worse than you might hope.
It's important to note that this doesn't need to be perfect (and strictly speaking, it can't be). You just need to stop non-advanced users from shooting themselves in the foot, and ideally prevent power users from being annoyed at your service.
I should really turn this into a library :-) But before you do any of this fancy stuff? Implement 2FA, ideally U2F. No work you do on password rules is going to compare to what you get if you allow shitty passwords, but most of your users use U2F. Just get started now. I know U2F has limited distribution right now. That's a chicken or the egg problem. You can do TOTP too, but trust me, U2F is way, way better.
If you haven't seen it before, zxcvbn [1] seems like a good attempt at automating these things, and there are ports of it in many popular languages. It's been in use in production at Dropbox for several years, now, so I'm hoping the ideas and implementation have been vetted pretty well.
(I have no Dropbox affiliation, I just found the library a while back and thought it was a great way to keep passwords secure while getting rid of arbitrary requirements focused more on SQL injection than password safety.)
I assume you mean "it's long but a commonly chosen long password"
Do you have evidence that is a commonly used password? I'm genuinely curious. The people geeky enough to know that meme might be slightly more likely to understand why it's a poor choice of password.
It was just a random example, but a couple years ago I found 250 BTC with a private key of sha256("how much wood could a woodchuck chuck if a woodchuck could chuck wood"). People use quotes from movies/tv/books/etc for stuff that matters.
Still better than most other password quality checkers.
In a sense, they can all only tell you that something is certainly a bad password, or maybe a good one. It's a very hard problem, and zxcvbn does a much better job than most (more naive) tools.
It estimates 79.6 bits of entropy. It's basing the estimate on just the words, not on the popularity of the phrase as a whole.
Let's compare that to https://www.grc.com/haystack.htm which many people promote as a good password checker, but is actually terrible. It claims 177 bits of entropy. This is basing the estimate on just the individual characters.
The README suggests that instead of this, you should check entropy. That's a little tricky! Entropy in the traditional information-theoretic sense is a property of a random variable. You need to know what distribution a user drew it from. You can make educated guesses (e.g. if long, probably using password manager, if using password manager, probably fixed length) but that usually only tells you something useful about the _good_ passwords, and not the bad. You don't care about the good passwords. If the user entered "correct horse battery staple" but the user _always_ uses that password, a sufficiently informed attacker experiences 0 bits of entropy.
So, entropy estimation is pretty bad, and we end up with imperfect password rules. Here are some ideas:
1. Make an educated guess about the distribution. Is it "correct horse battery staple"-like? Because then maybe don't tell people to add special characters if it's long enough. Relaxing requirements when people add numbers is tricky; turns out people are really likely to add those numbers at the end, and then it's probably a bad reused password like sparky1 or whatever.
2. Filter extremely common passwords, and things directly linked to usernames.
3. 8 <= len <= 70 or so (otherwise you'll get probably-bogus Hackeroni submissions about DoS).
4. No scheme will save your user from shitty passwords. bcrypt, scrypt, argon2, whatever -- not an excuse for not protecting your password database.
5. If you wanna be really fancy, use your guesstimate about the source distribution to produce an entropy estimation. Entropy is the nerd-proof answer, but most consumers don't know what it is. Whether or not telling users something like "try making your password longer" or adding a new class of special characters is friendly UX and whether that actually makes them use significantly better passwords versus the moral equivalent of sparky1 is an open question; I don't think it's an unreasonable assumption that both work out worse than you might hope.
It's important to note that this doesn't need to be perfect (and strictly speaking, it can't be). You just need to stop non-advanced users from shooting themselves in the foot, and ideally prevent power users from being annoyed at your service.
I should really turn this into a library :-) But before you do any of this fancy stuff? Implement 2FA, ideally U2F. No work you do on password rules is going to compare to what you get if you allow shitty passwords, but most of your users use U2F. Just get started now. I know U2F has limited distribution right now. That's a chicken or the egg problem. You can do TOTP too, but trust me, U2F is way, way better.