It seems reasonable to enforce a size-limit on passwords, but in the order of kilobytes, not a two-digit number of characters. Perhaps 64 KiB, to commemorate Heartbleed.
Bad Password Policies
11–20 of 45 posts
Re: Bad Password Policies
#12Please someone set up a tumblr for these.
Paypal has a max of 20 chars.
Re: Bad Password Policies
#13I'm always scared when I see the maximum length limit in password. I expect they just put clear text in their DB. Otherwise why would they limit it? Any key deviation or hash function will give the same length, regardless of the password length. Scary ...
Maybe they're just trying to protect against denial-of-service attack through very long passwords[1]. Although 16 or 20 characters seem too short. [1] https://www.djangoproject.com/weblog/2013/sep/15/security/
Yes, it's probably actually necessary to introduce some kind of limit to protect the server against hashdos-type attacks. Sadly though, Occam's razor suggests that the "20 char" limits and ridiculous "alphanumeric only" restrictions are caused not by some advanced considerations but by something much more stupid and incompetent.
Re: Bad Password Policies
#14I think the OP should name and shame the site that takes passwords over a non-secure connection, stores them in plain text, and silently truncates long ones. Maybe that would get them to fix it.
That could do more harm to the site users than the site itself. Especially with people sharing passwords between sites.
I guess that's an example Full Disclosure vs (as an alternative) Coordinated Disclosure; http://en.wikipedia.org/wiki/Full_disclosure_(computer_secur...
Re: Bad Password Policies
#15Honestly, I don't get why a service would enforce a password policy at all.
They should warn users about what makes a good password, and tell them when their password sucks ("your password is weak and would be crackable in 3 minutes") but if someone wants for some reason to use 123456 as a password, that's their own problem.
Re: Bad Password Policies
#16I have one question. Even if we use hashing and random salting, then should we make some max-limit on the password. Its not related to the length i want to store, its the length that system will convert to a hash. Will very long passwords be hashed in equal time ?
> Will very long passwords be hashed in equal time ?
No. This allows for DOS if there is no limit whatsoever: https://www.djangoproject.com/weblog/2013/sep/15/security/
But acceptable limits are in the kB range, not in the double-digits bytes range
Re: Bad Password Policies
#17I think the OP should name and shame the site that takes passwords over a non-secure connection, stores them in plain text, and silently truncates long ones. Maybe that would get them to fix it.
Microsoft used to truncate live/hotmail passwords silently to 16 chars pre-hash, I recall them announcing the change to an upper length of 16 a while back.
I doubt they're the ones storing passwords in plaintext though.
Re: Bad Password Policies
#18It's the service's job to be protected against bruteforce attacks.
Re: Bad Password Policies
#19I have one question. Even if we use hashing and random salting, then should we make some max-limit on the password. Its not related to the length i want to store, its the length that system will convert to a hash. Will very long passwords be hashed in equal time ?
A larger input will take longer, but for the ranges normally used for passwords it shouldn't be noticable. You want a maximum length to prevent denial of service attacks. The maximum depends on the hash you're using; Bcrypt has a 56 bytes limit for example.
Re: Bad Password Policies
#20I have one question. Even if we use hashing and random salting, then should we make some max-limit on the password. Its not related to the length i want to store, its the length that system will convert to a hash. Will very long passwords be hashed in equal time ?
A long password does take a bit longer to hash, but taking a long time is the whole point of modern hashing algorithms like bcrypt, so you shouldn't balk merely at the fact that it takes longer.
The real problem is that if the password is too long, it will kill your server to compute a hash of it. So there needs to be a limit. The usual limit in my apps is 1KB. bcrypt is fast enough to hash 1KB with a work factor of 10 (a reasonable default on current hardware), and I have yet to come across any realistic situation where a password over 1KB is needed. After all, the heat death of the universe will probably occur sooner than you can brute-force it.
I'm willing to increase the limit a bit if someone really wants to use a 32KB password. But 1MB is probably overkill. 1GB is definitely off limits.
There is, however, another problem with using bcrypt to hash long passwords. bcrypt ignores everything after about 60 bytes, so the password is effectively truncated. This can be a problem if most of the entropy is in the last part of the long password, because long passwords that only differ at the end would produce identical hashes given identical salts. (Imagine that someone uses the Fifth Amendment as his password but changes a few words in the last clause. What if someone types in the unmodified Fifth Amendment? Boom, they're logged in.)
My current solution for this problem is to do something like bcrypt(sha512($password)) so that I never need to feed anything really long to bcrypt. (The raw binary output of sha512 is 64 bytes long.) But I'm not sure whether this might negate the benefit of using a very long password in the first place, so I wouldn't recommend it unless someone who knows better can confirm that this is safe to do.