views:

1676

answers:

14

I can understand that imposing a minimum length on passwords makes a lot of sense (to save users from themselves), but my bank has a requirement that passwords are between 6 and 8 characters long, and I started wondering...

  • Wouldn't this just make it easier for brute force attacks? (Bad)
  • Does this imply that my password is being stored unencrypted? (Bad)

If someone with (hopefully) some good IT security professionals working for them are imposing a max password length, should I think about doing similar? What are the pros/cons of this?

+2  A: 

Storage is cheap, why limit the password length. Even if you're encrypting the password as opposed to just hashing it a 64 character string isn't going to take much more than a 6 character string to encrypt.

Chances are the bank system is overlaying an older system so they were only able to allow a certain amount of space for the password.

ShaneB
Unless there is a very valid reason, passwords should hashed. Hashes result in fixed length strings. There is not space argument to make, unless the system is storing the actual password, which is arguably a terrible idea.
Stu Thompson
+25  A: 

Passwords are hashed to 32, 40, 128, whatever length. The only reason for a minimum length is to prevent easy to guess passwords. There is no purpose for a maximum length.

epochwolf
Perhaps a bank might choose to limit the password because on ATMs you can't input more than, say, 8 characters.
André Neves
I didn't think about that because my bank separates online accounts and ATM card PINs. (PINs at my bank are 3 to 4 numbers in length /\d{3,4}/)
epochwolf
well at least on ATMs, if you try a brute force attack, it'll eat your card. What I'm referring to is the password for logging on online only though.
nickf
passwords and PINs are two different things. good point, nickf.
Stu Thompson
+2  A: 

I think you're very right on both bullet points. If they're storing the passwords hashed, as they should, then password length doesn't affect their DB schema whatsoever. Having an open-ended password length throws in one more variable that a brute-force attacker has to account for.

It's hard to see any excuse for limiting password length, besides bad design.

Lucas Oman
+4  A: 

First, do not assume that banks have good IT security professionals working for them. Plenty don't.

That said, maximum password length is worthless. It often requires users to create a new password (arguments about the value of using different passwords on every site aside for the moment), which increases the likelihood they will just write them down. It also greatly increases the susceptibility to attack, by any vector from brute force to social engineering.

Sparr
Agreed! Look at that the string of UK bank online access security failures of the past few years...
Stu Thompson
A: 

Should there be a maximum length? This is a curious topic in IT in that, longer passwords are typically harder to remember, and therefore more likely to get written down (a BIG no-no for obvious reasons). Longer passwords also tend to get forgotten more, which while not necessarily a security risk, can lead to administrative hassles, lost productivity, etc. Admins who believe that these issues are pressing are likely to impose maximum lengths on passwords.

I personally believe on this specific issue, to each user their own. If you think you can remember a 40 character password, then all the more power to you!

Having said that though, passwords are fast becoming an outdated mode of security, Smart Cards and certificate authentication prove very difficult to impossible to brute force as you stated is an issue, and only a public key need be stored on the server end with the private key on your card/computer at all times.

tekiegreg
A: 

Longer passwords, or pass-phrases, are harder to crack simply based on length, and easier to remember than requiring a complex password.

Probably best to go for a fairly long (10+) minimum length, restricting the length useless.

benPearce
+1  A: 

The only benefit I can see to a maximum password length would be to eliminate the risk of a buffer overflow attack caused by an overly long password, but there are much better ways to handle that situation.

DrStalker
Nothing that very basic testing could not solve.
Stu Thompson
+6  A: 

Allowing for completely unbounded password length has one major drawback if you accept the password from untrusted sources.

The sender could try to give you such a long password that it results in a denial of service for other people. For example, if the password is 1GB of data and you spend all your time accept it until you run out of memory. Now suppose this person sends you this password as many times as you are willing to accept. If you're not careful about the other parameters involved this could lead to a DoS attack.

Setting the upper bound to something like 256 chars seems overly generous by today's standards.

Jason Dagit
You can still send 1gb of data with a maximum limit. The software doing the limiting is almost always behind the webserver.
epochwolf
You can still drop all but the first 256chars before doing something computationally intensive though. Running a sha hash on 1gb of data is going to take *much* longer than the same hash on 256 chars.
rcreswick
A: 

Just 8 char long passwords sound simply wrong. If there ought to be a limit, then atleast 20 char is better idea.

+1  A: 

One reason I can imagine for enforcing a maximum password length is if the frontend must interface with many legacy system backends, one of which itself enforces a maximum password length.

Another thinking process might be that if a user is forced to go with a short password they're more likely to invent random gibberish than an easily guessed (by their friends/family) catch-phrase or nickname. This approach is of course only effective if the frontend enforces mixing numbers/letters and rejects passwords which have any dictionary words, including words written in l33t-speak.

mbac32768
A: 

Legacy systems (mentioned already) or interfacing outside vendor's systems might necessitate the 8 character cap. It could also be a misguided attempt to save the users from themselves. Limiting it in that fashion will result in too many pssw0rd1, pssw0rd2, etc. passwords in the system.

Chuck
A: 

My bank does this too. It used to allow any password, and I had a 20 character one. One day I changed it, and lo and behold it gave me a maximum of 8, and had cut out non-alphanumeric characters which were in my old password. Didn't make any sense to me.

All the back-end systems at the bank worked before when I was using my 20 char password with non alpha-numerics, so legacy support can't have been the reason. And even if it was, they should still allow you to have arbitrary passwords, and then make a hash that fits the requirements of the legacy systems. Better still, they should fix the legacy systems.

A smart card solution would not go well with me. I already have too many cards as it is... I don't need another gimmick.

Vincent McNabb
+2  A: 

A maximum length specified on a password field should be read as a SECURITY WARNING: Any sensible, security conscious user must assume the worst and expect that this site is storing your password literally (i.e. not hashed, as explained by epochwolf).

In that that is the case: (a) avoid using this site like the plague if possible [they obviously know nuts about security] (b) if you must use the site, make sure your password is unique - unlike any password you use elsewhere.

If you are developing a site that accepts passwords, DON'T put a silly password limit, unless you want to get tarred with the same brush.

[Internally, of course your code may treat only the first 256/1028/2k/4k(whatever) bytes as "significant" to avoid crunching on mammoth passwords.]

tardate
A: 

I think the only limit that should be applied is like a 2000 letter limit, or something else insainly high, but only to limit the database size if that is an issue

joshhunt
Passwords should be hashed... And database size wouldn't be an issue is the password is hashed.
epochwolf