3 ms·

Your proposal is equivalent to sending plaintext passwords, because the client-calculated hash can be used like a password.

• tptacek 8y ago
  No, it's not. You can capture the password-equivalent authenticator, but (assuming a strong KDF) not easily reverse it back out to a password that could be used at other sites, which is the only reason anyone cares about hiding passwords from servers in the first place.
  • Ar-Curunir 8y ago
    This doesn't prevent dictionary attacks, since there's no salt involved, AFAIK.
    • lvh 8y ago
      Since you're not worried anymore about burning the server-side resources, you prevent the dictionary attack in this scenario with a punitively expensive KDF. (Note: I am not saying this is a good idea! It's OPAQUE but worse.)
    • lucb1e 8y ago
      In the draft spec I wrote it would be salted by default with the origin (proto+domain+port), and could be overridden (in case a site changes domains) by a parameter. That would act as salt for the site, so that you have a unique hash for each site without having to keep (and sync to other browsers and computers) a database of salts.