
What technical reasons are there to have low maximum password lengths? - pzaich
http://security.stackexchange.com/questions/33470/what-technical-reasons-are-there-to-have-low-maximum-password-lengths
======
ianterrell
It's amazing how all the comments so far have entirely missed that it's the
top answer that was really submitted, not the question.

~~~
jl6
I found one of the comments interesting: that the monkey/ladder experiment
could be a myth.

~~~
dsego
It's probably just a thought experiment, a nice allegory.
[http://skeptics.stackexchange.com/questions/6828/was-the-
exp...](http://skeptics.stackexchange.com/questions/6828/was-the-experiment-
with-five-monkeys-a-ladder-a-banana-and-a-water-spray-condu)

~~~
maxerickson
It's fun to try to apply it recursively.

That is, if I take a lesson from a story about an experiment that never
happened, I'm acting like the hapless chimpanzees that merely learn to fear
the ladder. So I must choose to not model other people as cartoon chimpanzees.

------
mistercow
I actually emailed my credit union, pleading for them to increase their 10
character limit to something reasonable, and got a response saying that the
way their database handles passwords made it impossible.

Needless to say, I found that to be even more disconcerting than the existence
of the character limit.

~~~
randomdata
My credit union enforces similar limits (and only 0-9 are valid characters),
but I realized the validation was only enforced in Javascript. I disabled the
validation and I was able to use any password I wanted.

~~~
eru
Did you try any SQL injection attacks?

------
fruchtose
There's one reason I haven't seen mentioned yet:

Because the developer is storing passwords in plaintext, and he wants to save
database space.

Now, this is not a _good_ reason, but it is a reason nevertheless. Please note
that you should never, ever, ever, ever store passwords in plaintext.

~~~
obiterdictum
_Because the developer is storing passwords in plaintext, and he wants to save
database space._

This seem far fetched, not sure what thought process would lead anyone to come
to this conclusion. Even if you have a million users, you have ~8MB worth of
passwords. I'd imagine even developers who are not competent in cryptography
realise that.

~~~
derefr
If you allow truly _unlimited_ -length passwords, malicious users can set
gigabyte-long passwords. Whether you hash them or just store them, that's a
DoS waiting to happen with every login.

So, there actually _is_ a reasonable limit for the length of passwords, email
addresses, and most other user-editable fields that end up either being
hashed, or shoved through to the database. That limit is just probably
somewhere around 100KB to 1MB, not "eight". ;)

More importantly, that limit is an _infrastructure concern_ , not a _business-
domain concern_ ; it's best enforced by something like nginx spitting out a
400, not the model-validation logic in your app server.

~~~
fruchtose
While this is true, hashes use a set number of characters. For example,
SHA-256 hashes can be stored in 32-character hex strings. In that sense,
there's no point in allowing for a variable length field for password hashes.

~~~
pyre
It's not only dealing with password length. You could DoS the server by tying
up all threads in processing the upload. Uploading 4GB isn't instantaneous.

~~~
just2n
That's why the client should perform the hash and only submit the result.

~~~
derefr
No; this is effectively the same as doing no hashing at all. If your database
gets stolen, people can replay the "hashed" passwords from it to the server,
without having to hash them themselves.

~~~
just2n
I didn't mean to imply that you'd just store the hash the client comes up
with. That's idiotic, of course. Not everyone uses SSL, even though they
should, and it's not always secure, and even with the use of SSL, it seems
that there would be a potential length attack that could be employed to
effectively guess a user's password length. So in all cases, IMO, it makes
more sense to be receiving a fixed-length thing that is fairly insensitive to
attack in itself. So perhaps a user has 2 salts associated with their account,
per password: an auth salt and a storage salt. Then an auth looks something
like this:

    
    
        hash(saltFromServer + hash(password))
    

And then the server would do

    
    
        hash(user.salt + clientHash)
    

I'm not sure, but this seems reasonable to me.

~~~
ajanuary
Now you have quite a restricted domain, so if your database is compromised
there are a lot fewer values an attacker needs to enumerate to try and crack
the password.

~~~
just2n
That reasoning doesn't really sit well with me as a mathematician.

I would expect the image of MD5 on its codomain is almost a bijection (would
love to be demonstrated wrong here, if anyone knows of a paper that studies
this, but it seems reasonable that any good hash would have this property).

This doesn't really protect against a dictionary attack, but to guarantee a
collision, an attacker would still need to try approximately 2^128 passwords
for each password in the database, which is already the worst case for the
attacker, so no strength is really lost.

