What technical reasons are there to have low maximum password lengths? | Hacker News Reader

What technical reasons are there to have low maximum password lengths?

security.stackexchange.com

148 pointspzaich125 comments

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.

I think it may be a problem with the link itself. In the past I've seen SO links that auto scroll to the answer of interest, however this one just loaded to the top of the page.

Submitter should have used the "share" link that appears at the bottom of the answer, although that scrolls the question off the top of the page, which may also cause confusion.

"The Internet is full of chimpanzees."

I am reminded of Egor Homakov and his various exploits, especially in the Rails community. Someone points out a problem and the community collectively decided to ignore him.

I loved the analogy, it's sad that more people didn't read it.

It doesn't look like it still does, as the link is to ".../questions/33470/..."

lol, check out his other works: http://security.stackexchange.com/questions/9487/how-can-pay...

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

It's probably just a thought experiment, a nice allegory. http://skeptics.stackexchange.com/questions/6828/was-the-exp...

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.

Not "could be". It's a total fantasy. Real world chimps wouldn't even start beating up other chimps for touching the ladder before you start replacing chimps.

Either the submitted URL was changed or you are wrong. The URL goes to the page, not some anchor.

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.

CHAR(8)

Worse yet, it seems to imply that they aren't hashing, which is simply preposterous for a financial institution.

Many banks require you to use numbers only for your pin a smart engineer probably figured that cracking 10 char numerical "passwords" is trivial so hashing would be a waste of resources and hence energy and emissions. It is greener that way.

Don't worry too much about it. It's vastly more likely that it's actually their change policies that make the increase impossible.

Yes, probably, but it's still scary that whichever technical person they asked thought this would be an OK answer to give someone who is reporting security concerns.

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.

Did you try any SQL injection attacks?

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.

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.

Some developers love that kind of micro optimizations. Even smart ones. I've had my varchar(256) columns changed to a more modest varchar(30) because I was "wasting space." Those people dont like being wrong either so there's no point arguing it either and instead concentrate on the bigger issues.

I've seen that, but once the internal format is actually explained, varchar(256) generally survives.

For those who don't know, for varchar(1) through varchar(256) the internal database representation in sensible databases is one byte to say how long the varchar is, followed by the actual data. There is therefore absolutely no difference between the representation of varchar(30) and varchar(256) - it is just an arbitrary restriction on what data is allowed to fit in there. But databases that support varchar(257) need 2 bytes in front for it.

Thanks for the explanation, didn't know that.

