4 ms·
If you take your idea and step through the login//authentication process, you'll find that what you're suggesting isn't really all that different to what is don
by DistractionRect 7y ago
If you take your idea and step through the login//authentication process, you'll find that what you're suggesting isn't really all that different to what is done normally.
Overview, Scheme_0:
- You send your unique identifier (email, username, etc) and password to the server in plaintext.
- The server looks up the password hashing scheme and salt associated with your identifier
- The server checks that salt+password+hashing scheme produce the stored hash
- Server kicks back proper response
In your scenario, Scheme_1:
- You prehash the password locally and send your identifier + prehashed_password to the server
- The server looks up the password hashing scheme and salt associated with your identifier
- The server checks that salt+prehashed_password+hashing scheme produce the stored hash
- Server kicks back proper response
The only difference is the extra hashing step. From a security perspective, there is no gain; storing the prehashed_password from Scheme_1 in plaintext (e.g. logs) is no different than storing the password from Scheme_0 in plaintext.
- forty 7y agoThe difference is that the password of scheme 0 is probably reused on many other websites. If for example you bcrypt the password client side, you at least don't have to deal with credentials that might work with all the other websites that your user is using.
- twblalock 7y agoPassword reuse on other sites is not your problem. It is your user's problem.
- eropple 7y agoA fuck-you,-got-mine sort of approach to security doesn't work. It's everyone's problem. PAKEs are probably a good idea across the board.
- stevenwliao 7y agoHow do you bcrypt at an appropriate difficulty client-side? Consider that it probably needs to work on a mid-range Android phone from years ago.