------
manojlds
My bank limits my password to 8. When I questioned while creating my account,
they asked me to visit the login page - in the login page you are asked for
the answer of the security question and also presented with 8 input boxes -
one for each of of the password characters - but having to enter only randomly
selected few from the password ( for preventing key loggers from getting
password, of course ). This seemed like a valid technical reason to limit
passwords to 8.

~~~
godfreykfc
Wait. Doesn't that imply your bank is storing your password in plaintext, or
at best salted and hashed each individual character of your password? (Which
is still horrible, because it now takes O(n) instead of O(n^8) to crack stolen
hashes)

~~~
tjoff
The client, or server, could just concatenate all the chars and then calculate
whatever hash you desire of the result. Or?

Yes, if the machine is compromised the attacker could do it as well but the
point was to prevent keyloggers specifically.

~~~
godfreykfc
If I understand correctly, you are only asked to fill in a few of the 8
characters. (I have seen this before.)

You are presented with

* * [ ] * [ ] * * [ ]

and you are supposed to submit

* * [3] * [5] * * [8]

so neither side would have enough information to reconstruct the full password
based on the user's input alone.

------
luma
Whenever you see a password field that is limited to 8 characters you'll often
also see a notice that the minimum value is 6 characters. Why? IBM. CICS[1]
had this specific restriction on password length until the 4.2 release in
2011[2]. CICS is hugely popular in the banking industry, which is why you'll
see this kind of thing most often with banks.

[1]<http://en.wikipedia.org/wiki/CICS>

[2]
[http://pic.dhe.ibm.com/infocenter/cicsts/v4r2/index.jsp?topi...](http://pic.dhe.ibm.com/infocenter/cicsts/v4r2/index.jsp?topic=%2Fcom.ibm.cics.ts.whatsnew.doc%2Fpassphrase%2Fdfhe4_overview.html)

------
throwaway125
For how much people like to repeat the "Use bcrypt!" mantra I'm amazed no one
has mentioned the password length limit of bcrypt.

The hash output of bcrypt stops changing after 72 characters but almost all
bcrypt documentation mentions a 55 character limit. I'm not quite sure what
that is about, can anyone clarify?

~~~
thurn
Brute-forcing a 55-character password is a transcomputational problem
(<http://en.wikipedia.org/wiki/Transcomputational_problem>), i.e., it's
impossible to accomplish using a computer the size of the earth within the
expected lifetime of the earth. So I wouldn't worry too much about it.

------
codesuela
Wow what a dumb question obviously the OP has very little experience in
dealing with real people, probably one of those code monkeys disconnected from
the real world. Tune out of World of Warcraft, turn off your Xbox and think
for a second: If people could choose long passwords with special characters
how could our customer support reps read them back to the users in case they
loose it? How could they check them on the phone? Geez and people here are
complaining they are valued less than a manager.

~~~
zzzpass
if you don't keep the password lists in plain text you wont have this
problem...

~~~
lucb1e
Actually his post was sarcastic (I think that's the word). Of course passwords
should be hashed, and moreover they should not be read to customers over the
phone.

------
rbirkby
Why does a site limit password lengths at all? Because at some point, some
_other_ limit will be exceeded. For example, HTTP POST size or even working-
set size. But the question is specifically about low maximum password lengths.
This boils down to hashing vs encrypting. Hashing (with or without salt) will
produce a fixed-length output. The size of storage for this hash output is
pre-determined. For example a varchar(20) for SHA1. For encryption, you have
to take the plaintext _bytes_ and produce a ciphertext of a maximum number of
bytes to store. Now we have both a limit on the number of input characters,
but also on which characters are permissible. Let's say a site allows the Euro
symbol, passes that UTF8 byte stream through an encryption algorithm, base64
encodes the result and stores it in a varchar field. The trouble is that the
Euro symbol is composed of a 4-byte multi-byte UTF8 sequence - F0 A4 AD A2. If
a password system didn't take account of this, they could easily overflow the
storage limit and potentially expose internal details via an error message to
the user.

The simple answer is just to hash+salt and then to limit the input length to
some large value to prevent blowing HTTP POST or process vm limits.

------
danielrm26
I'd say there are three main reasons:

1) Legacy systems not supporting special characters, 2) The desire to keep
support overhead down, and use of the system up, by keeping users' passwords
actually rememberable. In other words, if you let users make and use paswords
they can't remember, they will, and as a result they'll either annoy you about
it or stop using the site due to the hassle, and 3) Developers not wanting to
have to worry about parsing special characters from untrusted users, which
could potentially be dangerous.

