plus/minus epsilon

• Purpose: To present a more efficient authentication scheme, geared towards web applications served over TLS or another secure channel.
• Audience: Web application designers interested in security.
• Implementation: Bren2010/sjcl-ssrp

Motivation

Often web app designers, in an effort to improve their site's security, will look to the Secure Remote Password (SRP) protocol. However, if their application is already served over a secure channel, then there's no point in using a complex and expensive protocol like SRP, which was originally designed as a way to build secure channels! This point is especially poignant given that most web apps that use SRP do the key exchange as authentication and then never reference its output. It's as absurd as doing any other flavor of key exchange and then proceeding to communicate over plaintext.

A tangent point is that, while there has been some effort to convert SRP to elliptic curves--making it viable for widespread use as authentication--there hasn't been much luck when considering elliptic curves as only a vector space. Researchers instead move to twists and pairings which scare implementors away even faster than the benchmarks on arithmetic in a 4,000-bit field.

The Protocol

Similar to the original SRP paper, the user generates a random salt s and applies a key derivation function to their password, salted with s, to generate x. The user sends (s, X = xG) to the server. (Side note: A coin-flipping protocol can be used to generate s to reduce the possibility of statistical biases in either party's DRBG.)

On authentication, the user supplies the server with their username. The server returns (s, A = aG), where a is known only to the server. The user re-calculates their key x and returns S = xA. The sever accepts if S equals aX.

The entire protocol needs to take place over a secure channel--meaning, messages sent on the channel should be authenticated (resistant to forgery) and the server should be identified (through another identification or signature/PKI scheme resistant to replays).

The above definition doesn't discuss confidentiality, even though X and S must remain confidential even if the provided channel isn't. In such a case, ElGamal or another form of encryption should be used.

Assumptions

1. The computational Diffie-Hellman assumption for elliptic curves.
2. The hardness of the discrete logarithm problem for elliptic curves.
3. The server is not actively malicious, but may be monitored or suffer data breaches.
4. The server's random number generator is cryptographically secure.
5. The server has correct implementations of elliptic curve arithmetic.

Security

The computational Diffie-Hellman assumption for elliptic curves is, in this case, the basis for the correctness of the system because it's assumed that only a user who knows x (the password) is capable of producing xA in a reasonable amount of time.

Because the validator X and the proof S are explicitly confidential, an adversary learns nothing about x or the corresponding password during a successful run. Also, if the validator or a proof are leaked (perhaps because of a database breach), an adversary still can't successfully authenticate as the user because they don't know the discrete logarithm of the validator. The adversary has to first calculate the logarithm by brute force discovery of the user's password (this being the main selling-point over challenge-response authentication protocols based on hashes or something similar).

Because we've assumed a secure channel (like TLS), server impersonation and session key compromise are no longer concerns. There's no value in considering server impersonation given that the server will often be the one providing the cryptographic code.

The proposed protocol is as-secure-as-possible given the threat model and it relies only on having a specific kind of secure channel.

Violating Assumptions

Violating assumption #3 was already well handled in the Security sub-section.

If assumption #4 is violated, there may be value in checking that the validator supplied by the user is on the curve and a multiple of G. A validator of low order can leak bits of the server's random number generator. An adversary who knows the state of the server's RNG can generate the ephemeral private key a and provide aX to successfully authenticate without violating the CDH assumption or solving the DLP.

If assumption #5 is violated, there's potential to build kleptographic channels which subliminally leak almost anything about the sever.

Conclusion

Given the threat model inherent in a web application, it's possible to build a much more efficient authentication protocol with all of the strong password-related security properties that makes SRP so attractive to the web.

Addendum

1. Applications can protect their users against phishing scams and partially against server compromise by promoting PwdHash or password managers that support password generation and auto-fill (so it "acts up" on unfamiliar domains) instead of writing their own browser extension to defend against server impersonation.