A Small SRP Protocol for Web Applications30 Nov 2014
- 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
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.
Similar to the original SRP paper, the user generates a random salt
applies a key derivation function to their password, salted with
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
(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
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
must remain confidential even if the provided channel isn't. In such a case,
ElGamal or another form of encryption should be used.
- The computational Diffie-Hellman assumption for elliptic curves.
- The hardness of the discrete logarithm problem for elliptic curves.
- The server is not actively malicious, but may be monitored or suffer data breaches.
- The server's random number generator is cryptographically secure.
- The server has correct implementations of elliptic curve arithmetic.
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.
#3 was already well handled in the Security sub-section.
#4 is violated, there may be value in checking that the
validator supplied by the user is on the curve and a multiple of
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
a and provide
aX to successfully authenticate without violating
the CDH assumption or solving the DLP.
#5 is violated, there's potential to build kleptographic
channels which subliminally leak almost anything about the sever.
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.
- 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.