5 ms·

In a real world implementation this can be easily avoided by breaking the retrieval query into a challenge-response like: retrieve_salt(username) retrieve_

In a real world implementation this can be easily avoided by breaking the retrieval query into a challenge-response like: retrieve_salt(username) retrieve_keyfile(username, encrypt(streched_password, salt, server_name)) So the offline, parallel crack turns into an online, serial and rate-limited bruteforce. The salt and password derived shared secret are established at account setup time and after any password change, which the browser must support too. This still has some imperfections related to replay susceptibility, but my point isn't to design a protocol, rather the principle of a thing that could make social login obsolete and stone-age.

Ajedi32 8y ago
So now the server needs to store a copy of your stretched master password? How is it supposed to know whether the value of `encrypt(streched_password, salt, server_name)` is correct? Why not just use public key authentication, like the Web Authentication standard already does?
- cornholio 8y ago
  >How is it supposed to know whether the value of `encrypt(streched_password, salt, server_name)` is correct? By comparing it to the static value stored at account setup time. The server trusts your shared secret just like it trusts your public key - establishing the identity of a public key is a different problem with various solutions, CAs, WoT, directory servers etc. The idea here is to move from plain authentication (user/password) to a public key system without carrying the key material around, but deriving it when needed from your password.
  - Ajedi32 8y ago
    So the server stores a copy of your encrypted keyfile, salt, and the result of `encrypt(streched_password, salt, server_name)`? That's better, but still allows malicious sites (or anyone who compromises the database of a site you have an account on) to brute force your master password offline. Slightly better than reusing passwords since there's no danger of sites using a weak hash algorithm or storing your password in plaintext, but still not great. IMO if you _really_ don't want to carry the key material around (which _does_ necessarily reduce security btw, as you're going from "something you have" + "something you know" to just "something you know", which is easier to steal and inherently susceptible to brute force), then it'd be much simpler to just derive a private key from `(user password, site id)` and use that with WebAuthn.

Ajedi32 8y ago

So now the server needs to store a copy of your stretched master password? How is it supposed to know whether the value of `encrypt(streched_password, salt, server_name)` is correct? Why not just use public key authentication, like the Web Authentication standard already does?

cornholio 8y ago
>How is it supposed to know whether the value of `encrypt(streched_password, salt, server_name)` is correct? By comparing it to the static value stored at account setup time. The server trusts your shared secret just like it trusts your public key - establishing the identity of a public key is a different problem with various solutions, CAs, WoT, directory servers etc. The idea here is to move from plain authentication (user/password) to a public key system without carrying the key material around, but deriving it when needed from your password.
- Ajedi32 8y ago
  So the server stores a copy of your encrypted keyfile, salt, and the result of `encrypt(streched_password, salt, server_name)`? That's better, but still allows malicious sites (or anyone who compromises the database of a site you have an account on) to brute force your master password offline. Slightly better than reusing passwords since there's no danger of sites using a weak hash algorithm or storing your password in plaintext, but still not great. IMO if you _really_ don't want to carry the key material around (which _does_ necessarily reduce security btw, as you're going from "something you have" + "something you know" to just "something you know", which is easier to steal and inherently susceptible to brute force), then it'd be much simpler to just derive a private key from `(user password, site id)` and use that with WebAuthn.