Password Rules Are Bullshit

So why isn’t “correct horse staple battery” a good password again? I can type 100 wpm, why not just let me have a passphrase? So many sites enforce all these stupid rules, but then limit the password length to fifteen characters, and often ban spaces. It is maddeningly stupid.


I think the most correct way is to tell person if his password is bad or not. I mean when you have rules, you just do something like “Aa1.$aaaaa” to comply to all rules, and then you’re pissed off and your password still sucks.

1 Like

I totally agree that arbitrary password rules are not a good thing, they frustrate users to no end, and can make things less secure.

I really liked the zxcvbn library from Dropbox, as it allows you to catch those really egregiously bad passwords before it’s too late, but is much smarter than any list of arbitrary rules could be. I actually wrote a similar library (nbvcxz) for my company which implements all of the functionality of zxcvbn (and extends it as well) so I could use it on the server side.

1 Like

I’ve been using LessPass recently, which is similar to your solution I think. There’s a master password which is combined with your account login details to generate a unique password deterministically. The actual master password is never stored on a server, and the password is regenerated each time you need it.

There is an opt-in server component to store special per-site options (username, password options like length or allowed characters) but you can self-host that too if you want.

1 Like

On a financial site I use, asterisk (*) is not allowed, even though special characters are required.

On learning this, I spent some time trying to enter various bash scripts & SQLs as my password, out of curiosity. Has nobody heard of Little Bobby Tables ?!

1 Like

What’s even more dangerous with passwords rules is that people are most likely to forget it, and just use the reset my password option through email, defeating the purpose of a strong password to begin with.

1 Like

This blog post continues the same pattern I’ve seen repeated since the beginning:

  1. Shame existing password validators
  2. Suggest yet another password validator

The solution to this problem eludes most people, because most people have a propensity to babysit others. The solution is to stop validating passwords altogether. If we stop babysitting people and allow the natural economics of the situation to govern it, we’ll begin to see more people educated in the science of creating good passwords.

The natural response to this is probably something like,

That’s great and all, but we can’t afford to let people lose their bank accounts and livelihoods based on some libertarian idealism.

to which the natural response is,

A) People already are losing their things, since as we’ve determined time and time again, password validators are only relevant until they aren’t, and B) most people lose their accounts because of social engineering, not because of data leaks and then subsequent password guessing (and especially not because of simple password guessing, since CAPTCHAs handle that).


One of the other things that really get my goat is when the password rules are explained to me, as a user, after I enter a password that doesn’t match them. Or even worse, if there are a set of rules I must follow, but the site only tells me the specific one I violated. Grrrr.

So…put some mechanism in place where I can see the password criteria before I take my first crack at creating one.

1 Like

I think that we need to add the 4th factor of authentication: Someplace You Are. Instead of a password, ping the user’s phone, and if it is more than 1000 meters from where they are trying to log in, they cannot.

1 Like

For another good analysis, take a look at Klaus Post’s excellent password requirements article.

He has developed a Go library for checking passwords against a dictionary, and provided a combined dictionary from several leaked databases with >1b entries.

Regarding password entropy (aaaaaaaa) you could consider running a compression algorithm over the password to check that it is suitably random: a good password should probably be incompressible. Passwords may still be too short for this to be a good estimate though. See also Kolmogorov Complexity.

1 Like

Exactly what I thought and expressed here too. Validation is bullshit but you should validate at least this and that.
Just let people decide themself and take the fucking consequences of their weak passwords.

1 Like

That requires every site you log into to have access to your GPS location. Probably not a good idea.

I don’t have GPS enabled on my phone, and I never enable location checking when I browse. But the “guesstimate” of my location is still good enough. The idea is to reduce the circle of attack from 20,000 Km to about 1. We got by with locks on our doors up to now because no one could steal your stuff unless they physically went to where your stuff was. Now, our digital stuff is “nowhere” and so are we, so the circle includes everyone on Earth. Bad design from the start. Make it physical, somehow. If someone steals ME I have bigger problems.

+1 for zxcvbn. Does a great job of estimating the entropy of passwords without imposing any particular rules.

No need to worry about length, symbols, or any other arbitrary rules. Just disallow weak passwords.

1 Like

I’ve another hint, for site developers: DON’T STORE THE PASSWORD IN CLEARTEXT. Run it through crypt() or SHA256 (I have no expertise in what’s the most secure way to do this) and store that. Unix has done it this way since it was two guys with an abacus. This way if your password list is stolen, at the very least it’s going to take some work to get the passwords out of it. It always appalls me how many sites’ password recovery screens actually show you your cleartext password instead of making you reset it.

This is why I’m a fan of passwordless login. Don’t even give your users the option of creating a password…


Don’t use SHA256 or crypt… while they’re better than clear text (which is beyond appalling practice) those are not very good for password hashing because they are way too fast.

Use something like Argon2, Bcrypt, or Scrypt (with a high enough rounds for each to make it relatively slow):


Because it uses 4 (common) dictionary words, and thus is fairly easy to break.OTOH, if you added some additional entropy, like misspellings (not standart letter -> digit substitutions), it might be safe enough.

There are some sites I use non-english passphrases and I feel quite safe about them.

Any reason why “aggressive” rate limiting can’t be “super aggressive” if a password matches one from the common list?

So instead of doubling the timeout (or whatever) between attempts, an attempt to use a password matching one in the list will give a 10x or 100x timeout?

If it’s a genuine user then the extra delay after trying ‘qwertyuiop’ instead of the ‘qwertyuiopILOVEBEER’ they changed it to when told that their initial choice was insecure might give them some time to ponder their life choices, but will likely not stop them getting in eventually.

An automated hack though will quickly run into an effective brick wall after only a few failed attempts and the timeout has reached a few hours.

1 Like

Any rule that reduces the attack space makes the password less secure. Until you throw in the fact that people are not random. Then you have to start eliminating the common entries. Holders of less than stellar intellect are going to continue to have control over password rules. The only hopes are better standards and education.

Sort of off topic: For true moronicity take Verizon. I kept having to rest my password every time I returned for a newly created account. It seems that the password creation system will accept 21 characters. It will however NOT STORE ALL OF THOSE CHARACTERS. So, when I went to log back in on another session my password would not be valid and I would reset it to something with 21 characters. Rinse, repeat. Technical support was totally useless and I finally figured it out myself.