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"...
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."
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).
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
IIRC Facebook creates three passwords to deal with character case issues; the one you enter, an inverted case version and a version with the first characters case inverted.
In order to be performant, since the check is not against your actual password but just against a stored hash (salted/bcyrpted/etc), I wouldn't be surprised if they simply stored all 3 hash results.
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 ...
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.
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).
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.
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.
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.
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.
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.
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.
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 (').
What's a reasonable minimum max password length? I've always fallen back on the Wikipedia Password strength article [0], for the NIST recommendation that 80 bits is sufficient entropy. I imagine that attack vectors other than password strength are for the most part going to be the killer issue. (heartbleed, MITM attacks, rubber hose, tempest, etc...)
Assuming that we're talking about purely randomly generated passwords, the entropy of passwords generated to fit in at least a few of the cases in the the original article should be fine. The UX factors are annoying however. This is an area where consistency would assist conformance.
It seems to me the more secure you want your data, the more arcane (and less secure) the password rules are. I recently got in an argument with the bank, that doesn't allow special characters "These rules are here for your protection" Then why are you limiting the input space. "It is for your protection, so it is more secure."
Rules like these, (limited length, limited set, etc) scream to me incompetence. And I wonder what else is broken.
Any length and any character is a nice idea, but given an incompetent developer on the other side it can get worse. E.g. a frequent snippet you can find on the web for hashing a string in .NET uses things like Encoding.Default or even Encoding.ASCII. Those then change every Unicode character silently to a question mark, making a lot of potential passwords identical. Normalisation should also be considered and rarely is.
My bank does not allow me to choose a password with more than 6 chars (but that is only the log in, for any actual money transfers there is a factor-2-auth), and i think icq did limit the password to 8 chars.
The only reason i can think of why one should do this is plausible deniability for the provider. No, we weren't hacked, your password just sucks.
One of the most ridiculous password policies I ran into recently limited passwords to a maximum length of 8 characters. I was absolutely stunned. And for whatever reason, they also enforce that it must contain both a capital and lowercase letter and a number, plus a minimum length of six characters.
My university used to have a similar length restriction. When I enquired about it, it was because they unify the password across all their systems, and some of the systems are old.
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 ?
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.
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.
As soon as some characters are not allowed for passwords I always fear that the service did implement own hashing and password storage methods instead of using standard ones
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.
And the very first complaint is about a site sending you a password after registration, which is safe unless your email is compromised (in which case you're screwed anyway).
