36

What is the reason that most websites limit to 16 characters?

I would have thought the longer the password the more difficult it makes it for someone to crack it?

Is it something to do with hash collisions?

curiousguy
  • 5,068
  • 3
  • 26
  • 27
orange
  • 483
  • 1
  • 4
  • 7
  • 1
    Good question, wondered the same thing, I know hotmail does it as well. – Lucas Kauffman Jul 31 '12 at 21:36
  • 2
    One email provider/ISP has a 10 characters limit for some passwords and 8 char for others. And they store many (not all) passwords in cleartext. – curiousguy Jul 31 '12 at 21:54
  • 2
    To prevent buffer overflows naturally ;-) – Andrew Smith Jul 31 '12 at 22:33
  • 8
    I know a site that restricts passwords to [a-zA-Z]{1,5} It is a billing portal and it scares me :( – Kurt Aug 02 '12 at 01:13
  • @Prowla Sites with such limits on passwords scare me too! – orange Aug 08 '12 at 15:28
  • Curiousguy and rook already have answered the question. 1st reason: Hashing a long password would take up memory and resources. 2nd reason: You don't want an attacker to write a book on the password field and crash your database server. 3rd reason: For God's sake, who would use a 16+ characters password? – mzcoxfde Sep 12 '16 at 14:43
  • In 2021, PayPal still enforces a 20-char limit. And they only let you use an arbitrary list of special characters: !@#$%^&*() – bryc Sep 10 '21 at 18:39

2 Answers2

32

If you are to abide by CWE-521: Weak Password Requirements. Then all passwords must have a min and max password length.

There are two reasons for limiting the password size. For one, hashing a large amount of data can cause significant resource consumption on behalf of the server and would be an easy target for Denial of Service. Especially if the server is using key stretching such as PBKDF2.

The other concerns is hash length-extension attacks or the prefixing attack against MD5. However If you are using a hash function that isn't broken, such as bcrypt or sha-256 , then this shouldn't be a concern for passwords.

IMHO 16 bytes is far too small. bcrypt has a built-in cap of 72 characters, which is probably a reasonable size for a heavy hash function. Key Stretching used by these functions creates the possibility of an Algorithmic Complexity Attack or ACA.

Community
  • 1
rook
  • 47,238
  • 10
  • 96
  • 182
  • What is a "broken hash function" in this context? – curiousguy Jul 31 '12 at 22:03
  • 4
    @curiousguy MD4, MD5 SHA0, SHA1 would be broken hash functions. – rook Jul 31 '12 at 22:04
  • "hashing a large amount of data can cause significant resource consumption" Calculating a (any) hash hardly takes CPUs. Hashes were designed for that. –  Feb 15 '13 at 08:19
  • 1
    @Jan Doggen A good password hash function, like bcrypt and PBKDF2 is most likely the heaviest calculation an application is exposing to an attacker. Key stretching by definition is an "Algorithmic Complexity Attack" or ACA. – rook Feb 15 '13 at 17:41
  • I disagree with CWE-521 on some of the points. In my opinion any reasonable password policy must satisfy this criteria: Any substring of an invalid password must also be an invalid password. And a couple of the requirements from CWE-521 conflict with that. – kasperd Jan 04 '15 at 11:05
  • 1
    I wonder why this answer was up voted so many times because I think it is wrong on all counts. ...cause significant resource consumption. Only the case for megabytes big passwords. The difference between hashing a 5 or a 50 character string is negligible. length-extension attacks This has nothing to do with the application of hashing algorithms for password security. It has to do with MACs only, which consist of a secret key part and a known message part. – mgr326639 Oct 31 '15 at 22:19
  • 16 bytes is far too small Most of my passwords are random strings in the range [a-zA-Z]{16} and I sleep very well at night knowing that a GPU brute forcing this password with 10^9 per second would still need more that the life of the universe (90*10^9 years) to calculate a hash for every possible permutation. Don't get me wrong. I think there should be a more reasonable upper limit like 100 chars. Nobody should be restricted from choosing "Nitwit Blubber Oddment Tweak" for a password. – mgr326639 Oct 31 '15 at 22:19
  • Also - in most databases where you store something setting a maximum length for fields is necessary or at least strongly recommended. So it is expected that each and every data-field has a length limit, which is set by humans to best capture the data in that field. And here someone reasoned that 16 characters should be enough for every reasonable password a long time ago (probably before password managers and pass-phrases became popular) – Falco Feb 29 '16 at 14:40
  • 2
    @Falco a secure message digest function will ensure that the resulting hash is a consent length, SHA-512 will always produce 512 bits. – rook Mar 01 '16 at 03:02
  • 4
    @JanDoggen "Hashes were designed for that" - The opposite, in fact. Key derivation functions, i.e. the hashes which are used to hash passwords, are deliberately designed to be expensive. Of course people can use cheap hash functions for password hashing, if they want to ensure the passwords get cracked quickly once their database leaks. – Peter Sep 12 '16 at 12:31
18

What is the reason that most websites limit to 16 characters?

Arbitrary implementation limit.

Maybe they only want to allocate a 17-octet buffer (16 ASCII/1-octet characters + terminating NUL).

Maybe they believe that having a password with more than 16 characters is useless or silly, because they have no understanding of passwords.

I would have thought the longer the password the more difficult it makes it for someone to crack it?

Indeed. A password with 16 random independent alphabetic characters with a uniform distribution has enough entropy. But human being are bad at randomly choosing 16 random independent alphabetic characters with a uniform distribution, and terribly bad at remembering such meaningless character sequences, so they choose passwords that they can remember, but with less entropy per character.

What matters is only the total entropy, not the entropy per character. For example, a sequence of random dictionary words, generated with a word-die (word-die: open a random page in a dictionary, etc.) is easier to remember than a sequence of letters obtained with a letter-die.

Such passwords will be longer than purely random letter sequences, but they will be a lot easier to remember for equal entropy; or, if you prefer, they will have a lot more entropy for equal mental memory effort.

For adequate strength, these passwords made of dictionary words will probably have more than 16 characters.

In other words, this limit is stupid.

Is it something to do with hash collisions?

No.

There is no formal guaranty with respect to collisions with short passwords, but the practical impact of hash collisions is non-existent.

techraf
  • 9,159
  • 11
  • 45
  • 63
curiousguy
  • 5,068
  • 3
  • 26
  • 27
  • 3
    If the max is 16 chars, there's no need for a 17th octet to hold the terminating NULL - you just read until you have either a NULL or all 16 chars. – Moshe Katz Jan 07 '15 at 02:06
  • One thing to be careful of is with words, a password cracker targeting words will likely crack even a slightly longer password than one of random characters. – Jonathan Apr 12 '19 at 19:59