Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

security.stackexchange.com

Post reply on HN
Print view View original

71–80 of 128 posts

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

#71

Post by godfreykfc »

tjoff wrote: post #44
godfreykfc wrote: post #31

Earlier quoted context omitted.

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)

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.

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

#72

Post by dsego »

jl6 wrote: post #39
ianterrell wrote: post #6

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

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

#74

Post by quesera »

lucaspiller wrote: post #57
btilly wrote: post #22

Earlier quoted context omitted.

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 arbitr…

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.

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

#75

Post by drostie »

dsego wrote: post #73

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.

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

#76

Post by jfb »

duaneb wrote: post #46
alxndr wrote: post #45

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.

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

#77

Post by nl »

fruchtose wrote: post #8

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.

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)

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

#78

Post by dhimes »

nl wrote: post #77
fruchtose wrote: post #8

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.

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)

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

#79

Post by luma »

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

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

#80

Post by drdaeman »

icebraining wrote: post #70
just2n wrote: post #53

Earlier quoted context omitted.

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 tha…

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?
Post reply on HN