SRP seems to be a very good password authentication protocol, compared to any other things used now. So why is there no popular implementations, or even no working secure implementations?

I tried to set up TLS-SRP protocol, but it haven't worked for me.

Haaalp! Someone?


7 Answers 7


When I learned about SRP we were told it wasn't seeing much deployment due to possibly infringing on EKE patents. Network Computing had this to say in 2002:

Standards groups have made several attempts to induce Lucent to talk about its EKE patent -- to no avail. Even with Lucent's silence on the topic, few vendors have been willing to use SRP. To further cloud the situation, there's been a new patent issued claiming that it too covers SRP.

The SRP website, however claims

Since SRP is specifically designed to work around existing patents in the area, it gives everybody access to strong, unencumbered password authentication technology that can be put to a wide variety of uses.

If I had to guess, I'd say patents were part of the original problem and that effect has continued even today. Whether patents are the sole reason for limited deployment or even the major reason is beyond me.

  • $\begingroup$ TLS-SRP became a RFC standard long ago. There is lack of implementations. Reference from 2002 is probably a little too old. $\endgroup$ Commented May 5, 2013 at 18:02
  • 2
    $\begingroup$ @SmitJohnth RFC 5054's status is "Informational". It is not an IETF standard! $\endgroup$ Commented Oct 27, 2015 at 17:36
  • $\begingroup$ And by the way, TLS-SRP (RFC 5054) leaks the user name, as it is sent in clear text as part of the ClientHello message. $\endgroup$ Commented Oct 27, 2015 at 17:38
  • $\begingroup$ @ErwanLegrand well, there is no other way as to send it in plaintext except you wrap the conversation into a public-key protected channel (and depend on PKI). $\endgroup$ Commented Mar 24, 2017 at 18:04
  • $\begingroup$ @ErwanLegrand To me it makes sense that RFC 5054 is informational, as it describes the application of SRP to TLS. But SRP is an IETF standard: datatracker.ietf.org/doc/html/rfc2945 $\endgroup$ Commented Dec 28, 2023 at 20:55

Issues are that

  1. SRP is only useful with a trusted implementation of it on the side where the password is keyed-in. And when you start bringing that by HTTPS from the server, then two things become weak security links:
    • unwarranted hope that the user won't key-in the password unless the green lock is there at the left of the appropriate domain name;
    • the certificate chain (which can be circumvented in practice: it is not that hard to obtain a rogue certificate from a legitimate CA; and even easier for a rogue CA to pretend having issued a rogue certificate in good faith, should the rogue certificate be noticed, which requires extraordinary attention. If a major CA is caught red-handed mis-issuing 30000 certs including for www.google.com and www.gmail.com, can we trust the certificate chain or is it security theatre?). Update: another example.
  2. SRP implemented in JavaScript is slow (at least on clients lacking a JavaScript with JIT); it is bearable in Java, but support of Java in browsers never became common.
  3. SRP does not protect against a keylogger or other compromise of the client machine or software; worse, once a client machine is compromised by some malware, an hypothetical standardized SRP client interface could arguably become a convenient target for malware gathering login credentials (with the plethora of web interfaces, malware is at plain reliably sieving login credentials from other user input).
  4. SRP on the client machine (by itself) does not provide two-factor authentication. Thus a TFA mandate is not reason enough to justify SRP.
  5. Compared to the practice of sending the password over HTTPS, the benefits of SRP exist only after you hypothesize a compromise of the server or of HTTPS.
  6. Update: SRP as standardized does not protect from leak of server-side data; with that data, it is possible to test the validity of a password, making password search in a dictionary to fear (and technological progress / use of ECC actively working against security). To address the threat of leak of server data (which is part of standard security requirements), SRP would need to be complemented by a purposely slow password-based key derivation function such as PBKDF2, Bcrypt, Scrypt, Argon2, Balloon instead of a fast hash. That, and where the salt and security parameters comes from, is not standardized by RFC5054 or ISO/IEC 11770-4:2006 (did not check the latest version), and does not promote interoperability of the few SRP clients.
  7. Update: how server-side data is established at enrollment is not standardized either AFAIK, and another area where HTTPS might be the weak link.

