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 loved the analogy, it's sad that more people didn't read it.
What technical reasons are there to have low maximum password lengths?
21–30 of 128 posts
Re: What technical reasons are there to have low maximum password lengths?
#22Earlier quoted context omitted.
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.
Re: What technical reasons are there to have low maximum password lengths?
#23"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.
Re: What technical reasons are there to have low maximum password lengths?
#24It's amazing how all the comments so far have entirely missed that it's the top answer that was really submitted, not the question.
[deleted]
Re: What technical reasons are there to have low maximum password lengths?
#25"Because it's hard enought remember 12 characters already" -my bank's tech support
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. T…
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.
Re: What technical reasons are there to have low maximum password lengths?
#26I 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.
Re: What technical reasons are there to have low maximum password lengths?
#27There'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.
Even if saving database space is a concern, you could store a truncated password hash.
Re: What technical reasons are there to have low maximum password lengths?
#28It's amazing how all the comments so far have entirely missed that it's the top answer that was really submitted, not the question.
It doesn't look like it still does, as the link is to ".../questions/33470/..."
Re: What technical reasons are there to have low maximum password lengths?
#29The 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, Authori…
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"?
Re: What technical reasons are there to have low maximum password lengths?
#30Earlier quoted context omitted.
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).