I would bet 99% of this is legacy support. Someone in <insert big company> built an entire system over assuming the password is CHAR(6).
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.
The only line of reasoning in the article that seems somewhat convincing to me is Microsoft's point that stronger passwords don't prevent phishing, malware, or compromise via another site (and I'm not sure about the third one -- I guess it's true if the other site is storing passwords in the clear, but if they're hashed, I'd think stronger passwords would be harder to get using rainbow tables). But even if it's true that password strength isn't the weakest link for MS, why not allow for stronger passwords anyway? Is it really a big investment that would require tradeoffs to make that kind of change?
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.
"Evernote's reason seems more like an admission of a technical debt than any kind of defense."
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.
So.. IF I would buy the argument that leading/trailing spaces are evil: How would the expression triple in size by exclusing those?
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..
Sounds like lack of technical thinking if it actually reduces support burden. It's trivial to just remove spaces before storing the password, allowing authentication with or without spaces. I'm not sure why people don't realise that normalizing the password before saving the hash is acceptable, so long there's still enough password material being used.
You do have a valid point. I used to have a password with a backtick (`) in it. That is a standard key on a QWERTY keyboard but seemingly untypeable on an iPhone. I didn't realize that until I actually tried to enter that password on my iPhone.
Good to know. I am not sure if that is a relatively new feature, but a quick Google search didn't reveal the answer when I initially ran into the problem. It was easier to just change my password than to delve too deep into it.
I'm not sure if you meant this is sarcasm, but I read this quote as being more appropriate for an Onion-type article than for a serious discussion about security.
I remember once reading a bank's FAQ trying to explain why passwords couldn't contain SELECT, UPDATE, DROP, or DELETE. I can't find it now so hopefully that little problem has been fixed...
My ex was a member of a teacher's credit union. To log in you had to give the account number, the password and the user's last name.
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...
I have various Google products under my account, which is my real name.
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.
Our engineers have thick skin, they can handle it. However, we don't know how sensitive a potential hacker might be, and would feel terrible if we offended someone who wasn't expecting so see such profanity.
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.”
What frameworks and third party applications are they passing the password through? And what kind of framework strips anything from a password field anyway?
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.
I assume the problem is related to space-handling on HTML form submission. I don't know off-hand how POST handling differs, but for forms submitted by GET, spaces get all screwed up and it wouldn't surprise me if some or all browsers automatically trimmed leading and trailing spaces, and it also wouldn't surprise me if various JS libs took varying approaches to compensating for this weirdness.
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.
I've noticed that the quality of Ars' work has been getting worse as they've widened their coverage. Much of it now seems to be either simply regurgitated PR garbage, or the lightest rewrite of PR garbage, with a sprinkling of "some people like cake; others, pie. You decide!" sort of non-journalism on top. It's a shame, because they have had excellent writers in the past.
It's somewhat interesting, I've noticed that around the last 6 months or so, I'm not sure what changed. I first noticed all the tabloidy Xbox rumor-mongering based on "leaks". Ars was the best around, they don't need to emulate the Gawker network, even though those threads surely get more pagehits and comments.
Sounds like he's thinking his regex is of their allowed "set" of [A-Za-z0-9!@#$%^&*()_.-], and thinks that to support space but not at start or end, he'd need ^[set][ set]{6,}[set]$, repeating his set 3 times except with a space added to the middle set. That's not accurate. He can add a space to his set, then put a not-space assertion at the start and end, like ^(?! )[ set]{8,}(?<! )$ and call it a day. (And perhaps \A and \Z instead of ^ and $ depending on what he does with new lines.)
The better question is why is there a regex in the first place? If someone wants to set their password to some random chinese characters then why shouldn't they be able to?
The brokerage and banking company Charles Schwab has strict length limits—
passwords can be no longer than six characters.
I'm a little dubious of this claim as I have several accounts (checking, savings and brokerage) with Charles Schwab and my password is longer than 6 characters. I'd be interested in knowing where they got this information.
They truncate your password (at 8 character not 6). Which makes things even worse in my mind. You might feel secure with a password like "Password329#*3j3f930#(4j49", but Schwab will simply validate against the "Password" portion without even letting you know the obvious security repercussions.
A favorite example from personal experience that boggles the mind and helps explain things:
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
This was my first thought at well, and none of the examples in the article refute it satisfactorily.
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?
Well to be fair, there really is zero point from a security point of view in having a password longer than 64 characters. If someone does enter more than 64 they almost certainly have made a mistake (a copy-paste screw up for example).
And you do need some kind of limit to prevent people using gigabyte sized passwords.
Most people using 50+ character passwords or phrases often use password management software like 1Password, Keepass, or browser-based, etc.
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.
> password management software like 1Password, Keepass, or browser-based, etc.
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
> [...] an AT&T spokesperson [...] told Ars that the company decided not to allow symbols because customers did not like typing them when using mobile phones.
It's not that they don't care, they are managing support headaches, and balancing risk to reward.
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.
I'm sorry but this is bullshit for so many reasons.
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
> If you can have a 32 character password it is more likely to be forgotten.
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.
how so? cutting off an IP after many failed passwords is good security anyway. Only side affect may be if someone's machine is infected and taking part in the attack they get locked out while it goes on.
I talked to a guy that worked on Windows Live about the 16 char restriction. Microsoft Accounts also do not support Unicode, or anything but a small subset of ASCII characters.
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.
The general reason in Microsoft environments is backwards compatibility. They have had a number of password hashing schemes over time, each getting better. But the password itself isn't sent in the clear over the wire so there is no way to upgrade the user account from one hash to another. The only time it can be done is when the user changes their password, and again that requires the authentication service getting the new password in the clear. Consequently they tend to store all supported hashes at once, and you are limited to the lowest common denominator.
Apple truncates passwords longer than 32 characters on Apple ID creation. I find this really annoying, particularly because they don't call this restriction out when you create/change a password.
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.
I think Evernote's reason is actually surprising reasonable. I can imagine there's really some UIs that unreliably mess up leading and trailing spaces, and if they want to support those platforms, that means no leading and trailing spaces in the passwords. No spaces in the middle is too bad, you can disagree with their decision that "1.5 percent more entropy isn't worth the effort", but at least it's a reason, which is more than you can say about systems that limit their password length to 8 characters.
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.
Assuming they salt each password before hashing it and use a reasonable number of iterations, having relatively short password should not be a huge deal, right? The salt means that an attacker can't just use a rainbow table attack against a single password. In the event that an attacker does get ahold of all the hashes and salts, they would still have to brute-force each individual password.
Though I suppose having a maximum password length of 6 might correlate with not using other best practices, like salting the hashes...
“Criminals attempt to victimize our customers in various ways and we’ve found the vast majority of attacks are through […] and the reuse of passwords on third-party sites—none of which are helped by very long passwords.”
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.
A recent favorite example of example of terrible password requirements, VMWare VDP. The appliance requires exactly 9 characters, no more, no less.
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.
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.