dumbpasswordrules.com
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.
That one is a fun one to find out.
Bonus Points: resetting the PIN had almost no security checks making it completely worthless as security
At (initial) password change they allow plenty of characters, but it is truncated without notice. After the password change, at login, it does not get truncated and you are not able to login, nor can you change your password ever again (until a password reset via mail (no email) arrives. Fun times.
Thank you for speaking up. And here it is: I don't trust you with my data.
Passwords should not be stored in a database. Period.
So how do you check a password if you can't store it? Hash it with a salt. This results in a fixed width output, regardless of the password size.
If you are setting a max password, it's because you are trying to store it as-is, which is why I don't trust you to store my data.
Edit: I also think it makes sites that do this a target security wise. It's like advertising ignorance.
“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+.
So one dump rule creates another
> 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.
The NIST guidelines are really good IMO.
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.
- must be a prime number - digits must sum to a number ending in 7
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.
from collections import Counter
from random import randint
def is_valid(password: str) -> bool:
# cannot have the same number 3 times in a row
if any(password[i] == password[i + 1] == password[i + 2] for i in range(len(password) - 2)):
return False
# cannot have 4 ascending numbers
if any(all(password[i] == str(int(password[i + j]) - j) for j in range(4)) for i in range(len(password) - 3)):
return False
# cannot have 4 descending numbers
if any(all(password[i] == str(int(password[i + j]) + j) for j in range(4)) for i in range(len(password) - 3)):
return False
# cannot have the same number appear more than 5 times
if max(Counter(password).values()) > 5:
return False
# cannot have pairs next to each other if the second pair is one number higher
if any(int(password[i:i+2]) == int(password[i+2:i+4]) - 1 for i in range(len(password) - 3)):
return False
return True
total_valid = 0
samples = 10**5
for i in range(samples):
password = str(randint(10**6, 10**20 - 1))
if is_valid(password):
total_valid += 1
print(f"valid passwords: {total_valid}")
print(f"valid percentage: {total_valid / samples * 100:.2f}%")
valid 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.
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.
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"
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.
[1] https://cheatsheetseries.owasp.org/cheatsheets/Password_Stor....
- bcrypt implementations that assume zero-terminated strings, which leads to easy attacks if you feed them raw hashes (1/256 chance that the first byte is 0, so on average every 256th user has a password that has a hash collision with with one in every 256 passwords)
- password shucking, which is where the attacker has hash(password) from other breaches (where hash is sha256 or similar), and you use bcrypt(hash(password)) (with the same hash function), which allows the attacker to bcrypt the hashes he has, compare them, and if any match can attack the much weaker hash(password).
Which is probably why their version uses `bcrypt(base64(hmac-sha256(data:$password, key:$pepper)), $salt, $cost)`. That seems complicated, bu the base64 encoding avoids the first issue, and the pepper the second. I guess that shows how easy it is to get these things wrong, even if it seems trivial.
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.
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.
So I logged out and back in and discovered that capitalization didn’t matter… neither did the any characters after the first six characters. It was a large national US consumer bank.
I sent them an email. They actually updated their system about 3 months later.
Some special characters (èéòó etc.) will have two or three different unicode code points, and using them means the server needs to either decide to mess with your password to unify the characters or accept the binary input you've submitted and hope that your other devices will input the character in the same way.
That said, if my password can't contain emoji, I don't trust your system. I've had one important service once tell me that characters like <>&; were illegal, which makes sense... if you're planning to show the password in HTML and you don't trust your sanitizer.
I've even helped someone log into a web service that needed to have every ' or " be preceded by a \. Someone must've called mysql_real_escape_string on a password there...
Note that most emoji are outside the BMP and will take four bytes per code point with both UTF-8 and UTF-16. Many are comprised of multiple code points.
The reason for this is that Japan uses a mixture of symbols that represent entire syllables (hiragana, katakana) and symbols that represent entire concepts (kanji). So they have a much higher density of information per symbol, at the expense of having a lot more symbols.
Then, when the game gets localized, input fields for names and spacing for text displays are way too short for languages written in the latin alphabet.
I assume it's a similar cause here.
For other inputs like names you're definitely right, though.
I will add our sites (Ameli.fr is already there) as well as banks.
One of the sites forbids to use your email username. In my case it is the single letter e. I had to decrease the length of the password to accommodate that, and the site was disappointed that I decreased the security.
It is truly infuriating that a problem that has a well known solution still triggers the "let's do it differently, to fuck with our customers" kind of reaction.
Who sold this dumb 'solution' to the government?
edit: I see it's on their list already. Gosh, it's horrible.
I think that's an acceptable rule? The longest password I've used was 30 characters. Does anyone need longer?
That's awfully specific that begs the question why it exists.
Same reason you'll see dollar signs and quotes often disallowed.
For those who get this better than I do, what would be the ideal set of password rules?
I wouldn't want to claim that one ideal set exists. But this one comes close. There is an often-cited XKCD comic that illustrates this: concatenating random lexicon words into a long, letter-only password (no special characters needed at all) is usually a very good password strategy.
Anything beyond that, in terms of better IT security, does not involve better passwords, but rather e.g. 2FA, Hardware tokens.
One of the dumbest I've seen is when the username has password-like requirements, like insisting capital letters and numbers.
I'll continue to try though and am evaluate ways that the site can actually help companies update their rules.
> Username is your national ID (easy to find) and your password must have up to 6 alphanumeric characters only.
Insanity. How is a system like that remotely acceptable?
to do so, requires 2fa push to okta
the push didnt come through
so i opted to insert the code manually
i opened the app to get the code but it was showing the push notification from before
i click yes to authorise, it gives an error and reloads back to same notification
i click back manually to try and get the code, it shows the code for a millisecond but then goes back to notification
restart app few times, no luck
i will try tomorrow again to update my password
This becomes super relevant in dealing with FreeIPA with its yp/NIS server component supporting systems from the early 90s. NIS broadcasts the shadow file to the L2 every two minutes, and everyone's password is truncated to the first 8 characters. Hashcat cracked 30% of a 500 user shadow file in a few days on a GTX1060.
lmao