UPDATE: My questions and concerns below boil down to: "Should I reject obviously poor passwords like 'hellomydarling' or 'password'? My guess is yes and I want to know to what extent. I'm using a password strength estimator to assist with that.
I have been doing research regarding usability verses security when it comes to password selection. I came across this very interesting quote I found on this Stack Exchange.
"Security at the expense of usability comes at the expense of security" https://security.stackexchange.com/a/6116/39548
My thoughts and question stem from this. I am working on a prototype for a password strength meter that appears beside new password selection input fields (JsFiddle at the bottom).
The policy I have in place is to make my validator fail if the password is deemed "unusable" by me and to let "better" passwords through.
However, I am concerned about the effect of banning "teenagemutantninjaturtles" but letting "Password must be at least 8 characters" through. Both are bad passwords, but my prototype really only handles the first very well.
This password strength meter is based on Dan Wheeler's zxcvbn "realistic password estimation library" available from https://github.com/lowe/zxcvbn and discussed in detail here: https://tech.dropbox.com/2012/04/zxcvbn-realistic-password-strength-estimation/
I like zxcvbn because it actually uses a dictionary to help identify weak or poor passwords. However, I believe it is too forgiving of plain text pass phrases. For example, it's stock implementation will award the highest possible score (4/4) for 'teenagemutantninjaturtles'.
However, Dan Goodwin at Ars Technica has pointed out that without true randomness, pass phrases aren't turning out to be very effective to thwart motivated attackers ( http://arstechnica.com/security/2013/10/how-the-bible-and-youtube-are-fueling-the-next-frontier-of-password-cracking/2/ ).
So that is why I'm attempting to bolster the behavior of the password strength meter by finding passwords that easily match the zxcvbn's dictionary and simply mark them as "unusable".
For your reference, we disclose that the minimum password length is 6 (even though they suck) and the maximum is 50 chars. There are no other restrictions or requirements. We do not disclose the precise reason why the password is unusable (e.g. it matches a dictionary word, or is to simple, or matches a pattern, etc) although we do provide hints such as those examples.
Here are my actual questions:
Considering that it's very hard for password strength meters to properly evaluate 'good' passwords from 'poor' passwords, when thinking about human behavior and security...
- Is it worth it to even include a password strength estimator?
- Is it worth trying to bolster the existing library with stricter rules?
- Am I just going frustrate my users when I ban a password they think is a good idea? (I'm worried this will potentially cause them to either give up or copy there password to their monitor, etc).
- If it is not a good idea, what's the best way to alert users and stop the worst possible passwords?
Note: I am not trying to invent my own security protocol. Once we get the password over https, we store it using via bcrypt with a high cost/iteration. For the sake of argument, let's pretend like this is the only security problem I have left to solve (which it is not).
I am simply trying to encourage better password use for our users.
I've copied over my work in progress to a jsFiddle, where my own changes are in the script part (and zxcvbn is an included resource).
There's also a lot of commentary and work done to make the password strength meter more usable, which is why there are timers and stuff going on, too.
Thank you for your thoughts.