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).<p>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?<p>Evernote's reason seems more like an admission of a technical debt than any kind of defense.<p>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.
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...
I found this very strange<p><pre><code> 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.”
</code></pre>
What frameworks and third party applications are they passing the password through? And what kind of framework strips anything from a password field anyway?<p>Sounds like the guy writing the regex thought it <i>might</i> be a problem so instead of thinking about it just opted for the safer option.<p>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.
<p><pre><code> The brokerage and banking company Charles Schwab has strict length limits—
passwords can be no longer than six characters.
</code></pre>
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.
A favorite example from personal experience that boggles the mind and helps explain things:<p>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.)<p>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.<p>Brittle security theater, but probably allowed this company to hold their nose and mark off a "data secured at rest" checkbox somewhere.<p>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.
<p><pre><code> A third user thought the length limit suggested that the company may then be storing
the password themselves rather than hashing them
</code></pre>
This was my first thought at well, and none of the examples in the article refute it satisfactorily.<p>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?
> [...] 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.<p>That argument does not compute.
It's not that they don't care, they are managing support headaches, and balancing risk to reward.<p>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.<p>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.
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.<p>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.<p>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.<p>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.<p>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.<p>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.<p>I remember reading a story about Facebook, where they flipped-case hashes as well, again to help the user login experience.
Umm, great reporting Ars. Schwab actually has a limit of 8 characters, not 6:<p><a href="http://www.schwab.com/public/schwab/nn/legal_compliance/schwabsafe/your_questions_answered" rel="nofollow">http://www.schwab.com/public/schwab/nn/legal_compliance/schw...</a><p>Still crappy and their password policy is terrible, but it's better than what Ars is reporting.
> Adding support for spaces only in the middle of the password would make the regular expression defining them three times longer, Engberg said.<p>My fucking god, because obviously you can't trim it <i>then</i> apply your bloody regex.
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.<p>However, the real solution is that these password restrictions are in fact not restrictive <i>enough</i>: If everybody would require a password to be <i>exactly</i> 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.<p>Though I suppose having a maximum password length of 6 might correlate with <i>not</i> 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.”<p>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 <i>exactly</i> 9 characters, no more, no less.<p>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.