Password Length Limitations — Always an Indication of Clear Text Storage?

As a long time listener of Security Now, a consumer oriented security podcast, I wanted to challenge one of the statements Steve Gibson regularly makes. The statement I want to challenge is that if passwords have length restrictions, they’re stored in clear text. My position is that it can be an indicator, but there can and should be password length restrictions. Let me dissect this a bit further.

Mr. Gibson often makes the statement that if passwords are hashed, it doesn’t matter what length they are. The resultant length of the hash process is the same regardless of whether it is 1 or 1000 characters. Therefore the site doesn’t and shouldn’t care if a password is too long because it will always be represented in the database by a fixed number of bytes in the form of a hash.

I disagree with categorically making the statement that a password length maximum, 15 characters for example, means that the password is being stored in the clear. It certainly may be, but this is not something that can be determined by this fact alone. So assuming passwords are hashed, why would a site have a password restriction? It certainly doesn’t affect the size of the representation in the database?

One reason I can think of for such restriction is input validation. We all know that websites that take input are prime targets for attackers. Input fields need some form of limits. Going to another extreme, what might happen if an attacker sent a million characters in the password field? This would either take cpu and memory resources from the hashing component, create a buffer overflow condition, or have to be truncated at some point in the process. Additionally, if we pound the concept of input validation into the minds of programmers, the absence of password limits would violate that important principle.

It is for those reasons that I believe some programmers may (and should) impose reasonable restrictions on passwords, perhaps 50 maximum characters. If the threshold is crossed,  I think it is more appropriate to provide feedback to the user than it is to truncate the passwords prior to processing. It might also be reasonable to flag the transaction for more aggressive monitoring. For those who happened to have read my article about password normalization, my opposition to password normalization prior to processing is probably understood. My opposition to password truncation without notification is similar.

I do think there are valid security reasons to place maximum limits on the length of passwords. It is for this reason that I do not think we can or should categorically state that a password length limitation is synonymous with clear text storage of passwords. For me, the only indisputable test to indicated passwords are not being hashed is if the password can be provided back to the user. In that case, the password is certainly not being hashed. With that being said, I have a lot of respect for Mr. Gibson and enjoy his podcast. He is certainly doing his part to educate the user community at large.

No related content found.

About Paul Stewart, CCIE 26009 (Security)

Paul is a Network and Security Engineer, Trainer and Blogger who enjoys understanding how things really work. With over 15 years of experience in the technology industry, Paul has helped many organizations build, maintain and secure their networks and systems.
This entry was posted in Other. Bookmark the permalink.