Is this true in most modern DBs? (I'm thinking MySQL and Postgres particularly).

Close enough in PostgreSQL. String columns larger than 256 actually use 4 bytes to indicate the length, but on the other hand, large strings are automatically compressed, so they may use less space than 4 + length.

http://www.postgresql.org/docs/9.2/static/datatype-character...

I believe in InnoDB the way text and varchar(X) is stored is exactly the same. They both only use as much space as the data they are storing requires. However if you pass a 101 character string to a varchar(100) it will be truncated. I'd guess that is useful in some cases, but in reality you probably want to do the truncation in your application so you have more control over it.

Truncation is the failure mode which MySQL describes as a feature.

Don't use MySQL.

I recently discovered its a similar case for numbers in Oracle, which slightly surprised me.

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.

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.

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.

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

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.

Couldn't you solve that by hashing it again on the sever?

I'm not sure about the added security benefit. Basically the only additional security is if someone gains access to your server they can't capture plain text passwords anymore but once someone gains access all bets are off and they might as well just switch out the Javascript. In any case you should run a strong hashing algorithm like bcrypt with a salt and oh I don't know 1000 iterations? Also last time I tried something like that (which was a few years ago) I ran into big problems with different hashing algorithm implementations providing different results (JS.md5("password") != Python.md5("password")).

Also please correct me if I'm wrong.

The added security benefit of server-side hashing is the same as if plain text passwords are sent, to prevent knowledge of the authentication secret if the database contents are disclosed to malicious third parties. The client side hash of the password is only to ensure that a fixed length secret is sent and subsequently processed, to avoid DoS attacks on the server.

Ah I see, thanks for pointing that out. Haven't thought of it myself.

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.

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.

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.

If you don't use SSL and the attacker can sniff the stream, chances are he can inject JavaScript to send him the password.

SSL is just indispensable nowadays for authentication.

And if you have SSL anyway, why use passwords when you can use certificates?

Because users don't understand certificates?

They didn't understood many other form of credentials either (like OpenID), but sites educated them and now they do.

They do? Are you sure of that?

That depends on who the site's audience are and how the login UI's done. Fairly tech-savvy visitors certainly do understand OpenID and alike. At least, I strongly believe so. Well, more casual audience probably don't.

However, my bank uses X.509 certificates to authenticate users over Internet. Out of curiosity, I've asked bank employee once and was told that most users do manage their certificates just fine, without any issues. Obviously, bank provides short and simple manuals, which explain how to generate a certificate request, obtain a signed certificate (by visiting bank in person), authenticate and renew expiring certs.

(My bank's not using in-browser PKI due to legal reasons and provides a small piece of software wrapping around the browser, but that doesn't really matter.)

Here is the attack scenario: Alice is trying to login to server Bob, but her WiFi access point Eve is running a protocol-mismatch attack: Alice communicates to Eve by HTTP, which Eve records and then transmits to Bob by HTTPS. We'll assume that Eve does not inject her own scripts but just eavesdrops on the conversation.

Your problem: clientHash is "password-like" and Eve can use it to log in.

One solution: use the HTTPS auth methods. Unfortunately, this is not the standard in the industry because the GUI is ugly.

The reason why this is an even bigger problem than you might think: what does the login method do? It probably sets a "remember me!" cookie, which is also "password-like" for just about every purpose. Eve sniffs the cookie and can use it to compromise the account in the future.

Also the 'remember me' cookie is probably stored in the clear in the database. So much for that, eh?

What you really want is a system based on digital signatures: whenever I make a request I digitally sign it. But the core problem is that I don't want to type in my password for every damn request, so this is being cached between requests and between page views. Depending on how it's cached, there are vulnerabiities -- especially if you just have your browser automatically fill in the password blanks, but also if you carry these "password-like" login cookies. A system of delegation and revocation can be done, but you come dangerously close to reinventing a public key infrastructure if you go too far down this road.

HTTPS auth methods can help out quite a bit, but can be hard to set up with a custom backend and hard to test against that sort of "downgrade attack" I mentioned in my first paragraph. The best of these ideas is to give your users client certificates and thus be safe forever, but nobody has found it useful enough to actually do this.

The only real alternative has been to remind the customers to always look for the s in the "https:// in the location bar. This is stupid and now there are some proposals for browsers to ship with lists which are "Expected to be secure", to avoid it, but yeah, we never really outgrew it.

Thanks for explaining that.

So sitting here trying to think about a way to solve that problem, what I come up with is essentially PKI. But if the attacker has the ability to inject code, they can always break this entirely by stealing my private key.

This feels to me like URLs are fundamentally broken, in that a user might try to go to http://mybank.com. Is there any secure way to get their browser to redirect to https://mybank.com? It seems like there might be something that could be done with dnssec, but that feels brittle too. Gross.

HTTP Strict Transport Security solves this.

That only works if the user makes an https request first.

Say the URL is: https://mybank.com, but I go to http://mybank.com, and I haven't been there yet, so the STS rule isn't in my browser. How can a user reliably be switched to https without risk of having the connection hijacked by someone injecting code to the user?

I'm not arguing with that. I wholly agree with you that a client should not be able to upload 4 GB for the password field. I think I misread your first point as if it dealt with server-side storage.

For the application code to complain about password length then the 4gb upload has to have already occurred.

Protecting against a DoS attack this way is done in the webserver, which doesn't care about individual fields. Sure this means there's an implicit password length limit, but not in any application-level sense.

I would think that the kind of developer that considers it acceptable to store passwords in plaintext could easily be the kind of developer that would make arbitrary decisions based on feelings rather calculating the actual likely storage a longer limit would result in to make an informed decision...

Even if saving database space is a concern, you could store a truncated password hash.

If you don't use the full hash, I believe you can't really make any guarantees about the variance and distribution of characters in the hash. So not sure that's such a good idea.

If you'll go as far as saving a truncated hash, it's better to just save the whole thing. I don't see any good reasons not to.

Just use ROT13 - same space requirements as in plaintext

(I really, really hope people realize that is a joke. Otherwise this might be the worst piece of advice I have ever given on the internet)

Yeah- you need at least rot26 or else it's just too easy to crack with today's technology. But everybody ought to know that. (Hey! It's April 1st somewhere...um, or will be in a few hours)

Fortunately I've already upgraded my encryption to rot52.

One iteration of ROT13 is too fast to compute to guarantee any sort of security. If you really want to secure your passwords, make sure you perform 2↑↑100 iterations of ROT13 or so to ensure substantial computational cost to the operation.

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.

May I ask what bank you bank with?

Natwest do exactly this.

They also require two factor authentication for all actual money transactions via a chip-and-pin card reader they ship to all customers. You only authorise one transaction for a specific amount/destination at a time.

All UK financial institutions I have used do this: Nationwide, Barclay's, Natwest (RBS).

Which is one of the reasons I do not use online banking!

I don't know your bank, but in my case (Barclays) as mentioned above, I'd think their tellers or credit card authorization would both be a weaker spot for attacks than their online banking.

They don't allow you only log in with two characters from your password like that, you also need a passcode or a one time pad generated with a chip and pin reader, and for transfers to accounts you haven't previously transferred money to and indicated you want to save for future use, you also need to enter your pin, amount and target account into the reader to get a code to enter into online banking to do the transfer.

Well yes, but not as the only security mechanism, as far as I'm aware.

Barclays for example allows you to log in with this plus a separate pass code, but you can't do much damage without using a chip and pin reader that will give you an 8 digit one time pad too (alternatively they now let you use a mobile app to generate the one time pads)

E.g. you can't do transfers to recipients you haven't specifically saved for future payments, for example, without entering your pin, the account number and amount into your key generator and entering the resulting code into online banking.

This was HSBC in Canada.

I am not a security expert, and realize that this may not be the right thing, and the implementation might be horrible, but if there is a reason to limit password to 8, this was a good enough reason to do so :)

A certain other Canadian bank only allows passwords with a length of 6, no more, no less. This bugs me to no end with how insecure it is. I believe their excuse is because the same password is used for your phone banking password and that one must be 6 characters.

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)

