Live data from Hacker News

Sites with dumb password rules

github.com

221–230 of 327 posts

Re: Sites with dumb password rules

#221
post #53

Not surprised to see Sparkasse (German Bank) here, their password rules are horrible, they cap it with 5 chars which is insane. I hope if someone gets hacked they will be able to sue the them because of their archaic security practices. p.s. would like to use this opportunity to also complain about their non-english English dashboard, god I hate it.

If only they were the only ones! Consorsbank (BNP Paribas) also has a limit of 5 chars, and comdirect even has a limit of 5 decimal digits. The IT security incompetence in banks in .de is just insane.

> comdirect even has a limit of 5 decimal digits

Hm, sure? My comdirect account uses a 6 digits pin. Never tried to use more than that. But 6 were still horrible enough when looking at the fact, that SEPA transfers of up to 30 Euros don't require entry of a TAN. A feature, which can't be disabled. Hate comdirect for that move.

EDIT: feature, not option. :)

Re: Sites with dumb password rules

#222

Earlier quoted context omitted.

Why not have one round of hashing in the browser? That way the input to your server-side hash function is fixed-length, whether the users password is 20 characters or 20 billion, and DOS attackers are only hurting their own computers.

Wouldn't that just turn the attacker's problem into brute forcing the client-side hash? Might be a problem if the client-side hash has a lower total complexity than the longer original password. I dunno though; just pondering out loud, I'm by no means an expert on this stuff.

Yes, obviously.

So you choose something like 1024 bits as the length of the client hash. The client hash doesn't even need to be any good, even xor-ing blocks might work. It just needs to preserve a lot of entropy.

Re: Sites with dumb password rules

#223

Earlier quoted context omitted.

Reasonable upper limits don't bother me all that much. If you're going to store a hashed password, you want to choose an expensive hash algorithm (It's been a while since I looked at this, but I don't think bcrypt is standard anymore?) and that complexity is meant to be computationally ridiculous, and probably scales with length. Good security dictates a minimum length, and practical avoidance of your login form bein…

bycrypt has a limit of 72 bytes (not characters) and possibly less depending on the specific implementation. Theoretically this could limit you to only 18 characters if your password is utf-8 encoded emoji (4 bytes per character). This can be worked around by the server hashing the password using a fast hash before passing it to bcrypt but this risks reducing the security of the password.

No, this doesn't reduce the security of the password at all, if your first fast hash is well distributed.

Eg use the first 72 bytes of SHA256, if you like overkill.

Re: Sites with dumb password rules

#224

Many complaints are that non-ASCII characters (which all but one European languages have natively) are not allowed. While I agree that allowing them would be good for password security past experience has made me paranoid. Not all systems handle non-ASCII the same way, so when you change browsers or they upgrade their system your password might no longer work. Today Unicode is used a lot so it gets better, but it's s…

Lots of them also ban space.

Re: Sites with dumb password rules

#225
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…

It's a naive approach, and also honestly, in my personal experience with banking software, these rules are not selected through some careful secops research, but are usually arbitrary picked to sound smart to managers and be easy enough to implement by devs. Bad passwords should be addressed specifically, because having "ijk" or "777" somewhere in you 40chars long random sequence is not really a vulnerability. On the other there are many bad passwords that are not made of sequential numbers, say "qwerty" or "asdfghjkl" or "sunshine". There're so many data dumps these days that it's easy to create a blacklist of popular passwords and block it, without giving headaches to users with password managers just because their safe random password happens to have a wrong number of these or those chars.

Re: Sites with dumb password rules

#226
post #189

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…

The one that actually tells you they store plaintext passwords is when it can't be close to previous passwords.

They are some ingenious ways to make that judgement without storing plaintext passwords.

But you are right, that none of those companies do that.

Re: Sites with dumb password rules

#227
post #147
post #47

My 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 figu…

Not a password but slightly related, had to use western union to send money for a friend last year and on their credit card page someone tried to be smart and failed, it checked for they key pressed to ensure only numbers but didn’t account for the fact that not everyone use QWERTY (on a French azerty you need to use shift to use the top row of numbers, without shift it’s accented letters and the like). I kept thinki…

Just bad code where they took the actual key codes being pressed not the characters they map into, which made the code reject anything with shift pressed.

Re: Sites with dumb password rules

#228
post #54

Hi, I made this. It seems like most of you are as enraged as I am about some of these password rules. They just flat out make me mad. It's not much, but I've actually had one company reach out to me after making it on the list and they made their password rules less dumb. So, if you find any particularly egregious offenders, do your part and submit a PR. It may actually make a difference.

I am actually appalled and baffled at American Express not applying case sensitivity. Like, what the actual.

I literally couldn't apply for an American Express card about 15 years ago because my (ISP) email address was too long. I wonder why they chose to restrict it rather than go with the standard email max length; they had to put effort in to pointlessly restrict new signups. Odd.

Re: Sites with dumb password rules

#229

Natwest has a really annoying password system where you have to enter certain characters of your password. LLoyd's Has another system where you can create a password you like, and then you have to create another second password that they ask you to take certain characters from (e.g. 1st, 3rd, 9th character), oh, and it's alphanumeric too.

Loads of places do that (both methods). What's wrong with that? It provides (some) protection against keyloggers and means you have to type in fewer characters.

Re: Sites with dumb password rules

#230

The most hilarious rules I've encountered were for a large, well known US hospital: * Password must be EXACTLY 8 characters long * Password must start with a letter * You must use exactly 3/4 of the following: upper case, lower case, numbers, one of three special characters * Password cannot "resemble" username or past password

"Password cannot "resemble" username or past password" So they're storing passwords in plaintext somewhere then? Otherwise how would they know?
Post reply on HN