“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!”
Wise for example, allowed me paste the password for creating account or changing the password. Password was 20 characters long, but seems like they cut it on client side or backend to 15. So when you login, it does not cut the password, and I never could figure out why I could not login in some places.
T-Mobile has a fun one. When creating the account they let me set a IIRC 6 digit account security PIN, but when setting up online access they only accepted a 4 digit PIN necessitating a call to customer service to reset the PIN.
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.
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.
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”
> 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.
- 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.
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.
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.
People don't want the mechanism either because the root problem is the misaligned incentives in that a secure password is always more work to use compared to an insecure password. Recently the push for passwordless authentication has been tackling that.
> 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}%")
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.
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.
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.
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.
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.
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.
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.
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"
>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.
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.
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.
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.
Interesting, that page links to two problems that can appear:
- 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.
“ 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
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".
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.
The most absurd example is the US government TreasuryDirect[1]. No password input box to provide your password. You have to use an absurd virtual keyboard abomination. ProTip: Go into developer tools and just paste your password into the value attribute for the password form field.
I was worried about this when I started using TreasuryDirect, but fortunately Kee[0], a KeePass-compatible browser extension, fills it in automatically so you don't have to bother with the virtual keyboard.
In the late 90s I remember signing into my bank account and being sure I mistyped my password.
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 of these rules make sense. For example, bcrypt (still secure enough of you pick a decent amount of iterations, though you should really be using something more modern like argon2) will take a maximum of 72 bytes. In a Java, Javascript, or native Windows based system, that could easily mean a maximum of 36 characters unless you do some risky unicode conversion (UTF-16 to UTF-8). With unicode you can spend three bytes on a character if you use the right (wrong) ones and that doesn't even touch the upper character codes that some systems can't represent. Upgrading systems to use modern hashing algorithms isn't always easy or even necessary as long as you pick your parameters well, but this does limit the input of your system.
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...
> That said, if my password can't contain emoji, I don't trust your system.
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.
This is actually a problem plaguing old ports of Japanese video games, sometimes even to this day.
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.
For passwords this doesn't work, as the Japanese IME requires visual feedback to pick the right characters. As far as I understand, password fields don't support foreign script very well.
For other inputs like names you're definitely right, though.
Such a website is immediately les funny when you live in a country where all institutions and banks have idiotic rules (namely France).
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.
The stupidest login I've seen to date is the US Treasury's TreasuryDirect website. You can create your account using your password manager that kicks out a secure password, but when you go to log in, you have to use a stupid virtual keyboard using your mouse, so you can't type your password in. You have to use your mouse to click buttons on a virtual keyboard.
Who sold this dumb 'solution' to the government?
edit: I see it's on their list already. Gosh, it's horrible.
I wish there were a web standard for sites to describe their password policy in a machine-readable format. Password generators could generate compliant passphrases, and this site could be programmatically generated, which hopefully would become a wall of shame encouraging sites to improve.
Because someone couldn't be bothered to parameterise their queries, and, as such, is explicitly rejecting characters which are used by some underlying language they're working with (or Windows environment variables, I suppose).
Same reason you'll see dollar signs and quotes often disallowed.
My dumbest experience was a Japanese local paid VOD website. It only allowed FOUR ALPHANUM CHARS for password in 2018. I suspect that they want to make it easy to input with TV remote. Fortunately they relaxed limitation now.
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.
I've previously had somebody from Microsoft reach out to me directly about their entries and had somebody from RedHat create an issue, but I don't think either actually took action.
I'll continue to try though and am evaluate ways that the site can actually help companies update their rules.
Many banks in Spain have the same exact restrictions. My guess is somebody sold the same shitty COBOL backend to everyone back in the 60s, and they keep running it with different HTML layers slapped on top.
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.
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.