For all these reasons, SRP in the browser never caught, neither downloaded from the server nor built into the browser. When there is money to spend on security, it goes to two-factor authentication. Otherwise, business decision makers want something now that works everywhere with a smooth user experience, and SRP has no business case.

  • 4
    $\begingroup$ 1)2) You mean javascript implementation of SRP, right? That's a bad solution. There is actually TLS-SRP standart, a pity it's too bad supported. 5) "the benefits of SRP exist only after you hypothesize a compromise of the server or of https." - Is that not enough? $\endgroup$ Commented Mar 24, 2017 at 17:58
  • 1
    $\begingroup$ "AFAIK nobody was fired for not having prescribed SRP" - you just described the fact it's not popular, not the reason for it. 3) don't get. $\endgroup$ Commented Jul 11, 2017 at 17:11
  • 2
    $\begingroup$ "Compared to the practice of sending the password over HTTPS, the benefits of SRP exist only after you hypothesize a compromise of the server or of HTTPS." - it protects from phishing too (it neither reveals the user's password nor can a fake server authenticate against a client) $\endgroup$ Commented Jul 12, 2017 at 20:38
  • 3
    $\begingroup$ Many of your objections are also true for the alternatives. One advantage of SRP that is not mentioned here is that that it protects against accidental server-side exposure of the password through exposure of request logs or other traffic-monitoring features. $\endgroup$ Commented Jan 28, 2020 at 16:43
  • 1
    $\begingroup$ Following a fine former comment by @maxkoryukov that the lack of use of SRP is saddening. I'm answering the question "Why is SRP not widely used?", not "should we use SRP?". My point is that the web started without SRP/PAKE, it's not technically sound to do SRP/PAKE using the existing infrastructure, and the security increment is not appealing enough to decision makers in startup mode, who want wide use of their service ASAP by all platforms, thus nothing happens. Perhaps I should put the last paragraph on top. $\endgroup$
    – fgrieu
    Commented Jul 3, 2020 at 5:14

Perhaps it is not widely used in TLS, but it is actually deployed in Apple iCloud (Page 49 in Apple security whitepaper), 1PassWord (Page 57 in 1PassWord security whitepaper), ProtonMail (In this blog) etc. for authentication purpose.

  • $\begingroup$ I don't know anything you written about. How is it used in ProtonMail? As Js SRP? It's useles. $\endgroup$ Commented Jul 11, 2017 at 22:01
  • $\begingroup$ @SmitJohnth The blog writes very clear. If you want to understand it, you should check it. $\endgroup$
    – 9f241e21
    Commented Jul 11, 2017 at 22:15
  • $\begingroup$ I don't see it, but there is no other way to do it as with js. $\endgroup$ Commented Jul 12, 2017 at 11:28
  • $\begingroup$ @SmitJohnth github.com/mozilla/node-srp $\endgroup$
    – 9f241e21
    Commented Jan 22, 2020 at 6:48

To be useful, it needs to be implemented in browsers, so that the user types in their password in an area that is not accessible to JavaScript, like the URL bar. And nobody had done that.

There is also a huge industry that tries to prevent and deal with phishing. Phishing is by far the greatest source of security problems today. SRP would kill phishing dead, so many will be against it.

  • $\begingroup$ Why can't it be implemented in Javascript? What risks do you see? What does phishing have to do with SRP? $\endgroup$ Commented Dec 28, 2023 at 21:13

While I think this is changing very recently with expiration of additional patents and SRP included with OpenSSL one of the central problems is compatibility with existing authentication databases.

NT OWFs, unix crypts, directory server hashes..etc everything but plaintext passwords (e.g. plaintext reversibly encrypted on disk) are incompatible with SRP. Sure you can have a SRP client perform encryption if you leak salts and match stored hash but this escalates importance of hashes to be equivalent to plaintext passwords. (e.g. "passing the hash")

Personally I'm very excited about SRP we have a few projects planned that will be leveraging TLS-SRP.

  • $\begingroup$ What patents do you mean? TLS-SRP in OpenSSL doesn't work for me (see link in the question) and I can't get help nowhere.<br> Don't even mention windows NT auth, it sucked 15 years ago and now it sucks multiplied growed computing power. $\endgroup$ Commented May 21, 2013 at 21:49
  • $\begingroup$ Well, if you ask about auth databases, then you are probably inside and organisation and could probably acquire one or many ssl certificates or even a CA. SRP would be useful for a lonely server for that it would be expensive or complicated to get a signed SSL certificate. $\endgroup$ Commented May 22, 2013 at 2:44
  • $\begingroup$ @SmitJohnth SRP has the additional advantage (over traditional RSA or DH key exchange with a server's certificate) that the client is automatically authenticated, too, and you don't need an additional step for client authentication. $\endgroup$ Commented May 23, 2013 at 21:43
  • $\begingroup$ @PaŭloEbermann I think your post doesn't belong here :) $\endgroup$ Commented May 24, 2013 at 1:27
  • 1
    $\begingroup$ @SmitJohnth No, my comment was meant as a response to your comment. SRP is not just for the case where "I can't afford a SSL certificate", but offers additional advantages (but only works for the case of a limited user group). $\endgroup$ Commented May 24, 2013 at 19:12

Most likely, the answer is ROI. Implementing SRP costs time and money. What do you get for what you pay? You could as well ask why SCRAM (RFC 7677) is not used, while we're at it. Or why client X.509 certificates are not more widely used.

I believe you need to perform a bit of threat analysis to understand this. (From now on, I am assuming secure network communications provided by TLS.)

Question: In which case do better password protocol provide additional security?

Answer: Better password protocols prevent illegitimate use of the password if the server is not trustworthy.

Question: But, if the server is compromised, why should you worry about keeping your password secret?

Answer: Because the same password is used to access other valuable resources.

But wait... this problem has been solved by password managers since the late 1990's (Schneier - PasswordSafe) or perhaps even earlier!

Now, let's look at another threat: let's assume the client system is compromised.

Question: Does SRP mitigate this threat?

Answer: It does not.

Question: Are solutions which provide mitigation against this threat widely used at this time?

Answer: Yes. (Google Authenticator, Blizzard Authenticator, SMS verification codes - provided the smartphone is not the device used to access the valuable resources - hardware tokens...)

Thus, I'm afraid the answer is there is little incentive to implement better password protocols.

EDIT: I was about to forget this! Dumb password protocols do not leak the user name (still assuming ordinary TLS) while TLS-SRP does. Thus, to sum up the answer: no existing threat mitigated by switching to TLS-SRP and another threat is no longer mitigated.

  • $\begingroup$ Traditional password schemes authenticate a client to a server. SRP authenticates in both directions, and is resistant to MitM and active network attacks. Consider a scenario where after SRP authentication, the server sends the client an encrypted payload, which is decrypted with a key derived from the client's password. Then this information is protected even if the server is compromised. This is not true for any other non-PAKE scheme. $\endgroup$ Commented Dec 28, 2023 at 21:25

Some years later, the question might no longer be valid, as there are some implementations now.

Here's one for PHP+JS that is supposed to be illustrative as well as functional. I cannot attest as to whether it is any good, but considering it implements a recent version of the protocol (SRP-6a) I'd say it is worth a look.

Here's another, also for PHP, and also fairly recent.

  • 2
    $\begingroup$ Not useful unless in the browser. Must not be implemented in JavaScript. The point is to not trust a malicious site. $\endgroup$
    – Tuntable
    Commented Nov 17, 2017 at 5:24
  • 1
    $\begingroup$ AWS Cognito supports and encourages SRP, and provides implementations in Javascript (both NodeJs and browser-side) , and modules for .Net Core and Python are also available. $\endgroup$ Commented Jan 28, 2020 at 16:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.