I wonder if the guys who create these heuristics/recommendations ever had contact with humans. I believe that their research is thorough in their area of expertise (info sec), however, it sounds like they are only considering data per se, ignoring human behavior variables. There's little value in enforcing hard-to-break passwords while also encouraging users to write them down.
What I believe: Info sec researchers should team up with HCI people.
It's a hundred times better to have a difficult password on a post-it on a monitor than it is to have an easily guessable password. Who do you suspect is going to hack you? Ask that question honestly and you'll know how best to thwart them.
However, at the enterprise level, physically visible passwords are a big problem. Imagine a less-than-happy worker, about to leave the company, having the opportunity to get coworkers passwords. In such scenario, less strict rules (let's say, rules that didn't make people writing the passwords down) would have been beneficial.
And there's another point: the "perception" about IT security rules. If they ask too much of people (think "non-IT people"), they might create a image of overzealousness/"overcomplication". I wonder if this doesn't make people less compliant, with security rules, on the long term.
According to my experience:
1. People I know in real life
2. People who execute phishing attacks
Your strategy is harmful in the first case, though irrelevant in the second
If you really do 2FA, though, you should actually relax your password requirements. The most important attribute of a password used in a 2FA scheme is memorability, to make sure the user doesn't write it down (and thereby remove a factor.) Even a dictionary word works, as long as it's not one that's written down on e.g. the user's employee profile, like their mother's maiden name. Generating one or two dictionary words would be fine.
Keep in mind, the majority of 2FA security is in the token. As long as you verify the token first, the only power the password needs is to distinguish the device owner from someone who stole the device, or has snuck onto it. It doesn't need to protect against automated attackers; that's what the token (plus rate-limiting) is for.
It depends on the threats you face. Generally, most attacks are from insiders.
While I absolutely understand your sentiment, I think you might be conflating extreme password requirements with reasonable password requirements.
The article linked suggests that a strong password is 10 characters (that's the whopper), and three of four complexity requirements (capital, special, number, lower). That's not unreasonable. In fact, the only really difficult part of that is the 10 characters bit.
Switch that to 8 characters and you're golden.
Even better, have a five minute lockout and/or email unlock functionality after, say, ten failed attempts -- and you're doing great.
I deal with web application security assessments on a daily basis, and the current status (as a general rule) is abysmal. Passwords won't fix most of those problems, but making sure that users can't set "password" as their password can at least improve one potential issue.
Taking a step back, what we are doing is essentially: you may choose your own password! But, not really. We are going to tell you what not to. After you try it. And it's not a human, or equivalent AI: it's a (dumb) algorithm.
If you are going to let someone choose a password, ask yourself: why? Is convenience that much more important than security? Putting, what many people will perceive as, onerous constraints on the passwords greatly reduces that convenience. But users will still try to make it as low entropy as possible, so security suffers, nonetheless.
Or is security so important, to hell with convenience? Then why not just generate a PW for them? Here, print this out, since you were going to, anyway. Click "save this password", since you were going to, anyway.
Cut out the middle man and save everyone time.
Now, instead of forcing your users to do the try-to-cheat-the-entropy-algorithm dance, you can show them what a good password can look like. String four words together: happy (or less annoyed) users, good entropy, happy admins.
In addition to the frustrations you've outlined, consider a further case where a user's username is their email address (this was true in the project I mentioned). How is the user most likely to behave in this scenario? Are they going to take the time to generate a new password that satisfies your constraints, or are they going to keep things familiar and use the same password that they use for their email? Afterall, the usernames are the same - so why not keep things easy to remember? Well, I'm sure that's convenient, but I absolutely DO NOT want your email password, even bcrypted/&c., in my DB. No thanks.
Clearly, then, the best choice is to generate something for the user; something that they can reset using a classic 'forgot password' system, but which they never have to define themselves. Four diceware generated words, plus spaces, each no longer than two syllables, seems to do just fine.
[1] https://github.com/dropbox/zxcvbn
[2] https://dl.dropboxusercontent.com/u/209/zxcvbn/test/index.ht...
As a client side solution, that download size seems excessive for a password strength meter.
I understand it contains a dictionary of passwords but that is larger than most JS frameworks. Perhaps a server-based XHR-based solution would be better.
There are secure key-exchange schemes that don't require sending over the raw password, but this isn't an example of one.
The alternative is browser-side encryption of the password before sending but that will get @tptacek rightfully punching you in the face for even mentioning it.
oauth / openid for the win
Unless your companies "secret sauce" is user authentication and management, you probably shouldn't be doing it.
That's even before getting into the question about whether or not such systems make it more likely that users will fall to phishing attacks by conditioning them to enter their credentials somewhere other than the website where they were issued that they went to directly.
It's also not suitable for certain demographics, which puts you back at square one (rolling your own).
They wanted at least 10 characters, and at least one uppercase, one lower, one digit, and one special character. Easy enough with .NET's built-in membership stuff by setting:
passwordStrengthRegularExpression="(?=.{10,})(?=(.\p{Lu}){1,})(?=(.\d){1,})(?=(.*\W){1,})"
The "\p{Lu}" part handles uppercase characters even in Unicode chars, but Javascript has no equivalent, so I couldn't do client-side validation of that. Should be validating on both ends anyway, but it's still a pain.
The real part I hated was having to keep track of users' last N passwords to make sure they didn't re-use them. Since everything's hashed and salted, I just kept a table of previous hashes by user. Seems simple, but MS didn't see fit to include a HashPassword(string plainTextPassword, byte[] userSalt) method in the membership provider, so I had to reverse engineer their password-hashing method to check when they change passwords if it's something that's been used before.
Then I realized that they could just change their password N+1 times in about a minute, then re-use their expired password anyway, so we wound up having to set a minimum age of N weeks before a password could be reused as well.
The whole problem is an exploding requirements nightmare that could easily be solved by saying "Must be >32 characters and don't write it down anywhere, idiot."
The worst part is as much as I hate these types of requirements, I now perfectly understand why these systems are the way that they are.
Compression systems typically need a lookup table of some kind and have more overhead than just the raw comparison.
PasswordA SomeOtherPassword1 PasswordB SomeOtherPassword2 PasswordC SomeOtherPassword3
Just iterate on every other change, and you've beaten the requirement.
For example, if a user's first password is "first123!@#" and their second password is "second456$%^", there are no letters in common—but those two passwords, when joined together, are very intracompressible (by an ideal compressor)—and likewise, an attacker who knew that the first was a previously-used password would be very likely to try the second. That both properties apply is not a coincidence of this particular password; the intra-compressibility of a set of plaintexts, and the predictability of unknown plaintexts of the set from known ones, are equivalent measures of informational entropy.
* not more than 2 identical characters in a row (e.g., 111 not allowed) * Name/Username in password (Name: Chuck Norris, username: ChuckNorris, Password: ChuckNorris#1)
These are reasons why I don't look forward to doing this and also why I'm leaning towards G+/FB/twitter/etc authentication in an app I'm planning.
For the second, I'd probably just do something like compute the Levenshtein distance between the username and password, and reject it if it passed some threshold.
Not to nitpick, but they wanted at least 3 of those 4. Is that possible with a regular expression or are we now into the custom validator territory?
(.*A.*B.*C.*)|(.*A.*B.*D.*)|((.*A.*C.*B.*)|(.*A.*C.*D.*)|(.*A.*D.*B.*)|(.*A.*D.*C.*)|(.*B.*A.*C.*)|(.*B.*A.*D.*)|((.*B.*C.*A.*)|(.*B.*C.*D.*)|(.*B.*D.*A.*)|(.*B.*D.*C.*)|(.*C.*A.*B.*)|(.*C.*A.*D.*)|((.*C.*B.*A.*)|(.*C.*B.*D.*)|(.*C.*D.*A.*)|(.*C.*D.*B.*)|(.*D.*A.*B.*)|(.*D.*A.*C.*)|((.*D.*B.*A.*)|(.*D.*B.*C.*)|(.*D.*A.*B.*)|(.*D.*A.*C.*)If you enforce all kinds of weird password rules to the user, he will have to write the password down somewhere, because one couldn't possible remember all passwords. And for non-technical users that means some random pieces of paper or post-it notes. On the other hand, encouraging them to come up with something that is strong makes it more likely that they will invent a password that they can remember, thus making it more secure.
That's the approach I follow in my projects.
I offer a Javascript (window.crypto powered) Diceware passphrase generator and use zxcvbn to let users know the relative strength of the password they've supplied.
I've also been planning an experiment to see if the width of a password field results in users choosing longer passwords, because more empty space. :)
I'm going to use the appeal to authority argument, and bring over Schneier to argue that writing your passwords down isn't bad: https://www.schneier.com/blog/archives/2005/06/write_down_yo... (and others posts since, google "schneier writing passwords down" or something)
Remembering your password isn't necessarily more secure, especially since it easily leads to password re-use, which is even worse.
I just love generating 3 or 4 different COMPLETELY RANDOM passwords with KeePass because your stupid password rules were written by people who wouldn't know entropy if a dictionary open to 'en' hit them square in the jaw.
Maybe just a minimum length? I too get annoyed when there are specific complexity requirements, like 'must include an uppercase letter' even though I've used a 20-character long password including numbers and punctuation.
I did come across a site that had a cuss word filter, then wouldn't let me change my password... lol. No mention of why it was an invalid password.
If you must have certain complexity requirements, spell them out. Personally, if it's over 8-10 characters (with leading and trailing whitespace trimmed off), I'll take anything... convert to UTF8 bytes before 1-way hashing...
As for using SCrypt, if it takes a modern CPU 1/2 second on a process to hash a password, then that's ripe for a DDOS against your authentication server, which is where failed attempt counts, and locking for X minutes comes in.
More generally, you could ban the top X passwords from those "most frequently use password" lists.
If a password is easy to remember, it is easy to guess, and if you reuse a password it's likelihood of being compromised increases dramatically.
There is no simple solution for this problem. Password managers make the best of a crappy and likely unavoidable situation.
Which is frankly more effort than I can be bothered with.
That said, I'm not crazy about the inherent paternalism of this sort of thing. I think allowing weak passwords with a warning is, in most instances (not including corporate IT and situations where you're requiring that the user protect your private information rather than their own), a preferred way to go. Informing people when they are making a weak password should at the very least let them make a choice about how much they care about their own security.
Our problem is that we SHA the passwords on the client side, so each password is 256 bits long. The resulting hashtable (or bloom filter) is still a reasonable size for disk storage, though.
Even in the event of a TLS leakage, we still never see your original password, and the server doesn't end up doing any more work. It's not perfect, but I definitely agree it's a great step forward.
In most cases I'd rather you had a twelve character random string written on a post it attached to your monitor than the password "password" not written down anywhere.
And yes, I agree that it is seriously annoying.
To clarify, to avoid downvotes for a non-'productive' comment, I firmly disagree since this will probably result in me having to pick a password that's harder to remember than I otherwise would. It might also might it more awkward to type quickly, making shoulder-surfing easier.
(Note that this is probably not i18n-friendly, either)