Comment by oniony | Hacker News Reader

Comment by oniony | Hacker News Reader

Parent Full thread

Even if none of the sites are compromised; even if your device is not stolen or lost; even if the sites don't use password expiration it doesn't work very well because some sites are just plain stupid with their password restrictions. Some of the things you'll face:

• Passwords that prevent double characters within the password: not ideal when using a scheme.

• Passwords with a minimum/maximum length: I've seen sites with a minimum of six characters and other sites with a maximum of eight characters. That means, to cover them all, you really have to choose a password of exactly six, seven or eight characters and even then it's no guarantee.

• Sites that prevent certain punctuation and other sites that require punctuation. That means you have to remember which sites require which.

• Likewise, sites that require/prohibit capital letters or require a mix of case.

It's a nightmare doing anything other than recording them somewhere. And recording them somewhere is not great either as you always have to carry that thing with you and, if it's electronic, remember to charge it.

Maximum length tops my list of favorite restriction, because it strongly suggests that they're keeping my password in the clear somewhere - or they used to, and just never got around to changing it.

The concept of illegal characters is tied for second. If you're handling it right, there should be no such thing - yet so many sites continue to set arbitrary limitations for reasons that aren't clear even to them.

Kind of wish I could just generate private keys for each site and not think about it anymore. (Yes, I know there are some convoluted ways to do this, but they're not particularly usable.)

THe best part is that even so many new and/or modern sites enforce the same arbitrary requirements.

I totally get what you mean, but setting an upper limit on fields is generally a good idea. Setting the limit too low sucks, but you don't really want to accept, e.g. 1MB passwords.

Why not, since you're only storing a fixed-length hash of the password?

Some browsers might not want to send the password in a POST request. Effect could be that you can change your password from browser X, but cannot login later from a different browser or after you upgraded that browser. If you are really unlucky, the browser you change it from chops off characters from the password.

Also, chances are users will not type their 10MB password into an input field, but try and paste it in. Again, the browser may silently discard a few MB of that string, or beep while you have your sound muted.

That's no reason to set max length at something small, but setting it to 1024 or so shouldn't limit anybody as long as it allows for more entropy in the plaintext password than will be in the hash you store.

Shouldn't the password be hashed on the frontend anyway...?

No. If you do that, then the password hash becomes the real password, and the exercise of hashing it serves no security purpose.

You can, of course, play some zero-knowledge tricks on the front end.

I agree and was just complaining about this to a coworker. I tried to use a passphrase somewhere, I think paypal? and it made me make my password between 6-10 characters...

A few months ago I set up an account with American Express. I was able to log in to their website from a desktop, but the Android app wouldn't let me log in. Eventually I would up talking with their tech support, having been elevated twice, and I learned that their passwords are limited to 20 characters, as well as NO UPPERCASE CHARACTERS! For some reason, I had been able to make my long, uppercase-filled password on the desktop site, but the app was lower()ing and truncating my password.

To add insult to injury, when I tried to tell the gentleman on the line what an egregious security lapse this was, he cut me off with a terrifying and patronizing explanation: "strong passwords don't matter anymore, because nowadays we have _encryption_".

American Express, get fucking real.

> maximum length

This one really grinds my gears because it also indicates that they're most likely storing your password in the clear. Hashes are all the same length.

Or worse, if they ask you to type your password into a phone keypad (eg. the 9 button stands in for [9w-zW-Z] and 0 for all punctuation). Not only does this mean they're storing your password in plaintext, but reducing the character set to just 0-9.

A major financial company does this, of all the terrible places.

It doesn't imply they're storing your password in plaintext, no.

It doesn't guarantee it, but it does imply it pretty heavily.

The alternative is that they're smart enough to come up with a clever scheme like hashing your password in both its raw form and when converted to 0-9, but not smart enough to realize how converting your password to 0-9 makes it vastly less secure.

No, it's easy for them to convert your password to 0-9 when you enter it on a regular keyboard, before hashing it. It does make it vastly less secure, yes, but it doesn't imply plaintext storage.

Isn't that what I said in my second paragraph? As I said, for that to happen, you need people smart enough to come up with that scheme but not smart enough to realize how insecure it is. Possible but unlikely. "Imply" does not require a complete guarantee.

I was talking about logical implication, which does require a complete guarantee. I didn't realize you weren't.

Does it actually make it less secure though? Consider the situations where each password is used:

1. Your password is required online where the full password must be entered and the numerically reduced password is not accepted. This results in no loss of difficulty in the password.

2. Your password is required over the phone where the password is reduced to a T9 password. Despite the fact that the solution space has been cut down significantly (by 33%^n), the password cannot be broken any quicker because the bottleneck for this case is not computational power but rather the phone system. You can brute force all of the passwords in X seconds, but this is irrelevant because you can't try more than 1 password per call and you can't call more than Y times per second.

Good points. I would still say yes, although it's not a particularly huge problem. One scenario where it could be problematic is if the password database is stolen and nobody notices. They could then potentially brute force your numeric password and then access your account by phone.

In the universe of banking this is pretty small potatoes, though. My bank uses a case insensitive comparison for passwords (!), limits them to 8 characters (!!), and silently truncates anything over the limit (!!!!!!!!!!!!!!!!!!!!!!!!!!).

They say they're fixing it. But it sure is taking a long time.

Reply on news.ycombinator.com