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.
Oh you mean that the number 256 overflows into 0 in 8-bit range. My joke was leaning more into the idea that when you use all 256 possible bit combinations (1111 1111), it can represent -1 in signed integer formats. Even though 255 is the highest number you can directly represent, there are still 256 total combinations, including zero, so IMO, the joke works.
And sure, in theory your hashing browser-side could break if you do that. Depending on how much text the user pastes in. But at that point, it’s no longer your problem but the browser’s. 🦹
It doesn’t matter too much. It’s well past the point where fully random passwords are impossible to brute force in this universe. Even well conceived passphrases won’t get that long. If you’re really bothered by it, you can sha256 the input before feeding it to bcrypt/scrypt, but it doesn’t really matter.
wouldn’t you then just break it up into chunks of 72 bytes, hash them individually, and concatenate the hashes? And if that’s still too long, split the hash into 72 byte chunks and repeat until it’s short enough?
I don’t know the specifics behind why the limit is 72 bytes, but that might be slightly tricky. My understanding of bcrypt is that it generates 2^salt different possible hashes for the same password, and when you want to test an input you have to hash the password 2^salt times to see if any match. So computation times would get very big if you’re combining hashes
Why would you not hash in the browser. Doing so makes sure the plaintext password never even gets to the server while still providing the same security.
Because then the hash is the password. Someone could just send the hash instead of trying to find a password that gets the correct hash. You can’t trust the client that much.
You can hash the password on both sides to make it work; though I’m not sure why you’d want to. I’m not sure what attack never having the plain text password on the server would prevent. Maybe some protection for MITM with password reuse?
Per your edit, you’re misunderstanding what Bitwarden does and why it’s different than normal web site password storage.
Bitwarden is meant to not have any insight into your stored passwords what so ever. Bitwarden never needs to verify that the passwords you’ve stored match your input later on. The password you type into Bitwarden to unlock it is strictly for decrypting the database, and that only happens client side. Bitwarden itself never needs to even get the master password on the server side (except for initial setup, perhaps). It’d be a breach of trust and security if they did. Their system only needs to store encrypted passwords that are never decrypted or matched on their server.
Typical website auth isn’t like that. They have to actually match your transmitted password against what’s in their database. If you transmitted the hashed password from the client and a bad actor on the server intercepted it, they could just send the hashed password and the server would match it as usual.
You could salt it. Distributing a unique salt doesn’t help attackers much. Salt is for preventing precomputing attacks against a whole database. Attacking one password hash when you know the salt is still infeasible.
It’s one of those things in security where there’s no particular reason to give your attacker information, but if you’ve otherwise done your job, it won’t be a big deal if they do.
You don’t hash in the browser because it doesn’t help anything.
It helps against the server being able to read the password, so a bad actor (either the website itself or after a hack) could read your password. Which isn’t bad if you’re using good password hygiene with random passwords, but that sadly is not the norm.
If you hash in the browser it means you don’t salt your hash. You should absolutely salt your hash, not doing so makes your hashes very little better than plaintext.
Even 255 bytes with 10 million entries is only ~2.6GB of data you need to store, and if you have 10 million users the probably $1 a month extra that would cost is perfectly fine.
I suppose there may be a performance impact too since you have to read more data to check the hash, but servers are so fast now it doesn’t seem like that would be significant unless your backend was poorly made.
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.
16 characters is too low. I’d say a good upper limit would be 100, maybe 255 if you’re feeling generous.
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.
The eBay password limit is 256 characters.
They made the mistake of mentioning this when I went to change my password.
Guess how many characters my eBay password has?
Just paste it in here and I count the characters for you.
-1?
0*
I’m not sure what you’re implying with this. But how did you dig this up anyway?
255=-1, 256=0
btw, the internet never forgets
Oh you mean that the number 256 overflows into 0 in 8-bit range. My joke was leaning more into the idea that when you use all 256 possible bit combinations (
1111 1111), it can represent -1 in signed integer formats. Even though 255 is the highest number you can directly represent, there are still 256 total combinations, including zero, so IMO, the joke works.The problem is that you (hopefully) hash the passwords, so they all end up with the same length.
And sure, in theory your hashing browser-side could break if you do that. Depending on how much text the user pastes in. But at that point, it’s no longer your problem but the browser’s. 🦹
Why are you hasing in the browser?
Also, what hashing algorithm would break with large input?
bcrypt has a maximum password length of 72 bytes.
https://en.wikipedia.org/wiki/Bcrypt#Maximum_password_length
Damm, I legit didn’t knew there bcrypt had a length limit! Thank you for another reason not to use bcrypt
Scrypt has the same limit, FWIW.
It doesn’t matter too much. It’s well past the point where fully random passwords are impossible to brute force in this universe. Even well conceived passphrases won’t get that long. If you’re really bothered by it, you can sha256 the input before feeding it to bcrypt/scrypt, but it doesn’t really matter.
wouldn’t you then just break it up into chunks of 72 bytes, hash them individually, and concatenate the hashes? And if that’s still too long, split the hash into 72 byte chunks and repeat until it’s short enough?
I don’t know the specifics behind why the limit is 72 bytes, but that might be slightly tricky. My understanding of bcrypt is that it generates 2^salt different possible hashes for the same password, and when you want to test an input you have to hash the password 2^salt times to see if any match. So computation times would get very big if you’re combining hashes
Why would you not hash in the browser. Doing so makes sure the plaintext password never even gets to the server while still providing the same security.
Edit: I seem to be getting downvoted… Bitwarden does exactly what I described above and I presume they know more than y’all in terms of security https://bitwarden.com/help/what-encryption-is-used/#pbkdf2
Because then the hash is the password. Someone could just send the hash instead of trying to find a password that gets the correct hash. You can’t trust the client that much.
You can hash the password on both sides to make it work; though I’m not sure why you’d want to. I’m not sure what attack never having the plain text password on the server would prevent. Maybe some protection for MITM with password reuse?
Per your edit, you’re misunderstanding what Bitwarden does and why it’s different than normal web site password storage.
Bitwarden is meant to not have any insight into your stored passwords what so ever. Bitwarden never needs to verify that the passwords you’ve stored match your input later on. The password you type into Bitwarden to unlock it is strictly for decrypting the database, and that only happens client side. Bitwarden itself never needs to even get the master password on the server side (except for initial setup, perhaps). It’d be a breach of trust and security if they did. Their system only needs to store encrypted passwords that are never decrypted or matched on their server.
Typical website auth isn’t like that. They have to actually match your transmitted password against what’s in their database. If you transmitted the hashed password from the client and a bad actor on the server intercepted it, they could just send the hashed password and the server would match it as usual.
With comments like this all over public security forums, it’s no wonder we have so many password database cracks.
Because then that means you don’t salt your hashes, or that you distribute your salt to the browser for the hash. That’s bad.
You could salt it. Distributing a unique salt doesn’t help attackers much. Salt is for preventing precomputing attacks against a whole database. Attacking one password hash when you know the salt is still infeasible.
It’s one of those things in security where there’s no particular reason to give your attacker information, but if you’ve otherwise done your job, it won’t be a big deal if they do.
You don’t hash in the browser because it doesn’t help anything.
It helps against the server being able to read the password, so a bad actor (either the website itself or after a hack) could read your password. Which isn’t bad if you’re using good password hygiene with random passwords, but that sadly is not the norm.
It doesn’t. It just means the attacker can send the hash instead of the password.
If you hash in the browser it means you don’t salt your hash. You should absolutely salt your hash, not doing so makes your hashes very little better than plaintext.
There’s nothing stopping a browser from salting a hash. Salts don’t need to be kept secret, but it should be a new random salt per user.
Even 255 bytes with 10 million entries is only ~2.6GB of data you need to store, and if you have 10 million users the probably $1 a month extra that would cost is perfectly fine.
I suppose there may be a performance impact too since you have to read more data to check the hash, but servers are so fast now it doesn’t seem like that would be significant unless your backend was poorly made.
Yeah but what if I have one user with 9.9 million accounts? That bastard
Account georg