3 ms·

Another interesting method, overkill for most applications but absolutely required for end-to-end encrypted apps where no password must be sent to the server (e

Another interesting method, overkill for most applications but absolutely required for end-to-end encrypted apps where no password must be sent to the server (eg: password managers): the Secure Remote Password (SRP) protocol[1]. It's a form of zero-knowledge proof-based verification that the password provided during account creation matches the one provided during an authentication challenge, all without transmitting the password at all. As a bonus, it also act as a key exchange on the client and server, that can be used for securing transmissions over untrusted channels (at the cost of having stateful connections). [1] https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco...

throw0101a 6y ago
SRP was good for its time, but things have moved forward in the password-authenticated key exchange (PAKE) world. See for example OPAQUE: > Currently, the most widely deployed (PKI-free) aPAKE is SRP [RFC2945], which is vulnerable to pre-computation attacks, lacks a proof of security, and is less efficient relative to OPAQUE. Moreover, SRP requires a ring as it mixes addition and multiplication operations, and thus does not work over plain elliptic curves. OPAQUE is therefore a suitable replacement for applications that use SRP. > This draft complies with the requirements for PAKE protocols set forth in [RFC8125]. * https://tools.ietf.org/html/draft-irtf-cfrg-opaque https://tools.ietf.org/html/draft-irtf-cfrg-opaque More on PAKE generally: * https://blog.cryptographyengineering.com/2018/10/19/lets-talk-about-pake/ https://blog.cryptographyengineering.com/2018/10/19/lets-tal... * https://news.ycombinator.com/item?id=18259393 https://news.ycombinator.com/item?id=18259393 If you're looking for a challenge-response system for your application, then it's hard to go wrong with SCRAM (which Postgres went with a while ago): * https://en.wikipedia.org/wiki/Salted_Challenge_Response_Authentication_Mechanism https://en.wikipedia.org/wiki/Salted_Challenge_Response_Auth...
- anirudhan 6y ago
  I have been checking out OPAQUE for sometime. But I couldn't find any reliable javascript implementation that I can use in my webapp. Do you know of any such implementations.
  - dchest 6y ago
    There's no need to use PAKE in a web app.
  - tialaramex 6y ago
    There are two scenarios in your "webapp". In both scenarios your connection a client should be secured with TLS (HTTPS) 1. Humans, should be authenticated with WebAuthn. This means now they can't get phished (a major threat today), their credentials can't be stolen (even from you, you only have a worthless public key and an arbitrary identifier), their privacy is protected as best possible, and most likely their platform is also looking out for them (e.g. on an iPhone the fingerprint sensor so their kid sister can't even authenticate to your webapp from their phone) 2. Machines should be authenticated with either public key encryption (mutually authenticated TLS) if you're up to it or random revokable tokens issued by your service for that purpose to a human end user. PAKEs are most valuable when you do not have a secure connection, but a webapp should have a secure connection over HTTPS already.
dchest 6y ago
It's not absolutely required for end-to-end encrypted apps (that encrypt data with password or use it for authentication). The two benefits of SRP-like (aPAKE) protocols are: - a password hash (verifier in SRP) is not transmitted during authentication. (But is transmitted during registration and stored on the server). This isn't really required if the secure channel is already established — e.g. TLS — you can as well just send the password hash via TLS, which the server will hash again and check against the stored hash. For registration you already need some kind of non-password based secure protocol to transfer the verifier anyway. - mutual authentication (that is, client also learns if the server knows the password/verifier). For this case, an app would already come with some kind of mechanism to ensure that the server it talks to is authentic (e.g. TLS with pinned certificates or some other public key protocol with hard-coded keys). So the benefit of verifying that this authentic server is the one that stored your verifier is also limited. To summarize, there's not much use for SRP in a typical e2e app, since it already needs a secure connection between a client and the server, and SRP verifier is a client-side password hash. SRP is useful if you need to establish a secure connection with a password and nothing else, but it requires first to store the verifier on the server somehow.

throw0101a 6y ago

SRP was good for its time, but things have moved forward in the password-authenticated key exchange (PAKE) world. See for example OPAQUE: > Currently, the most widely deployed (PKI-free) aPAKE is SRP [RFC2945], which is vulnerable to pre-computation attacks, lacks a proof of security, and is less efficient relative to OPAQUE. Moreover, SRP requires a ring as it mixes addition and multiplication operations, and thus does not work over plain elliptic curves. OPAQUE is therefore a suitable replacement for applications that use SRP. > This draft complies with the requirements for PAKE protocols set forth in [RFC8125]. * https://tools.ietf.org/html/draft-irtf-cfrg-opaque https://tools.ietf.org/html/draft-irtf-cfrg-opaque More on PAKE generally: * https://blog.cryptographyengineering.com/2018/10/19/lets-talk-about-pake/ https://blog.cryptographyengineering.com/2018/10/19/lets-tal... * https://news.ycombinator.com/item?id=18259393 https://news.ycombinator.com/item?id=18259393 If you're looking for a challenge-response system for your application, then it's hard to go wrong with SCRAM (which Postgres went with a while ago): * https://en.wikipedia.org/wiki/Salted_Challenge_Response_Authentication_Mechanism https://en.wikipedia.org/wiki/Salted_Challenge_Response_Auth...

anirudhan 6y ago
I have been checking out OPAQUE for sometime. But I couldn't find any reliable javascript implementation that I can use in my webapp. Do you know of any such implementations.
- dchest 6y ago
  There's no need to use PAKE in a web app.
- tialaramex 6y ago
  There are two scenarios in your "webapp". In both scenarios your connection a client should be secured with TLS (HTTPS) 1. Humans, should be authenticated with WebAuthn. This means now they can't get phished (a major threat today), their credentials can't be stolen (even from you, you only have a worthless public key and an arbitrary identifier), their privacy is protected as best possible, and most likely their platform is also looking out for them (e.g. on an iPhone the fingerprint sensor so their kid sister can't even authenticate to your webapp from their phone) 2. Machines should be authenticated with either public key encryption (mutually authenticated TLS) if you're up to it or random revokable tokens issued by your service for that purpose to a human end user. PAKEs are most valuable when you do not have a secure connection, but a webapp should have a secure connection over HTTPS already.

dchest 6y ago

It's not absolutely required for end-to-end encrypted apps (that encrypt data with password or use it for authentication). The two benefits of SRP-like (aPAKE) protocols are: - a password hash (verifier in SRP) is not transmitted during authentication. (But is transmitted during registration and stored on the server). This isn't really required if the secure channel is already established — e.g. TLS — you can as well just send the password hash via TLS, which the server will hash again and check against the stored hash. For registration you already need some kind of non-password based secure protocol to transfer the verifier anyway. - mutual authentication (that is, client also learns if the server knows the password/verifier). For this case, an app would already come with some kind of mechanism to ensure that the server it talks to is authentic (e.g. TLS with pinned certificates or some other public key protocol with hard-coded keys). So the benefit of verifying that this authentic server is the one that stored your verifier is also limited. To summarize, there's not much use for SRP in a typical e2e app, since it already needs a secure connection between a client and the server, and SRP verifier is a client-side password hash. SRP is useful if you need to establish a secure connection with a password and nothing else, but it requires first to store the verifier on the server somehow.