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.
Sensible upper bounds are a must to provide a reliable service not open to DDOS exploits.
If I choose to make you hash it in browser first… Then I simply don’t care do I? I can hash/salt again when I get your hash.
Edit: There are other answers to the “DDOS problem” that don’t require upper bounds.
And a meteor can hit my server the exact time you send your hash which will DOS you/others as well. What’s your point.
The thread is talking about what it takes to store passwords. There is not DOS potential in a well designed system. Just because you want to arbitrarily conjure up bullshit doesn’t make that any less true.
Rejecting large inputs != disallowing users to have large passwords. Why are you attempting to straw-man me here?
You were saying the input size doesn’t matter because you only store the hash which is always the same size. What I’m saying is that the input size really does matter.
You absolutely should set upper limits on all input fields because it will be abused if you don’t. Systems should validate their inputs, passwords included
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.
you might compare 1,000 to 10,000, but more like 0.1% to 0.01%
meaning of this? no. bad grammar.
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.
If I choose to make you hash it in browser first… Then I simply don’t care do I? I can hash/salt again when I get your hash. Edit: There are other answers to the “DDOS problem” that don’t require upper bounds.
You can make a client hash it, but if you don’t reject large inputs to your API a client can send enough data to DOS you anyway.
And a meteor can hit my server the exact time you send your hash which will DOS you/others as well. What’s your point.
The thread is talking about what it takes to store passwords. There is not DOS potential in a well designed system. Just because you want to arbitrarily conjure up bullshit doesn’t make that any less true.
Rejecting large inputs != disallowing users to have large passwords. Why are you attempting to straw-man me here?
You were saying the input size doesn’t matter because you only store the hash which is always the same size. What I’m saying is that the input size really does matter.
You absolutely should set upper limits on all input fields because it will be abused if you don’t. Systems should validate their inputs, passwords included