Why websites have password length limits, if they’re hashed anyway?
In: 16
The program still has to handle the string to take it from the input into the hash function. The bigger the string you’re allowing, the more memory you’re devoting to the program to handle it. At some point, it’s diminishing returns; maybe one person in a hundred will use a 12-character password; maybe only one in a thousand will use a 16-character password; probably only one in ten thousand will even think to use a 20-character password. Do you want to allocate 40% more memory for *every* password interaction for the sake of those 0.01% of users?
Websites do this for a few reasons.
* Arbitrarily large passwords are hard to test.
If you allow thousands of characters in a password, then at some point you may run into issues. If you’re properly testing your software, you should at least test edge cases like “the largest possible password” to see if they actually work. You can’t do that if you don’t have *some* limit.
Some systems do the hash on the server side, to protect against broken clientside code, because it was easier, or because they just decided to design it that way. In this case, you not only need to know that your software can handles long passwords, but you need every step along the way to work too. Firewalls, network hardware, other software….
You also need to be consistent. Some sites have gotten burned in the past because the password change page allowed you to set a password longer than the login page would accept. Users could lock themselves out of their accounts by accident this way. (This happened to Paypal at one point).
Defining a limit allows you to test that limit.
* One of the cardinal rules is *do not truncate user passwords*.
By not setting a limit, you may end up doing this by accident. Perhaps some part of the chain truncates strings by default, and you don’t realize it. This could make a user’s password substantially less secure, and with no feedback to them at all. Instead, a password field should accept a very long password and give the user feedback that it’s too long and allow them to fix it. Again, this goes back to testing.
* Arbitrarily long passwords can allow DoS attacks.
Hashing algorithms take longer to process longer inputs. If your system doesn’t set some limit, then maybe someone uploads a multiple gigabyte text file as their “password” to lock down one of your server processes.
Because this can be mitigated with rate limiting, it’s probably a secondary concern.
———————–
Ultimately the problem with many sites is not that they set a limit on long passwords, but that the limit is *too low*. A 100 character password should be possible on just about any system in use today. There’s no excuse for sites choosing to set a limit much lower than this. Yet we sometimes see banks setting a limit to 8 characters or something absurdly low.
Hashing the passwords protects users (somewhat) if the database storing the passwords is stolen/copied. Instead of being able to see a user’s actual password, they only see a hash with no way to turn that back into the original password. They can still try to guess what it is by putting their guesses through the same hash method and comparing the results with what they see in the database. How long it takes for this to work depends on where your password is on their list of things to guess.
If the hacker knows the website only allows a maximum of four numerical digits for the passwords, then they know there are only 10^(4) (10,000) possible combinations that any password can be. This means they only need a maximum of 10,000 guesses to crack your password.
But if you allow upper and lowercase letters as well without changing the length, that’s now 56 new characters plus the original 10 so now there are 66^(4) (18,974,736) possible combinations that the hacker potentially has to work through.
If you increase the maximum length of the passwords to, say, 20 characters and keep the digits-only constraint, there are now 10^(20) (100,000,000,000,000,000,000) possible combinations. And tossing the letters back in makes it 66^(20) (about 2.46 x 10^(36)). That’s not even including special characters, which most websites do allow.
So you can see that by allowing longer passwords, it greatly increases the number of possible combinations that a hacker must try, which greatly reduces their chances of successfully guessing with random guesses.
Ignorance and stupidity. Here’s the UK [cyber security centre’s recommendations](https://www.ncsc.gov.uk/collection/passwords/updating-your-approach). You’ll see they explicitly recommend against complexity requirements. It’s counterproductive.
> you should specify a minimum password length, to prevent very short passwords from being used. Avoid using any maximum length requirements that a user might try to exceed, as they will make it harder for users to choose a suitable password that fits the length criteria
A longer and stronger password makes it safer on your end. Hashing them with salt in DB makes them safer on server’s end. Your password is safe when both ends are safe.
Why websites have password length limits, if they’re hashed anyway?
In: 16
The program still has to handle the string to take it from the input into the hash function. The bigger the string you’re allowing, the more memory you’re devoting to the program to handle it. At some point, it’s diminishing returns; maybe one person in a hundred will use a 12-character password; maybe only one in a thousand will use a 16-character password; probably only one in ten thousand will even think to use a 20-character password. Do you want to allocate 40% more memory for *every* password interaction for the sake of those 0.01% of users?
Websites do this for a few reasons.
* Arbitrarily large passwords are hard to test.
If you allow thousands of characters in a password, then at some point you may run into issues. If you’re properly testing your software, you should at least test edge cases like “the largest possible password” to see if they actually work. You can’t do that if you don’t have *some* limit.
Some systems do the hash on the server side, to protect against broken clientside code, because it was easier, or because they just decided to design it that way. In this case, you not only need to know that your software can handles long passwords, but you need every step along the way to work too. Firewalls, network hardware, other software….
You also need to be consistent. Some sites have gotten burned in the past because the password change page allowed you to set a password longer than the login page would accept. Users could lock themselves out of their accounts by accident this way. (This happened to Paypal at one point).
Defining a limit allows you to test that limit.
* One of the cardinal rules is *do not truncate user passwords*.
By not setting a limit, you may end up doing this by accident. Perhaps some part of the chain truncates strings by default, and you don’t realize it. This could make a user’s password substantially less secure, and with no feedback to them at all. Instead, a password field should accept a very long password and give the user feedback that it’s too long and allow them to fix it. Again, this goes back to testing.
* Arbitrarily long passwords can allow DoS attacks.
Hashing algorithms take longer to process longer inputs. If your system doesn’t set some limit, then maybe someone uploads a multiple gigabyte text file as their “password” to lock down one of your server processes.
Because this can be mitigated with rate limiting, it’s probably a secondary concern.
———————–
Ultimately the problem with many sites is not that they set a limit on long passwords, but that the limit is *too low*. A 100 character password should be possible on just about any system in use today. There’s no excuse for sites choosing to set a limit much lower than this. Yet we sometimes see banks setting a limit to 8 characters or something absurdly low.
Hashing the passwords protects users (somewhat) if the database storing the passwords is stolen/copied. Instead of being able to see a user’s actual password, they only see a hash with no way to turn that back into the original password. They can still try to guess what it is by putting their guesses through the same hash method and comparing the results with what they see in the database. How long it takes for this to work depends on where your password is on their list of things to guess.
If the hacker knows the website only allows a maximum of four numerical digits for the passwords, then they know there are only 10^(4) (10,000) possible combinations that any password can be. This means they only need a maximum of 10,000 guesses to crack your password.
But if you allow upper and lowercase letters as well without changing the length, that’s now 56 new characters plus the original 10 so now there are 66^(4) (18,974,736) possible combinations that the hacker potentially has to work through.
If you increase the maximum length of the passwords to, say, 20 characters and keep the digits-only constraint, there are now 10^(20) (100,000,000,000,000,000,000) possible combinations. And tossing the letters back in makes it 66^(20) (about 2.46 x 10^(36)). That’s not even including special characters, which most websites do allow.
So you can see that by allowing longer passwords, it greatly increases the number of possible combinations that a hacker must try, which greatly reduces their chances of successfully guessing with random guesses.
Ignorance and stupidity. Here’s the UK [cyber security centre’s recommendations](https://www.ncsc.gov.uk/collection/passwords/updating-your-approach). You’ll see they explicitly recommend against complexity requirements. It’s counterproductive.
> you should specify a minimum password length, to prevent very short passwords from being used. Avoid using any maximum length requirements that a user might try to exceed, as they will make it harder for users to choose a suitable password that fits the length criteria
A longer and stronger password makes it safer on your end. Hashing them with salt in DB makes them safer on server’s end. Your password is safe when both ends are safe.
Latest Answers