In the past the top reason was probably the lack of ability to support the
passwords (#1), and today it's probably the lack of desire to support them--
mostly from #2, but partially from #3.

------
geuis
Remember that until the early-mid 90s, file names were limited to 8
characters. Lots and lots of enterprise financial software was written in
those days, and a lot of it still runs. We're talking about tremendously
complicated systems that support trillions of dollars in transactions a day.
You don't change level of interleaving complication fast nor easily.

With that said, the rest is just my own guess. Banks are slow moving. They're
built on these old systems that run well, but would be prohibitively expensive
to rebuild from scratch with modern principals. We see the edges of these
systems when it comes to things like passwords.

~~~
lucaspiller
I believe that is true for a lot of cases. People seem to overlook this, but
I'd guess that is the reason for a lot of cases.

90s though? I think you need to go further back a couple of decades. Royal
Bank of Scotland still has COBOL/IMS powering their core system [0].

[0] [http://ovum.com/2012/06/27/rbss-core-system-meltdown-
assessi...](http://ovum.com/2012/06/27/rbss-core-system-meltdown-assessing-
the-implications/)

------
zdw
The usual one I've seen is that it's hardcoded into a system in some way that,
while changeable, nobody wants to touch for fear of collateral breakage, which
is a variant on the "don't touch the ladder" argument given by the first
response.

This is usually something like a fixed width database or file field that works
with code written a long time ago...

Does it suck? Yes. In nearly all cases, Authentication, Authorization, and
Access should be separated in ways where they don't interact/overlap other
than at an absolute minimum.

~~~
drivebyacct2
The only way "fixed width database field" makes any sense is if they're
storing in plaintext, which is stupid all on its own.

~~~
cpeterso
Wouldn't a password hash, possibly truncated, fit into a "fixed width database
field"?

~~~
drivebyacct2
Why would you truncate it? My point was simply thus: if one is hashing a
password... every password will be the same length
(strlen(sha1("a")))==(strlen(sha1("somereallybigstring"))).

Thus, the column would be the right size for the hash _always_ and would be
completely unrelated to the user's inputted password.

Not sure I interpreted your message correctly, but either way, the DB field
should be unrelated to the length or limit of length put on the user password.
It should only be correlated to the length of the hash produced. (Truncating
seems like it would narrow the space for collisions, those bits are there in
the hash for a reason).

------
mattchamb
I work for a company that does the banking websites for several major banks
(not going to mention any names here). We have a few customers who have quite
low password length limits. There isn't any technical reason for this. We
provide a configuration option that the bank can set to limit password
lengths. So from my experience, the limits have less to do with technical
reasons, and are instead arbitrary "business logic" limits.

~~~
andreasvc
Why don't you just tell them that for technical reasons, the lowest you "can"
limit it to is 12 characters?

~~~
mattchamb
I'm just not part of any of those discussions. Besides, the code around
passwords and their configuration has barely changed in the last decade; and
the people who wrote it are now the ones discussing security with the banks.

------
csomar
[http://skeptics.stackexchange.com/questions/6828/was-the-
exp...](http://skeptics.stackexchange.com/questions/6828/was-the-experiment-
with-five-monkeys-a-ladder-a-banana-and-a-water-spray-condu)

Funny that the experiment was mentioned many times in different occasions, and
it's not clear if it was ever conducted. Still Bears around the Internet
believed it and just kept repeating it in every opportunity ;)

------
tlrobinson
"Because it's hard enought remember 12 characters already"

-my bank's tech support

~~~
INTPenis
Typically bank tech support have no idea about the inner workings of their
website.

My bank uses 2 stage auth to login which works really well. However, they have
a sort of shortcut service where you can activate and pick a password and then
use that password to do quick stuff online or in their mobile app. The quick
stuff still let's you transfer away all your money to someone else so it's
basically a gaping hole.

That password has the wildest restrictions I've seen. It allows only a-zA-Z0-9
and it must consist of exactly 6 characters. No restriction on containing at
least one digit or anything like that.

I've e-mailed them several times about this but their response is that this
particular service has been out sourced to one of the many companies they out
source things to, so they have no control at all over it.

And it's rather funny because you can tell that when you use this service,
you're taken to a completely different server farm than the rest of the
internet site. Fucking scary is what I call it.

~~~
ValentineC
I imagine there's the possibility of a huge PR scandal, especially if a blog
post is written eloquently and carried by the right news sources.

Unless the bank doesn't care about their image, of course.

~~~
INTPenis
You know you really got me going with your post.

I've spent the whole day thinking about this and now I've been looking up ways
to write a PoC. Because I don't think a blog post without a proper PoC will do
much good.

So first of all assembling a wordlist was easy using Python. The hard part
will without a doubt be interacting with one of the entry points to their
service.

It's a flash application, with a login form.

