I sort of get it. You don’t want to allow the entire work of Shakespeare in the text field, even if your database can handle it.
You don’t store the original text. You store the hash of it. If you SHA512 it, anything that’s ever given in the password field will always be 64Bytes.
The only “legit” reason to restrict input to 16 character is if you’re using an encryption mechanism that just doesn’t support more characters as an input. However, if that’s the case, that’s a site I wouldn’t want to use to begin with if at all possible.
I’ll admit I kind of typed this without thinking it through. In a secured site, the password would be hashed and salted before storing in the database.
Depending on where you’re doing the hashing, long strings might still slow you down. That being said, from a security standpoint, any gain in entropy by adding characters would be negligible past a certain point. I don’t remember what that number is but it certainly isn’t in the thousands.
That being said, from a security standpoint, any gain in entropy by adding characters would be negligible past a certain point.
That would be completely based on the hash being used. In the example above I showed SHA512 which is 64Bytes. If we’re using ASCII (7 bit per character) as our input then 64 Bytes is just over 73(73.1428…) characters. After that you’re losing data in the hashing process and by that effect it would be negligible… (There’s some wiggle room here in that we can’t type hidden ASCII characters so some passwords over 73 characters would fill those spaces… but detecting collisions is silly and non-trivial… better to just not worry about those at all.)
Extended ASCII would be same premise, just 64 characters instead of 73.
The reality is that nobody is using much more than 64 Bytes for their hashing algorithm for passwords… 64 characters is a good number to max out most of them. Databases don’t need to store much at all regardless of the length of your actual password. If you’re developing an app you can set the database to limit based on the algorithms you’re using. If you have no idea what the web-dev will actually use… then 128 characters on the database field is probably pretty safe (88 I think if storing as Base64, 128 if storing in Hex. Could be off by one here.) and literally trivial to store. The point being that even if every one of your users submitted 10000 character long passwords… that’s irrelevant and trivial for storage as hashes.
There’s a more practical limit. Using US standard keyboard symbols, a 40 char password is about as secure as a 256-bit block cipher key. That’s impossible to break due to thermodynamic limits on computing.
The reason to put a high char limit is to mitigate DoS attacks. It can still be a few hundred chars.
The resulting hash will always be the same size, but you don’t want to have an unlimited upper bound otherwise I’m using a 25GB blueray rip as my password and your service is going to have to calculate the hash of that whenever I login.
Sensible upper bounds are a must to provide a reliable service not open to DDOS exploits.
You don’t store the original text. You store the hash of it. If you SHA512 it, anything that’s ever given in the password field will always be 64Bytes.
The only “legit” reason to restrict input to 16 character is if you’re using an encryption mechanism that just doesn’t support more characters as an input. However, if that’s the case, that’s a site I wouldn’t want to use to begin with if at all possible.
I’ll admit I kind of typed this without thinking it through. In a secured site, the password would be hashed and salted before storing in the database.
Depending on where you’re doing the hashing, long strings might still slow you down. That being said, from a security standpoint, any gain in entropy by adding characters would be negligible past a certain point. I don’t remember what that number is but it certainly isn’t in the thousands.
That would be completely based on the hash being used. In the example above I showed SHA512 which is 64Bytes. If we’re using ASCII (7 bit per character) as our input then 64 Bytes is just over 73(73.1428…) characters. After that you’re losing data in the hashing process and by that effect it would be negligible… (There’s some wiggle room here in that we can’t type hidden ASCII characters so some passwords over 73 characters would fill those spaces… but detecting collisions is silly and non-trivial… better to just not worry about those at all.)
Extended ASCII would be same premise, just 64 characters instead of 73.
The reality is that nobody is using much more than 64 Bytes for their hashing algorithm for passwords… 64 characters is a good number to max out most of them. Databases don’t need to store much at all regardless of the length of your actual password. If you’re developing an app you can set the database to limit based on the algorithms you’re using. If you have no idea what the web-dev will actually use… then 128 characters on the database field is probably pretty safe (88 I think if storing as Base64, 128 if storing in Hex. Could be off by one here.) and literally trivial to store. The point being that even if every one of your users submitted 10000 character long passwords… that’s irrelevant and trivial for storage as hashes.
There’s a more practical limit. Using US standard keyboard symbols, a 40 char password is about as secure as a 256-bit block cipher key. That’s impossible to break due to thermodynamic limits on computing.
The reason to put a high char limit is to mitigate DoS attacks. It can still be a few hundred chars.
you might compare 1,000 to 10,000, but more like 0.1% to 0.01%
meaning of this? no. bad grammar.
The resulting hash will always be the same size, but you don’t want to have an unlimited upper bound otherwise I’m using a 25GB blueray rip as my password and your service is going to have to calculate the hash of that whenever I login.
Sensible upper bounds are a must to provide a reliable service not open to DDOS exploits.