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

51–60 of 128 posts

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

#51

Post by statictype »

cpeterso wrote: post #27
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.

Even if saving database space is a concern, you could store a truncated password hash.

If you don't use the full hash, I believe you can't really make any guarantees about the variance and distribution of characters in the hash. So not sure that's such a good idea.

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

#52

Post by mattchamb »

andreasvc wrote: post #49
mattchamb wrote: post #26

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

Why don't you just tell them that for technical reasons, the lowest you "can" limit it to is 12 characters?

I'm just not part of any of those discussions. Besides, the code around passwords and their configuration has barely changed in the last decade; and the people who wrote it are now the ones discussing security with the banks.

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

#53

Post by just2n »

derefr wrote: post #40
just2n wrote: post #35

Earlier quoted context omitted.

That's why the client should perform the hash and only submit the result.

No; this is effectively the same as doing no hashing at all. If your database gets stolen, people can replay the "hashed" passwords from it to the server, without having to hash them themselves.

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 that is fairly insensitive to attack in itself. So perhaps a user has 2 salts associated with their account, per password: an auth salt and a storage salt. Then an auth looks something like this:

    hash(saltFromServer + hash(password))
And then the server would do

    hash(user.salt + clientHash)
I'm not sure, but this seems reasonable to me.

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

#54

Post by rbirkby »

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.

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

#55

Post by birchbird »

cpeterso wrote: post #27
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.

Even if saving database space is a concern, you could store a truncated password hash.

If you'll go as far as saving a truncated hash, it's better to just save the whole thing. I don't see any good reasons not to.

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

#56

Post by edanm »

btilly wrote: post #22
bjourne wrote: post #19

Earlier quoted context omitted.

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

Thanks for the explanation, didn't know that.

Is this true in most modern DBs? (I'm thinking MySQL and Postgres particularly).

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

#57

Post by lucaspiller »

btilly wrote: post #22
bjourne wrote: post #19

Earlier quoted context omitted.

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

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

#58

Post by lucaspiller »

geuis wrote: post #42

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

I believe that is true for a lot of cases. People seem to overlook this, but I'd guess that is the reason for a lot of cases.

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

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

#59

Post by lucaspiller »

cbhl wrote: post #18
manojlds wrote: post #14

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

May I ask what bank you bank with?

All UK financial institutions I have used do this: Nationwide, Barclay's, Natwest (RBS).

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

#60

Post by Sprint »

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.

Either the submitted URL was changed or you are wrong. The URL goes to the page, not some anchor.
Post reply on HN