So the initial justifications for password length limits are based on a fallacy of limiting length to allowing bad server side password hashing to exist instead of pushing for proper PBKDF2 like implementations that allow unlimited input & protect against DOS.
A better upper limit might be that which offers no additional entropy over the collision probability of the underlying digested output i.e. If the stored hash is say 128 bits then a password longer than this will by definition be a collision with one of this length i.e. 16 bytes / ASCII characters. This means for PBKDF2 with a SHA256 wrapper 32 bytes which may be as little as 8 UTF8 4 byte characters, which suggests any limit should be byte & not character based.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
So the initial justifications for password length limits are based on a fallacy of limiting length to allowing bad server side password hashing to exist instead of pushing for proper PBKDF2 like implementations that allow unlimited input & protect against DOS.
A better upper limit might be that which offers no additional entropy over the collision probability of the underlying digested output i.e. If the stored hash is say 128 bits then a password longer than this will by definition be a collision with one of this length i.e. 16 bytes / ASCII characters. This means for PBKDF2 with a SHA256 wrapper 32 bytes which may be as little as 8 UTF8 4 byte characters, which suggests any limit should be byte & not character based.