Oh they probably are storing it in plaintext

I believe they have some legitimate reasons for doing that (like the example quotes)

Another reason for specifying a length/limits is that you may need to type it using another device (like an ATM) and keeping it apart from other passwords (if you allow everything, you'll just use your gmail password or something)

Now, to be honest, if you break into a bank db, why are you going to bother with passwords?

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.

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.

Or they could generate say, 10 masks, hash them along with the password and then only present you with one random mask from those 10.

What kind of security is that? Don't you think an attacker who can install a key logger could also install a screen grabber? This definitely smells like a false sense of security.

It might be insecure, but not in the way you mention. You only enter 3 or so characters while logging in. Others are hidden. Screen grabber can get only the three characters. Of course, if you login multiple times, the password can be obtained eventually. But this probably for one time login at a public computer.

And yeah, like in many things, these are done to give a false sense of security to the user and some minimal deterrent to the attacker.

8 choose 3 = 56

Even sniffing just one login gives a completely practical attack to gain access to your account, even though the attacker doesn't have the full password. They might not be able to do everything the full password would let them do, but its still not exactly acceptable.

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

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?

I'm unsure of why it is but I don't see why the algorithm can't just handle it like this:

check string length

if longer than 55, remove first 55 or less characters up to end of string, store in array

repeat until string is empty

encrypt each item in the array, append them all on to each other as such

EncryptedText[0] . EncryptedText[1]... etc

Seems like a simple way to handle this. You could impose your own restrictions to stop a server DDoS by encryption requests on long strings, but to be honest if you're allowing a 100,000 character password, you're doing it all wrong.

That is potentially problematic, but it's far from the atrocity that is a bank website limiting you to a 10 character password.

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.

To clarify I never meant that the limit is a security issue, just that it's a valid technical limitation to limit the length of a password.

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.

Brilliant

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

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.

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.

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.

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.

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

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.

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

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

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

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.

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

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.

http://skeptics.stackexchange.com/questions/6828/was-the-exp...

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 ;)

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

-my bank's tech support

This could be translated to,

"Because we estimate the added costs of supporting users will increase by X due to more users forgetting their password due to length"

It's more complex than that. Banks are also liable for security breaches, not consumers.

Additionally, banks invest in a variety of security mechanisms that ordinary companies, even major ones, do not invest in. Passwords are only one part of their overall security. I think all of this outrage over banks having poor password practices, while sometimes valid, is made by people not fully informed. It's like complaining that the bank vault has weak points that could be attacked. That's not all that's keeping your money secured.

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.

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.

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.

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

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

That's not your strongest password any longer.

Why can't they just use email password recovery like everyone else?...

Before you comment, read the top answer!

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.

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!

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

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?

Why does paypal limit the password to 20 characters?

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.

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.

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

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

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

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?

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

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

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

Reply on news.ycombinator.com