Why your password can’t have symbols—or be longer than 16 characters
arstechnica.com
arstechnica.com
Unfortunately these fixes aren't always as easy as updating the column and introducing salt/hash. The system could be sending the password in plaintext to multiple sub-systems, it could be used for VOIP services, it could even be used by CSRs to manually update settings on behalf of a user, even better, they might be extracted and emailed as attachments to partner companies. I've seen all of the above done with passwords. Fun stuff.
Evernote's reason seems more like an admission of a technical debt than any kind of defense.
AT&T's reason doesn't make sense either -- if users don't like entering certain characters on a mobile phone, they can pick a different password.
Our eyebrows are only raising because an article with a strong focus on passwords was written and they saw fit to include this tidbit. In isolation I doubt any of us, including the developers of this particular little thing, sees it as something worth caring about. The point about leading or trailing spaces is definitely true, and who cares if you can have spaces in the middle? If your password policies are so awesome that that is your biggest problem, I'm ready to declare victory and move on.
You use the "passphrase" thing in a system that silently ignores the extra characters (see below for "brokerage and banking company Charles Schwab" which does just that), and "wonderful undefeated password ftw" becomes "wonderful" (trivially cracked with a dictionary attack). Pwned.
Or you get your way, and, as a naive user, use a common passphrase, included in more involved attacks. Like "rage against the machine", "let me in", "my secret password", "empire strikes back", etc. Pwned.
Or you end up with 30 passphrases in 30 different systems. Or, since a lot of them don't allow long password, you end with a mix with passphrases and short passwords.
Might as well have used a password management app with cryptic generated passwords all along.
And more important: Why is that relevant in any way? An article about maximum password length presents a quote that reads like "that's over our maximum regex length".
Certainly no big deal, but I can't help raising my eyebrows at that line of reasoning..
Fundamentally, I don't think it's unreasonable to try to protect users from themselves.
One day she told me she always had trouble remembering which way to log in... which seemed strange to me. Anyway, her surname is Irish, one of your typical O'Somethings. When she tried without the apostrophe she was fine but when she used the apostrophe it failed with a SQL error message.
When I finally was able to breathe again she asked me what it meant. I just told her that it meant that she should never leave any money in that account...
One time I gave feedback to Google, from a Google feedback form, and gave my real (and had been in use for years) googlemail account name on this Google form.
The form rejected it, because my real name has a mild swear in it.
That kind of thing is vaguely disappointing.
I did suddenly have to change all the answers to my 'secret questions' when I realised that I'd have to read them out loud if I needed to get back into my bank account. Lots of profanity snipped there.
The permitted characters and length for passwords are defined as a regular
expression in Evernote’s API, but spaces are left out, Evernote says,
because leading and trailing spaces presents a problem. “Software needs to
precisely determine how to treat leading and trailing spaces,” Dave
Engberg, Evernote’s CTO, told Ars. “Some UI frameworks and third-party
applications would unreliably trim spaces, others would not.”
Sounds like the guy writing the regex thought it might be a problem so instead of thinking about it just opted for the safer option.
Why do any kind of a regex validation at all for a password? As long as you are hashing it straight after receiving it the user should be able to send whatever they want.
Re: why you'd have a regex for validating passwords, I assume this is in the password setting user interface, so you can give the "hey that password doesn't meet the requirements" feedback without waiting for a round-trip to the server.
Edit: the real frustrating thing about this article is that it doesn't actually answer the question in the title, and nobody seems to care. Yeah, Microsoft, great point: longer passwords may not actually be more secure, but prohibiting them causes your users problems if they've developed a nice consistent scheme for generating their passwords and have to have a special exception for your dumb site that limited the length for no good reason.
"Adding support for spaces only in the middle of the password would make the regular expression defining them three times longer, Engberg said."
So they admit they already have the regex definition that would allow this, but for some reason don't want to put it in production? How strange.
They can't even cite performance reasons as hashing passwords should be very cpu intensive anyway
The brokerage and banking company Charles Schwab has strict length limits—
passwords can be no longer than six characters.
edit: I just tried on my account and it's actually 8 characters, not 6.
Edit: Someone else commented saying it might actually be the first 8, so try that too if you want.
A core financial platform used by many many hundreds of financial institutions in the US offers "encryption" of the online banking password, which is stored in the core DB. (Most of the times, the core system -- which records how much money you have, your txn history, &c -- is separate from other auxiliary functions like online banking, and the two are joined with some sort of gateway.)
The encryption scheme was taking the password, and doing a byte-wise conversion to EBCDIC for that field. It was trivial to reverse with a one-line TCL query, but appeared encrypted to the casual observer.
Brittle security theater, but probably allowed this company to hold their nose and mark off a "data secured at rest" checkbox somewhere.
The encryption of the data transfered between teller workstations and the core was just as laughable -- XORed against a key sent to the client in plaintext at the beginning of the session. You didn't even need the key to break it -- using static strings or frequency analysis would suffice.
A third user thought the length limit suggested that the company may then be storing
the password themselves rather than hashing them
Is there any point at all to capping the maximum length? Are sites worried that if the 64-character limit is lifted, 64+ character passwords will become common, leading to a bad user experience?
And you do need some kind of limit to prevent people using gigabyte sized passwords.
I do think an upper limit is valid, as allowing an arbitrary long string could be a form of DOS (imagine someone sending the library of congress as a password), but 64 characters seems kind of weak.
AFAIK all these programs allow generation of <=64 character password
> but 64 characters seems kind of weak.
A 64 character alpha-numeric password has 36^64 combinations. That's 2^330. You're trillions of times more likely to find a hash collision than brute force the password (assuming 256bit hashes).
Security-wise there is absolutely 0 difference between allowing >64 character passwords and not. From a user experience perspective I'm sure arguments could be made either way
That argument does not compute.
6 Character AlphaNumeric for Schwab is because they use the same password for phone, and this is a throwback to a "Pin". They could at least be honest that this is why it is what it is. The Fobs they send that generate a random number to go with your login make this not a deal breaker for me.
Microsoft is balancing support with security. If you can have a 32 character password it is more likely to be forgotten. But that isn't the real "Support" cost it is DDOS attacks. Computing a hash of a 128 character password is more expensive than doing a 16 character password. This makes it possible to bombard their servers with a Hotmail address you know to be real, and an imaginary password which they have to compute and check the hash for.
But that isn't the real "Support" cost it is DDOS attacks.
Computing a hash of a 128 character password is more expensive than doing a 16 character password.
1. There is no way hashing 128 characters instead of 16 is so much more expensive that it enables an otherwise infeasible DDOS
2. Passwords should be salted before hashing, so you're adding (hopefully) at least 30 characters of salt to the password anyway.
3. Hashing should be expensive. You should be using bcrypt or some other algorithm with a work factor to protect against brute forcing if your database is compromised.
The real reason is likely a mix of legacy code and extra support from people forgetting passwords, and just plain ignorance from the developers
I disagree. There are many long passwords that are easier to remember than a short password. Just to make up an example, I might use "WakeGrindTampInfusePourSip" as a password--it's the sequence of actions that lead to my morning caffeine fix. Compare that to a password that must be between 6 and 12 characters, with one lowercase letter, one capital letter, one numeral, and no special characters. Nothing in my life maps readily onto that schema except for my AOL password from 1996, so I'm going to make something up on the spot, forget it immediately, and rely on the password reset functionality every time I want to log in.
They need to test is against hoardes of naive users.
They need to encourage those users to have one long strong password to unlock the safe, and then to have strong random passwords for everything else.
Having seen how some computer users operate I guess any OS supplier has a hard job here. See, for example, the 'power users' who turned off UAC.
The solution to a DOS like this is to ignored all password attempts after N per M time.
DOSing yourself to stop a DOS :/
First, there must be a maximum size. Obviously, you're not going to allow allow 2^64 byte passwords. So it's under that. But, sure, 16 characters is pretty low.
The actual reason seems to be lost to time. The password code was originally written well over a decade ago, when things were less security focused. For all we know, some part of the auth pipeline (even if the passwords are stored hashed) might have sent the user data in a space or comma delimited, using 8-bit chars without UTF-8 support.
He explained that every time they've reviewed it, the password restrictions haven't been close to the top of things they can spend their time on to improve user safety.
I've run into other companies that limit symbols, citing problems with users on mobile devices messing up and generating support tickets. That sounds reasonable for lower-security assets.
Evernote's space explanation sounds really silly. Why not just include stripping spaces as part of the password "hash" function? That's gotta be easier than using Regex.
I remember reading a story about Facebook, where they flipped-case hashes as well, again to help the user login experience.
http://en.wikipedia.org/wiki/LM_hash
I think it'd be nice if there were a list of these stupid password rules per domain; that way, 1Password and equivalents could generate maximally strong random passwords per site. Best of all, of course, would be a standard, machine-readable way to communicate this security brain-damage so that it wouldn't have be crowdsourced.
Hmm.
http://www.schwab.com/public/schwab/nn/legal_compliance/schw...
Still crappy and their password policy is terrible, but it's better than what Ars is reporting.
My fucking god, because obviously you can't trim it then apply your bloody regex.
However, the real solution is that these password restrictions are in fact not restrictive enough: If everybody would require a password to be exactly 40 hexadecimal digits, no more and no less, this would force everybody to start using password managers, and they would all be much more secure.
Though I suppose having a maximum password length of 6 might correlate with not using other best practices, like salting the hashes...
I'd actually disagree with this assertion. If I can just prefix my insecure password (let's say "password123") with "Microsoft", it becomes both more secure, essentially distinct from the password on other sites, and easy for me to remember. If the limit is just 16 chars, then I can't do that.
Personally, I'm most aggravated by services with uneven complexity requirements. It seems pretty often that I run into situations where special characters are required but underscores are forbidden, things of that sort.
Who is giving these banks all this terrible advice?
Focus groups of users, I'm guessing.