8 ms·

I thought it could get hashed client side

• VWWHFSfQ 4y ago
  Then the hashed password is effectively the plaintext password
  • thamer 4y ago
    It's not the same. If you the un-hashed password leaks it can often be used to authenticate on other websites since people reuse passwords. You can't do that if all you have is the hashed password.
    • alophawen 4y ago
      Does it matter when you can use the hashed password to log in?
      • jaywalk 4y ago
        I think you missed the other websites reference. If you're at the point of being able to steal the table of users, you're probably not too concerned about using the credentials to login to that website.
  • sascha_sl 4y ago
    Except, if you run rounds on the client and server, you now never handle plain passwords (that users might be reusing) and reversing the thing you store into something you can use against that services' API is still just as hard (if not harder because you need to do either do the total rounds on plain or the server rounds on a very long input)
  • lxgr 4y ago
    Not if it's scoped to the username/domain in some way (e.g. by making the client-sent value H(password, username, domain) rather than just password or H(password)). But that would require a canonical and secure (i.e. not (only) controlled by server-fetched code) way of client-side password preprocessing, and if you have that, you can just as well use a PAKE, modern instances of which have all of these nice properties and more.