Readit News logoReadit News
Posted by u/duffn 3 years ago
A compilation of websites with dumb password rulesdumbpasswordrules.com/...
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.

gorjusborg · 3 years ago
I absolutely love the concept behind the site.

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.

NickBusey · 3 years ago
Disabling paste anywhere is a cardinal sin.

“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!”

madamelic · 3 years ago
My favorite is when sites completely disable pasting my bank account number.

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+.

_fat_santa · 3 years ago
I wonder, what is the rationale for this "security feature"?
gorjusborg · 3 years ago
Oh, and if you have a maximum password length, I don't trust you with my data.
madamelic · 3 years ago
Only surpassed by _having_ a password length then truncating it to fit rather than throwing an error at registration.

That one is a fun one to find out.

reidjs · 3 years ago
You can’t just let users paste in 18,000 characters you need to limit the password length somewhere. But I agree a limit less than 255 chars is insane.
duffn · 3 years ago
I'm glad you enjoy it! If you have any sites you like to add, please feel free to contribute. https://github.com/duffn/dumb-password-rules/blob/main/CONTR...
amlozano · 3 years ago
TreasuryDirect.gov should get a special callout for forcing you to use an on screen keyboard to click your password, with of course paste disabled.
armchairhacker · 3 years ago
Suggestion: add a rating system, because some of these are more dumb than others. Also add an indicator or separate rating for requirements that make the passwords too easy to guess like “no more than 8 characters”. e.g.

> 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”

jwestbury · 3 years ago
> Also add an indicator or separate rating for requirements that make the passwords too easy to guess

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.

duffn · 3 years ago
Good idea! I've added an issue for discussion here: https://github.com/duffn/dumb-password-rules/issues/445
MetaMalone · 3 years ago
+ 1. Let me filter by most to least insane.
JasonFruit · 3 years ago
ME Bank is the best:

- 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.

jwestbury · 3 years ago
I saw some similarly obtuse password policies when working in the defense industry. A coworker who had spent much longer than I had in the industry showed me what he called "the waterfall method" of password generation. That is, your password would be something like 1Qaz2Wsx -- a waterfall down the keyboard, if you will. You could always tell when he was typing in his password by the staccato tapping of keys.

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.

zmgsabst · 3 years ago
The hard part was always password generation.

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

leetrout · 3 years ago
Very common password methodology to remember the pattern on the keyboard like that.

The NIST guidelines are really good IMO.

elesiuta · 3 years ago
> It would be fun to work out mathematically how much they're limiting the password space with these rules.

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 passwords: 65045

valid percentage: 65.05%

JasonFruit · 3 years ago
I'm glad I sniped you before I sniped myself!

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.

zamadatix · 3 years ago
Really the only place the amount of excluded password space matters is at the minimum length, which is conveniently brute forceable. Without padding 0's that comes to 91.63% valid, with padding 0's 91.42%. Smaller spaces are going to hit the repeat rules less often so the wide difference in percentages should be no surprise.
gs17 · 3 years ago
At that point they might as well add some more interesting ones

- must be a prime number - digits must sum to a number ending in 7

mrleinad · 3 years ago
Do they at least tell you which one you're failing to comply with, or do they just let you figure it out on your own?
duxup · 3 years ago
Most of those rules sound like rules that came about because of the first stupid rule.
baal80spam · 3 years ago
This reads as if someone was throwing darts at the board with random rules.
duxup · 3 years ago
More like they came up with one dumb rule…. and had to make the other rules to cover for it.
postingawayonhn · 3 years ago
I think they mean like 7879.
SamBam · 3 years ago
Nice, but displaying this as a gallery seems to make it harder to quickly parse all of these. The rules are all just images some hard to read at that scale, and some cut off. If you click on one, you can't page to the next, you have to go back to the gallery and click on the next.

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.

thesuitonym · 3 years ago
I bounced pretty quick, because as amusing as it was, seeing a site and then a cut-off sentence about why it was there was not the best presentation.

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.

duffn · 3 years ago
Thanks for the feedback, the gallery seems to be not well loved, so will be re-evaluated.
duffn · 3 years ago
Good feedback, thanks! Pagination through items would be a great addition and the gallery seems to be not loved, so will be re-evaluated.
lelag · 3 years ago
The French Family allowance is an interesting case.

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.

jeroenhd · 3 years ago
These types of character input screens do help against some forms of shoulder surfing or maybe even phishing, but only if your password is random and long enough for it not to be brute-forcible. The problem with this method is that most people will keep their passwords short if you make them more difficult to enter.

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.

wongarsu · 3 years ago
Some physical keypads have a screen behind the keys to shuffle the positions of the buttons (e.g. [1]). That defeats many attacks, including recording the hand movement or infrared cameras (you can see where the person pressed, but you don't know the number that was there). Alternatively you can heat the keypad to reduce the difference between body temperature and keypad.

1: https://jkcorpeng.imweb.me/japan_doorlock/?idx=53

lelag · 3 years ago
An 8 digit code coupled with a gradual rate-limiting system offer probably a decent security trade-off for such a service. They probably use an all digit code so that people can authenticate easily over the phone.
throwaway2016a · 3 years ago
This is what happens when compliance rules force sites to have specific policies. Especially when you have more than one set of rule combined.

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"

thesuitonym · 3 years ago
>from a UX perspective some of these rules may be best to only tell the user about if they actually trigger it.

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.

throwaway2016a · 3 years ago
Yeah, kind of a lesser of two evils sort of thing. Though immediate validation client-size would help. The best UX would be to just not have ridiculous rules like "cannot contain %"

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.

diarrhea · 3 years ago
Cryptographic password hashing functions such as bcrypt have relatively low maximums. Bcrypt sits at 72 characters, which if you used 4-byte UTF-8 is pretty short, for example.

Bcrypt is outdated but still widely used, I reckon.

throwaway2016a · 3 years ago
I actually didn't know that about Bcrypt. Good to know! Thank you. Though, 72 (18 if using 4 byte) would still be better than 10.

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" :(

wongarsu · 3 years ago
Wouldn't this be easily solved by giving bcrypt the sha512 of the password?

Though 72 or 36 characters max really isn't so bad.

zht · 3 years ago
“ Also, this gibberish if you intentionally left the "confirm password" field empty and that's even after a en_US redirection. 请输入新的登录密码.”

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

twawaaay · 3 years ago
My favourite was at one of the companies I worked for. The admin decided that users are not to be trusted to choose their own passwords and so you had to mail the admin to generate the password for you which you then could not change on your own -- you had to mail him again. The password had to be changed every month and an email would go to entire company to change passwords before the guy goes on vacation.

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.

seanw444 · 3 years ago
What's the point of hiring professionals if you're not going to take their advice, and treat them as hostiles? I find it so strange that I hear about so many companies that actively work against themselves on here.