obligatory thread naming good open-source password entropy checkers. I'll start.
Sites with dumb password rules
41–50 of 327 posts
Re: Sites with dumb password rules
#42Strange to see a .gov.uk site on there ( https://github.com/dumb-password-rules/dumb-password-rules#h... ) as they have excellent guidance on this https://design-system.service.gov.uk/patterns/passwords/
Re: Sites with dumb password rules
#43It would be nice if there was a HTML standard for specifying password requirement data, like length ranges, valid/invalid characters, character type requirements(3 letters, 1 number, 1 special character), etc, so that password managers/generators could use it to always create a valid secure, valid password for you.
There is. The `pattern` attribute lets you specify a regex for an input field - including password.
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...
Re: Sites with dumb password rules
#44Chase Bank: Must not include more than 2 identical characters (for example: 111 or aaa) Must not include more than 2 consecutive characters (for example: 123 or abc) First, they apparently mean repeating and not identical characters. But more importantly, perfectly random character strings frequently contain repeating and consecutive characters, so this rule must reduce the entropy of passwords. ------ Edit - Just si…
Does it reduce the entropy of passwords in practice or just in theory ? It could be that in practice if you let users repeat characters they will do so more often than random chance would allow for, thus making their passwords predictable to some degree. Thus, prohibiting that practice would increase the randomness of passwords actually getting used.
My 16-char alphanum generated password for Chase had an equivalent of "rST" in it. I can never remember which password modification I ended up with, and "can't choose the same password as your previous 4" gets real old real fast.
Re: Sites with dumb password rules
#45Honestly, I'm past caring about upper length limits, however stupid they are. What really pisses me off is not validating on it, so my too-long password is happily accepted, and I have no idea what it is except that it's some prefix of the one I saved.
I've switched almost entirely to diceware passwords and the too-long thing is a major PITA.
Re: Sites with dumb password rules
#46Honestly, I'm past caring about upper length limits, however stupid they are. What really pisses me off is not validating on it, so my too-long password is happily accepted, and I have no idea what it is except that it's some prefix of the one I saved.
Silent truncation. This becomes worse when you realize that a companies web login vs mobile have different hard lengths, in this case it was mint.com. They allowed 16 online and 32 mobile, after letting them know they thankfully made it consistent at 32. Which isn’t perfect but it’s far better than most
I've encountered other weird bugs in mint too. On one site they wouldn't let me enter an email address as a username for a website which used your email as your username. Editing the DOM to remove that front-end validation worked, which was also disappointing, but at least it worked.
Re: Sites with dumb password rules
#47My favorite dumb password experience involves EZPass, a system for paying tolls without cash, in New York.
I signed up for EZPass using a relatively “long” password (20 chars). I then received a letter in the mail about a toll I had to pay, even though I’d had the EZPass at the the time. But, the letter said, I could pay the toll by logging in to their site and using my EZpass credentials. Didn’t use OAuth but I figured it would be OK. I input my username and password using my password manager but it didn’t work. Pretty strange, as I was able to log in to the “main” EZpass site using those same credentials. I tried logging in on the payment site again to no avail. Finally I realized that my password was being truncated by the password input field itself.
The solution was to inspect the page and change the maxlen attribute of the password field.
Re: Sites with dumb password rules
#48Earlier quoted context omitted.
doesn't any rule decrease password entropy?
The maximum possible entropy is in a sense sampled by users various passwords. The sampling can be biased, so rules can technically eliminate such biases and lead to higher effective entropy. Furthermore, there is a benefit in forcing the user to not share the same password across multiple websites which can be achieved by imposing extra (or ideally mutually exclusive) password rules. Of course I am just playing devi…
What's hell is not being told /at login/ what the unusual restrictions are.
Re: Sites with dumb password rules
#49Earlier quoted context omitted.
Not necessarily. They could run str.lower() on the password input before hashing and saving the hash. Then to verify the password, you just always run str.lower() on the input before calculating the hash.
I haven't checked lately, but I understood that Facebook passwords are case-insensitive.
IIRC Wells Fargo passwords used to be /partially/ insensitive. Like, just the first half was to_lower.
Re: Sites with dumb password rules
#50Earlier quoted context omitted.
Silent truncation. This becomes worse when you realize that a companies web login vs mobile have different hard lengths, in this case it was mint.com. They allowed 16 online and 32 mobile, after letting them know they thankfully made it consistent at 32. Which isn’t perfect but it’s far better than most
I've encountered other weird bugs in mint too. On one site they wouldn't let me enter an email address as a username for a website which used your email as your username. Editing the DOM to remove that front-end validation worked, which was also disappointing, but at least it worked.
Oh! Related gripe - registration and login having different validation, removing it in the frontend 'fixing' it...
I've been able to supply my 'too long' password more than a few times that way, and it's transpired that actually it clearly was all stored on registration.
So on a whim I've tried it when registration's failed, and sure enough it's been stored, and then not validated on login.
It's so easy to do better, just don't do it in the frontend!