Live data from Hacker News

Sites with dumb password rules

github.com

21–30 of 327 posts

Re: Sites with dumb password rules

#21
There are so many compliance reviewers who get stuck on our "high entropy" approach to passwords when doing security reviews for a sale. "But what about special characters? Mix of upper & lower? etc." I'm very grateful to NIST for https://pages.nist.gov/800-63-3/sp800-63b.html and Sophos for their summary here https://nakedsecurity.sophos.com/2016/08/18/nists-new-passwo... (both of which make fine references when requested). As a side point, I'm now entirely unsurprised by the near-weekly big-corp breaches that get announced given the caliber of the compliance people we encounter.

Re: Sites with dumb password rules

#23
post #5

Earlier quoted context omitted.

> WTF is hacking characters Basically anything a scripting programming language might use as a comment or sigil. Putting 'we are probably calling exec() on your password' into writing though is a boneheaded move.

Maybe they run a password report and someone had alert("lol"); as a password. Managment freaked out and demanded someone fix the hack.

Printing out people's unhashed passwords? Not cool.

Re: Sites with dumb password rules

#24
post #14

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

Re: Sites with dumb password rules

#25
Want to DDOS somebody? Try their password incorrectly three times.

Stupidest password rule ever. Rate limiting after 3 mis-attempts is understandable. That rate limit doesn't need to exceed 1m with passwords over 14 characters.

Re: Sites with dumb password rules

#26
post #14

Chase 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…

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 devils advocate here.

Re: Sites with dumb password rules

#27
post #12

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

Useful idea, but I wouldn't it be exploitable by adversaries as well (eg. knowing those constraints would be helpful for generating dictionary attacks)?

If you're targeting a specific site's database for a dictionary attack, finding out and entering the specific constraints would be minimal effort. And if you're not targeting a specific site, you probably want your dictionary to be as permissive as possible so can potentially match users on all sorts of sites.

Re: Sites with dumb password rules

#28

The interesting thing about some of these is that you can instantly spot instances where they are storing the password in clear text. For instance, case-insensitive passwords. EDIT: I guess they could be converting to lowercase (or uppercase) every time before hashing, as multiple people pointed out. If that's the case though... fine, let's pick one of the first instances in that site (not mentioning by name). Why ca…

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.

Re: Sites with dumb password rules

#29
post #4

You can always trust State Bank of India to pick the worst possible process and phrase. WTF is hacking characters ?

Presumably something like “; . Characters that get used in XSS/SQLI. Totally the wrong defense, of course

Please don't put anything in here that might harm us, because we're inserting these characters directly into our totally secure password database, which also happens to contain all of your biometrics. We use firewalls and lots of red tape, so it's all very safe.

Re: Sites with dumb password rules

#30
post #12

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

Useful idea, but I wouldn't it be exploitable by adversaries as well (eg. knowing those constraints would be helpful for generating dictionary attacks)?

No, because attackers can easily determine the constraints (assuming they are kept "secret") by signing up for an account on their own.
Post reply on HN