I've discovered Selenium for this purpose, and theoretically Selenium can act
as a browser, clicking input fields in the flash form relative to where the
element is created on the page. And then I can take a picture of the current
page after each operation and compare it to how the page should look at login,
or at failed login.

Jesus did you just ruin my weekend. ;) (in a good way)

Edit: Found sikuli and was amazed by how simple it is. Jython script that
let's you essentially use images from your screen as conditional expressions
in Jython. So you can do

    
    
      if exists(screenshot of bank login form.jpg):
        click(screenshot of first input field.jpg)
        type('bla')
    

And so forth. Very powerful stuff! Sikuli scripts can then be called by
external programs such as CPython Popen for example, and passed arguments.

------
alxndr
Discover (the credit card company) doesn't allow non alphanumeric characters
in their passwords. I harangued them until I got a reason why: that way, they
got fewer people bothering customer support with password problems.

(I wonder if they got any other people besides me bothering them because of
that rule...)

~~~
duaneb
I'm pretty sure this is no longer true. I use my strongest password
(techniques) at discover, including symbols.

~~~
jfb
That's not your strongest password any longer.

------
saadazzz
Before you comment, read the top answer!

------
mayneack
I used a small regional bank until recently and they had both a small (might
be 8, I can't remember) character limit and stored them in plaintext. When I
was emailed my current password after having to reset it, I left.

------
anon987
As mentioned in the link I've seen it mostly due to modern web-apps that have
to interact with legacy systems.

Also, I just did some Googling and it wasn't until 2009 that HP/UX supported
passwords >8 characters!

------
keithpeter
Primo Levi, _The Periodic Table_ , Chromium, tells a similar story of
something that was done once for a good reason, but then became 'just what you
do'.

------
NateDad
I don't really get the "legacy" systems bit. Are you passing around the
person's password to every back end server? Why? Just auth once and pass
around the user id. You should trust your internal systems, not require each
system to reauth. Security around the perimeter, once you're in, you're in.

Though to be fair, when's the last time you heard about a bank's password
database getting stolen?

------
dsego
Why does paypal limit the password to 20 characters?

~~~
drostie
I vaguely also remember typing a password into Paypal and it said, "hey! no
spaces are allowed!" and I definitely lost a significant chunk of confidence
in their process.

------
michaelwww
I'm not up on this topic, but I've always wondered why password length is so
important if dictionary and other automated attacks aren't allowed. I hope you
don't tell me that banks allow millions of password attempts in a short period
of time, certainly not from the same ip address and even from what might be a
bot net.

~~~
ufmace
The usual concern is the database storing the passwords/hashes being stolen.
This has happened to dozens of small to medium size web services. The attacker
could then hash away at the passwords to his heart's content. Then end-goal of
this is to get user/pass combos to be tried on other, higher-value sites, like
email services and, uh, banks.

Which gets us to the strange part. Who hacks a bank's service to steal a
password DB in hopes of using the passwords against some other target? I'm
thinking nobody. If you managed to compromise a bank's web service to that
extent, you'd be trying to transfer all of the money from all of the user's
accounts to one you control, not trying to crack their passwords.

That means that your bank's password storage method and complexity is not very
important. What is important is that, whatever password you use, you never use
that password on any other site. And that you use a bank that requires real
2-factor authentication, via text or mobile app or something like that, not
with "security questions".

~~~
kc0bfv
If the passwords are stored somewhere that's easier to access than your real
target at the bank, then cracking the passwords might be helpful... I totally
agree with your recommendations, but bank password storage/complexity
definitely could be important.

If an attacker got hold of a large number of bank account user logins, I'm not
sure what they'd do. My bank doesn't provide a feature to quickly transfer
cash from the website... Several hundred large billpay changes would show up
and be easy to cancel... Perhaps they'd just gather personal info useful to a
social engineering attack...

------
lovehashbrowns
Does Paypal still do this? It said my password was too long when I first set
it. I really really hate that.

------
andreyf
I could swear learning somewhere that it's because forcing short/simple
passwords makes it harder to recognize the password in keystroke logs, which
is the attack vector banks face the most. Can't find any sources to back that
up, though... has anyone else head this explanation?

~~~
andreasvc
I'd expect that the attack vector banks face most is that oblivious users
simply _give away_ passwords through phishing schemes. And banks with
reasonable security don't rely on passwords (alone), but on some kind of token
generator, in which case such a phishing scheme which directly transfers money
to the attacker is the only option (any keystrokes captured are useless after
x minutes).

------
Qantourisc
I.m.o incompetence. If not I'd love the "guilty" ones to explain this annoying
ting once and forever.

------
ChikkaChiChi
In today's world, password length is like zombo.com: The only limit is your
imagination.

