5 ms·

This is literally untrue. Zero-knowledge comparison protocols exist [1], and their goal is to prevent malicious party from obtaining any knowledge of the secret

by ilammy 6y ago

This is literally untrue. Zero-knowledge comparison protocols exist [1], and their goal is to prevent malicious party from obtaining any knowledge of the secret. Yes, the genuine server will have its copy of the password (or its hash, whatever) and the user will have their copy of the password too. What you don't want is to have the user send their copy of the password to a place which looks like your server but isn't. [1]: https://www.cossacklabs.com/files/secure-comparator-paper-rev12.pdf https://www.cossacklabs.com/files/secure-comparator-paper-re... EDIT: I mean, yeah, you're right in the sense that whatever you send to the server is used to authenticate you, so that whatever is a 'password' of a sort by definition. However, using the raw password as is for authentication is not a great idea. If you intercept the password, you will be able to compromise any further authentications. There are alternatives that avoid this.

DarthGhandi 6y ago
Another alternative is a PAKE. You'll never have a password sent over the wire. For some reason PAKE schemes aren't that commonly used despite having a solid grounding. Matthew Green has a few good articles on them.
- thaumasiotes 6y ago
  > You'll never have a password sent over the wire. As far as I can see, you do need to send the full password over the wire once when you set its value. But the server doesn't need to remember it. > For some reason PAKE schemes aren't that commonly used despite having a solid grounding. It doesn't look like something you can implement unilaterally. How's browser support? (Interestingly, I guess you could implement it unilaterally between your server and client-side javascript...)
  - DarthGhandi 6y ago
    I'm not sure if this is coming down to semantics here but the password is essentially encrypted to everyone except the client, I wouldn't call that sending a password over the wire, you may disagree. This is a unique value for every login attempt. Probably the most common scheme is SRP. https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco...
    - deleted 6y ago
      [deleted]
    - thaumasiotes 6y ago
      No, you're right; I wasn't talking about login attempts. I was thinking that PAKE is a way to establish that two parties have common knowledge of a shared secret, and so the password needs to be shared once in order to become a shared secret. But the protocol you link doesn't transfer the password even when setting it. (Weirdly, the article explicitly notes that s, the salt Carol applies to her own password, is shared with the server and sent over the wire during login. But the salt never appears to be used by the server in any capacity. And the instruction "Carol must not share x with anybody, and must safely erase it at this step, because it is equivalent to the plaintext password p" doesn't make a lot of sense; presumably Carol isn't going to erase her knowledge of her password -- what does erasing x add? [The only thing making the password equivalent to x is that the server transmits the value s during the login attempt. If it didn't do that, x would still be useful, but the "password" would be worthless, unless of course s was stored alongside the password...])

by ilammy 6y ago

DarthGhandi 6y ago

Another alternative is a PAKE. You'll never have a password sent over the wire. For some reason PAKE schemes aren't that commonly used despite having a solid grounding. Matthew Green has a few good articles on them.

thaumasiotes 6y ago
> You'll never have a password sent over the wire. As far as I can see, you do need to send the full password over the wire once when you set its value. But the server doesn't need to remember it. > For some reason PAKE schemes aren't that commonly used despite having a solid grounding. It doesn't look like something you can implement unilaterally. How's browser support? (Interestingly, I guess you could implement it unilaterally between your server and client-side javascript...)
- DarthGhandi 6y ago
  I'm not sure if this is coming down to semantics here but the password is essentially encrypted to everyone except the client, I wouldn't call that sending a password over the wire, you may disagree. This is a unique value for every login attempt. Probably the most common scheme is SRP. https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco...
  - deleted 6y ago
    [deleted]
  - thaumasiotes 6y ago
    No, you're right; I wasn't talking about login attempts. I was thinking that PAKE is a way to establish that two parties have common knowledge of a shared secret, and so the password needs to be shared once in order to become a shared secret. But the protocol you link doesn't transfer the password even when setting it. (Weirdly, the article explicitly notes that s, the salt Carol applies to her own password, is shared with the server and sent over the wire during login. But the salt never appears to be used by the server in any capacity. And the instruction "Carol must not share x with anybody, and must safely erase it at this step, because it is equivalent to the plaintext password p" doesn't make a lot of sense; presumably Carol isn't going to erase her knowledge of her password -- what does erasing x add? [The only thing making the password equivalent to x is that the server transmits the value s during the login attempt. If it didn't do that, x would still be useful, but the "password" would be worthless, unless of course s was stored alongside the password...])