Possible Duplicate:
Why restrict the length of a password?

Lately I've noticed a lot of online applications that have odd password requirements. For instance, I recently opened up an account at Chase Bank and had to choose a password for online banking. The password had to be between 6 and 8 characters and strictly alphanumeric. No carets, ampersands, stars, or anything else like that. My CapitalOne credit card's online banking password is similar. The password can't have any special characters, and it had to be between something like 8 and 10 characters. An eleven character password would be invalid.

Even the popular web host Webfaction, (which appears by all means to be ran by fairly competent people), has a requirement that passwords can't have certain characters. (For proof, watch one of their screencasts where a dev has to choose another password because "example.com" was rejected based on it having a period.)

So far in my web developing "career", I've always just let the user use whatever password they want, as long as it's bigger than 5 or so characters. The password always gets ran through some kind of hash algorithm anyways. So it doesn't matter if it's a 300 character password, or a 5 character password, it's always going to be worked with internally as a 32|64|128-character hash.

The question I'm asking here, is what is the basis for limiting passwords like this? Why would it even matter? Is there something I should know here? I can understand limiting a password to at least so many characters, but why impose an upper limit? Additionally, I can understand forcing the use of special characters for a stronger password, but what purpose does restricting their use do?


Limiting password length is a sign of carelessness and is poor practice.

Please see this question for more info:



The character limitations (no ., etc.) are due to programmers who don't know (or care) how escaping works.

The length limitations are due to programmers storing passwords in plaintext in fixed size columns, and a cargo cult mentality (we store hashes, but everyone else has a length limit!). Andy's link has a good explanation.


There used to be many reasons to do this. However, today, I can think of none; the entire spectrum of Unicode should be usable in a password, which should be considered to be an opaque stream of bytes, not a meaningful, displayable string. The string that is fed to the server is escaped, and so arbitrary bytes can be fed into the hash function that is applied before saving the password to a database (at least, I hope they're hashing it, and securely, too).

I won't be a customer for a Web site that requires a password so weak that it can be cracked in a reasonable amount of time. I wouldn't be a customer for sites that I knew stored passwords in plaintext or unsalted, either, but I can't see everyone's databases, so I can't avoid those unless they're blatently obvious (no password reset, just "Hey, we'll email you your password!", sure, thanks, grr).


There are still a few "valid" reasons to limit passwords. If you're interfacing with a legacy system, that system may have an unchangeable limitation on password length and replacing that system may be outside of your time and/or money budget. Not saying that this is the best course of action, but we can't always take the very best course.


If you're building a system from scratch where the password will only need to be ever be entered via a PC directly into your software, there are very few good reasons.

However, if you're integrating with other systems (legacy or otherwise), or if the users account will be accessible by other means, the answer is less clear.

For example, my bank asks me for random letters from my password (eg 6th and 10th) when I phone them. If someone's chosen a 100 letter string of arbitrary Unicode characters, that isn't going to work.

Similarly, if you're using a system where the password is processed and hashed by third party client software before it's transmitted, you've got a choice between trusting every client vendor to have got their UTF-8 canonicalization algorithms correct, or restricting the available characters in a password to reduce the possible points of failure. It's a reasonable engineering decision to choose the latter.


The only half-way decent reason I can see for limiting password lengths is to avoid transmitting extremely large amounts of data. It would be possible to DDOS a site through a username/password field if you could use arbitrarily large values.

Eventually the password will be hashed (I hope) and be a fixed size, but before that there is no limit unless one is enforced.

Not necessarily a good reason (perhaps a good reason to limit passwords to 1024 characters) but the only remotely valid reason I can think of.


A lot of these systems are using a mainframe for the back-end. Traditionally there has always been a limit on the size of the password there. Usually max of 8 characters. Also, a lot of these systems are using COBOL, so now you're dealing with fixed-length records.


It could be that from the bank's point of view, not much additional security is gained by complex passwords. Users are constantly typing their passwords into phishing sites anyway, so why not make them easier to remember?

All banks are required to use multifactor authentication now. (Compliance was required by Dec 31, 2006 - see FDIC FIL-103-2005) I'll bet Chase has set a token on the machine you log in with, and if you use another machine, you will get challenge questions in addition to having to supply a username/password. That's the cheapest way. Some banks use services that are a lot more sophisticated. They'll do things like keep a record of what IPs you've logged in from and what the geolocations were and calculate a level of risk based on historical data. If the risk rating is low enough, they let you pass. Pretty interesting stuff.

Let me clarify. We do not limit password length where I work, but there was some discussion about it. Thankfully we were able to avoid it.

This was the reasoning: You or I would create a strong password and either memorize it or stick in in KeePass or something similar. The customers not comfortable with computers would also create a long password; AARP (not meant to be critical; I get the AARP magazine) and other trusted sources have told them they should. This would guarantee that the password will then be written on a post-it note and stuck in a wallet, purse, or under the keyboard. Thus, permitting longer and harder to remember passwords harms security more than it helps.

Perhaps at Chase this line of reasoning won out. And, as I said above, the password is only part of the login security. The challenge questions are the weak point of those things.


The only reason I can think of is to make the password easy to remember.
It's an accessibility issue and nothing less.


Somewhere you'll hit the limits of some buffer but there's no reason to restrict it to less than this.


A lot of banks will often ask you to provide certain characters from your password rather than the whole password and they are usually used in conjunction with a pin. If they are doing this the password can't be stored as a hash as they wouldn't be able to validate the characters provided. Its probably just a limit to keep it useable for their customers as working out what the 128th and 156th letter of your password isn't going to be very easy.


The bank doesn't store the password, only the hash, probably the MD5 hash, of the password in their database. If I crack their database server and copy their 'users' table, I might be able to find out that your password's hash is 2A33DEF55D05003488AB90ABC552FF31.

Even if you've chosen a strong password, it's possible for me to find a string with that same MD5 hash. However, finding a string of a specified length with that same hash is much less likely - especially because there are far fewer than 2^128 8-character passwords.


I once used Osewiesewosewiesewallakristalla as a password. It's part of the text of some childish song. For me, easy to remember.:-) Unfortunately it's way too long for most password dialogs.

Why would companies add some additional restrictions to passwords? The only reason I can come up with is to make it easier to crack those passwords! If you only store a hash value calculated over some password then password recovery tends to be difficult. But if the password is limited to 8 lowercase characters and digits only then you can still crack all passwords relatively easy. There would be only 2.821.109.907.456 possible values and although it seems a lot, they're easy to store on a 1 TB harddisk. Okay, if they allow uppercase characters, spaces and shorter passwords, it becomes a bit more difficult but still, such restrictions make it easier to crack their own passwords!

Why would a company ever need to crack passwords? I don't have a clue. Hey, what are those black helicopters doing above my house? ;-)