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.
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.
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.
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?
With comments like this all over public security forums, it’s no wonder we have so many password database cracks.
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.