I've created a compilation, along with many great contributors, of sites with dumb password rules. This has long existed as a simple README on GitHub, but was just transformed into a full-fledged site.
Dumb password rules annoy me very much. If they annoy you, too, feel free to contribute!
Feedback, comments, criticisms, contributions welcome.
I'd like to submit all the sites that disable copy/paste on their password entry, especially if they have stringent password content policy.
My randomly generated 10 word passphrase is more secure than your password policy, but I don't want to type it in by hand, you donkey.
“We want to make sure the user gets this right. So instead of letting them just hit Ctrl+V let’s make them type the whole thing, introducing all sorts of possibilities for errors!”
Oh, let me get out my bifocals and checkbook that I copying from... and definitely not my online banking we've had for two decades+.
That one is a fun one to find out.
> Coil
> Does not allow simple characters and sequences such as '4587' or 'efgh' in password & necessarily requires numeric values.
or Apple’s requirement that you cannot have more than 3 consecutive characters, seem reasonable to me. Certainly these rules ban perfectly fine passwords, but they’re a lot better than something like “must be between 8 and 16 characters and contain one uppercase, lowercase, number, and special character, but not these special characters, and it also cannot have an edit distance of 3 from your user ID”
This, naively[0], is all requirements except minimum length. Every requirement reduces the problem space for would-be attackers and increases the cognitive burden for users.
[0] I recognise that with many modern techniques, password-cracking utilises common patterns rather than a brute-force approach.
- Must be all numerals.
- Be 7 to 20 digits.
- Cannot have the same number three times in a row.
- Cannot have four ascending or descending numbers.
- Cannot have the same number appear more than five times.
- Cannot have pairs next to each other if the second pair is one number higher.
- Cannot be the same as 8 previous ones.
It would be fun to work out mathematically how much they're limiting the password space with these rules. I'm also not sure what "Cannot have pairs next to each other if the second pair is one number higher"; is that referring to consecutive pairs of numbers, or pairs of consecutive numbers, e.g. 7788 vs 7889.
Just further proof, really, that overly restrictive password policy leads to users adopting insecure password practices. But we've known that for ages -- and, indeed, the password policies we were grappling with at work were in direct defiance of NIST guidelines about password policy.
That we’ve spent decades trying to add abstruse rules and training people to “do it right!” rather than provide a mechanism speaks to the psychology of security people.
Buy people a box of tiny dice; have them make a game of a new pass phrase… that they can actually remember.
Eg, this box which fits in your palm — and gets ~50bits per shake.
https://zmichaelgehlke.com/images/dicebox.jpg
The NIST guidelines are really good IMO.
Alright, you nerd sniped me, but I'm lazy so I just simulated it, this cuts down the password space by ~35%. I didn't take into account passwords with leading 0s in my sampling, but this shouldn't change the result by much.
valid passwords: 65045valid percentage: 65.05%
I still question the interpretation of:
> cannot have pairs next to each other if the second pair is one number higher
But I think the outcome would be the same either way.
- must be a prime number - digits must sum to a number ending in 7
Seems like it would be nice to have the actual set of rules next to each example, and to be able to page through the examples.
I also find having to page through the home page a little odd.
The splash page would make more sense if it had some brief description of why sites end up there--and maybe some guidance of making decent password rules.
https://dumbpasswordrules.com/sites/caf-french-family-allowa...
It looks crazy but actually I think they were trying to solve an insolvable issue. The population that will want to use this website is basically anyone who has children in France. That will include some very computer-illiterate people using god knows what public devices, some of them, very likely infected with all malware known to mankind.
They came up with this: have people click on numbers whose place change all the time and whose real values (beside the image shown) are server side. They probably hoped that it would protect the users from at least basic keyloggers attacks.
It's easy to watch someone unlock their phone with a PIN or gesture, steal the phone and open it later if the location of the keys never changes. Especially if the fingerprints are left on the screen.
If we can make this work with soft materials like rubber, it'd also be a defence against skimmers. It's trivial to see someone's PIN on a payment terminal even after they've already left the store if the keys don't immediately disappate body heat. Aim an infrared camera at the keypad and you'll see which keys were pressed, sometimes even in what order.
1: https://jkcorpeng.imweb.me/japan_doorlock/?idx=53
With that said, a lot of these seem pretty reasonable. The one that I really don't get that keeps appearing is max length though. I get that they may not want to allow you to have a 10MB password but I think a reasonable max like 500 characters would be better. A max length of 8 makes me think they are storing the unhashed password in a VARCHAR.
Also, from a UX perspective some of these rules may be best to only tell the user about if they actually trigger it. Like "most not contain username" is uncommon enough they can probably only show it if it actually happens. Same with "cannot reuse last 4"
This is fine if you have reasonable password policies, but I've run up against incredibly frustrating password requirements that were hidden until I triggered them. The workflow went like this:
Password manager generates a password, attempt to submit. "Password must be less than 20 characters"
OK, regenerate a new password at 19 characters. "Password must include at least one special character."
...OK, add special characters in the list. "Password cannot contain %."
If they just told me all of the rules at the beginning, I could have made sure my password worked the first time.
I was referring more to the "cannot be the same as last 4" policy and things like really long password lengths (too long to expect a reasonable person to type in). If your max length is, say 500, you probably don't need to include it in a long list because a reasonable person would never hit 500.
Bcrypt is outdated but still widely used, I reckon.
Edit: Also as OWASP suggestions (I thought of it but wanted to verify if it was OK before I posted)... if you're using Bcrypt you could hash it with something like sha256 before running it through Bcrypt to get around the length limit.
Edit: mistyped "bit" instead of "byte" :(
Though 72 or 36 characters max really isn't so bad.
While it’s unfortunate that the particular string is not localized (it means please enter new password), this is not gibberish. Other languages are not gibberish
I would like to think we progressed a bit but recently I worked for another company which required that we use our company domain password to log in to test linux servers. The issue is that everybody has root access on those servers. I implored that it is not safe and there should be separate accounts to access those servers but of course nobody would hear it.
So I wrote a script which intercepted all logins and passwords of people logging in to our test servers and then sent to the manager responsible for it. Well... they wanted to fire me for "hacking" their servers and I had to explain to them that once you have root on a server there really is not much they can do to prevent me from stealing passwords.
The end was they did not understand anyway and I was barred from accessing test environments. They also changed the linux distribution and "hardened" it because the old one "must had security vulnerabilities".
Fortunately, I soon changed the job again.