
Why your password can’t have symbols—or be longer than 16 characters - darxius
http://arstechnica.com/security/2013/04/why-your-password-cant-have-symbols-or-be-longer-than-16-characters/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+arstechnica%2Findex+%28Ars+Technica+-+All+content%29
======
columbo
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.

~~~
ocean12
Ars Technica has been doing a lot of excellent work recently.

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

~~~
jerf
"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.

~~~
tikhonj
Eh, spaces are nice if you want to have an actual pass _phrase_.

~~~
coldtea
Passphrases are lame.

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.

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

~~~
lifeformed
No offensive words either! We don't want our engineers looking through our big
plaintext files to get offended.

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

~~~
korg250
The solution is simple: change your name!

------
shawabawa3
I found this very strange

    
    
        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.

~~~
seanalltogether
Additionally.

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

~~~
shawabawa3
but it's 3 times longer! Think of all the ram that would use!

They can't even cite performance reasons as hashing passwords should be very
cpu intensive anyway

~~~
troels
The regexp might be longer to write, but I doubt it would perform worse, once
compiled.

------
themckman

      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.

~~~
mcherm
I have a brokerage account with Schwab and I am using a 10 character password,
so I can confirm your skepticism.

~~~
ChrisClark
Try logging in with just the first 6 characters of your password and see if
it's really looking at all 10 of them.

Edit: Someone else commented saying it might actually be the first 8, so try
that too if you want.

~~~
tomasquintero
I just confirmed this with my account, it's truncating at 8 chars.

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

------
miorel

      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?

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

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

~~~
shawabawa3
> 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

------
wereHamster
> [...] 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.

That argument does not compute.

~~~
illuminate
It plausibly sounds like something a PM would say.

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

~~~
Evbn
Hashing passwords intentionally slow for security.

The solution to a DOS like this is to ignored all password attempts after N
per M time.

~~~
samegreatsleeve
That's like saying to get someone to stop punching you, just punch yourself.

DOSing yourself to stop a DOS :/

~~~
harshreality
Nope, what typically happens is the account gets locked out and requires a
confirmation sent to the account's email address to unlock it.

~~~
samegreatsleeve
So a soft DOS then. Not much of a solution, still fully exploitable.

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

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

<http://en.wikipedia.org/wiki/LM_hash>

<http://en.wikipedia.org/wiki/NTLM#NTLMv1>

<http://support.microsoft.com/kb/299656>

------
bascule
Umm, great reporting Ars. Schwab actually has a limit of 8 characters, not 6:

[http://www.schwab.com/public/schwab/nn/legal_compliance/schw...](http://www.schwab.com/public/schwab/nn/legal_compliance/schwabsafe/your_questions_answered)

Still crappy and their password policy is terrible, but it's better than what
Ars is reporting.

~~~
Terretta
At the time of my reading and comment, the Ars text says a minimum of 6 and
maximum of 8.

------
masklinn
> Adding support for spaces only in the middle of the password would make the
> regular expression defining them three times longer, Engberg said.

My fucking god, because obviously you can't trim it _then_ apply your bloody
regex.

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

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

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

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

------
swang
American Express has (had?) terrible password requirements. I think it has
changed but not sure.

Who is giving these banks all this terrible advice?

~~~
illuminate
"Who is giving these banks all this terrible advice?"

Focus groups of users, I'm guessing.

------
gweinberg
Requiring two passwords is not two-factor authentication.

