Bad Password Policies

http://www.davidpashley.com/2014/04/16/bad-password-policies/

by edward • 12 years ago

29 43 12 years ago

prohor• 12 years ago

I'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 ...

harshreality• 12 years ago

The most frightening I've seen is interactive brokers. Passwords must be 6 to 8 characters, and symbols are forbidden. Strangely, usernames must be 8 or 9 characters (with additional restrictions: >2 letters, >2 digits, and must start with a letter).

smnrchrds• 12 years ago

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/

twelve40• 12 years ago

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.

axefrog• 12 years ago

I find it extremely frustrating how many services (Microsoft included!!) won't allow me to use spaces in my passwords. Why on earth do they care which characters I choose for my passwords? So much for "correct horse battery staple"...

rtpg• 12 years ago

you can try camelCasing your passwords, same effect really

certainly_not• 12 years ago

Passwords don't need to be legible in the first place. There's nothing wrong with correcthorsebatterystaple.

On the other hand, forbidding spaces is absolutely misguided.

kijin2• 12 years ago

Unless the website silently lowercases all passwords. A lot of them do, in the name of making life easier for people who have Caps Lock on.

thisishugo2• 12 years ago

I had this annoyance with FastMail[0], recently. They give this justification for their restriction:

    FastMail provides a lot of different services over many
    different protocols. To ensure that your password is
    compatible with all of them, and the many (often
    slightly buggy) clients out there, we only allow
    the characters A-Z, a-z, 0-9 and !?@#$%^&*()-=_+[]{}.,:;<>/\|~"'`.

Which I understand, but how about a checkbox that says "for goodness sake, I'm a grown up, I promise not to moan if I use a "buggy" client, now please let me the password of my choosing."

[0] https://www.fastmail.fm/help/account/password.html

SlashmanX• 12 years ago

Twitter is also included in the list of annoying sites. I think AppleID is one too, their password policy just sucks anyway, I'd love to see the stats on the amount of "Forgot Password?"'s on their service

xtrumanx• 12 years ago

Spaces do however sometimes cause some problems on html forms. For instance, they get trimmed off the end of each value of a form when the request is sent (happens on Chrome at least).

There was another gotcha I noticed with spaces and html forms once; an option in a select list with multiple consecutive spaces in the middle of it had those spaces reduced to one space when the request was sent (once again, happens on Chrome at least).

maxk42• 12 years ago

Please do not enforce character set or maximum length restrictions. I have a number of 30+ -character passwords that are regularly rejected because they don't contain a digit. I'm sorry but "Password1" isn't going to be stronger than that.

Also, consider enforcing higher minimums. Eight characters is simply too fast to brute-force.

ateevchopra• 12 years ago

I 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 ?

masklinn• 12 years ago

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

Rafert• 12 years ago

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.

kijin2• 12 years ago

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.

MattBearman• 12 years ago

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

paulannesley2• 12 years ago

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

Robadob• 12 years ago

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.

EGreg• 12 years ago

In apps built on our Q Platform, the default "set password" screen actually encourages users to select a PASSPHRASE and displays several suggestions. When the app is online, the suggestions consist of three consecutive words in Yahoo News. If the app is offline, they are generated from a dictionary in the form MY NOUN VERB HIS NOUN or similar.

This should hopefully help more people choose strong passphrases.

paulannesley2• 12 years ago

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.

user243• 12 years ago

Please someone set up a tumblr for these.

Paypal has a max of 20 chars.

cheepin• 12 years ago

I can't remember which site did it, but one site would just silently fail and redirect to the same page if the password was too long... awkward.

fuzzix• 12 years ago

Hetzner Robot is 32 IIRC.

Disappointing.

ozh• 12 years ago

Honestly, 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.

thisishugo2• 12 years ago

For services where a user can only access their own account, I mostly agree. But sometimes one users' bad security practices can compromise other people's security, too. If you're sharing confidential data with other people - for example, via SpiderOak[0] - and any one of those people's accounts are "hacked," it doesn't matter how good your password is.

[0] I'd say Dropbox, but you shouldn't be putting confidential data in Dropbox.

gkya• 12 years ago

The easiest answers I can intuit are a) space concerns and b) passwords being stored unencrypted. I reckon point a is valid because malicious users may attack the provider with very long passwords via creating bogus accounts, to disrupt the service; and b is valid because if the developers are lazy enough to store unencrypted passwords away, likely they are to defend against injection attacks via disallowing characters like (').

jbverschoor• 12 years ago

It's the service's job to be protected against bruteforce attacks.

user243• 12 years ago

Bad Password Policies

Related Stories