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 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.
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.
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.
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.
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)
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.
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.
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?
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.
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.
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.
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.
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.
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.
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.
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 ;)
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.
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 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.
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?
[+] [-] ianterrell|13 years ago|reply
[+] [-] vinhboy|13 years ago|reply
[+] [-] niggler|13 years ago|reply
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.
[+] [-] harkenthus|13 years ago|reply
[+] [-] zheng|13 years ago|reply
[+] [-] jl6|13 years ago|reply
[+] [-] iaw|13 years ago|reply
[+] [-] Sprint|13 years ago|reply
[+] [-] unknown|13 years ago|reply
[deleted]
[+] [-] mistercow|13 years ago|reply
Needless to say, I found that to be even more disconcerting than the existence of the character limit.
[+] [-] fruchtose|13 years ago|reply
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|13 years ago|reply
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.
[+] [-] nl|13 years ago|reply
(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)
[+] [-] cpeterso|13 years ago|reply
[+] [-] manojlds|13 years ago|reply
[+] [-] godfreykfc|13 years ago|reply
[+] [-] andreasvc|13 years ago|reply
[+] [-] cbhl|13 years ago|reply
[+] [-] luma|13 years ago|reply
[1]http://en.wikipedia.org/wiki/CICS
[2] http://pic.dhe.ibm.com/infocenter/cicsts/v4r2/index.jsp?topi...
[+] [-] throwaway125|13 years ago|reply
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|13 years ago|reply
[+] [-] shanelja|13 years ago|reply
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.
[+] [-] throwaway125|13 years ago|reply
[+] [-] mistercow|13 years ago|reply
[+] [-] codesuela|13 years ago|reply
[+] [-] rbirkby|13 years ago|reply
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|13 years ago|reply
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|13 years ago|reply
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|13 years ago|reply
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...
[+] [-] zdw|13 years ago|reply
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|13 years ago|reply
[+] [-] mattchamb|13 years ago|reply
[+] [-] andreasvc|13 years ago|reply
[+] [-] csomar|13 years ago|reply
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|13 years ago|reply
-my bank's tech support
[+] [-] INTPenis|13 years ago|reply
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.
[+] [-] sliverstorm|13 years ago|reply
"Because we estimate the added costs of supporting users will increase by X due to more users forgetting their password due to length"
[+] [-] alxndr|13 years ago|reply
(I wonder if they got any other people besides me bothering them because of that rule...)
[+] [-] duaneb|13 years ago|reply
[+] [-] vbuterin|13 years ago|reply
[+] [-] saadazzz|13 years ago|reply
[+] [-] mayneack|13 years ago|reply
[+] [-] anon987|13 years ago|reply
Also, I just did some Googling and it wasn't until 2009 that HP/UX supported passwords >8 characters!
[+] [-] keithpeter|13 years ago|reply
[+] [-] NateDad|13 years ago|reply
Though to be fair, when's the last time you heard about a bank's password database getting stolen?