# Why is SRP not widely used?

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?

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.

• TLS-SRP became a RFC standard long ago. There is lack of implementations. Reference from 2002 is probably a little too old. – Smit Johnth May 5 '13 at 18:02
• @SmitJohnth RFC 5054's status is "Informational". It is not an IETF standard! – Erwan Legrand Oct 27 '15 at 17:36
• 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. – Erwan Legrand Oct 27 '15 at 17:38
• @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). – Smit Johnth Mar 24 '17 at 18:04

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 does not provide two-factor authentication.
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.

• 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? – Smit Johnth Mar 24 '17 at 17:58
• @Smit Johnth: 1)2) Yes, and indeed javascript implementation of SRP is a poor solution. Yes TLS-SRP is nice, but not used in practice; perhaps partly because, as explained in 3), it's API would becomes a SPoF. 5) yes, but AFAIK nobody was fired for not having prescribed SRP, when people could be fired for not relying on HTTPS on the true ground that it is unsafe, when overwhelmingly most of the web has nothing better than HTTPS and a passable password manager, and anything else will reduce the potential user base. – fgrieu Mar 24 '17 at 18:14
• "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. – Smit Johnth Jul 11 '17 at 17:11
• "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) – Smit Johnth Jul 12 '17 at 20:38
• 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. – Elroy Flynn Jan 28 at 16:43

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.

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

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.

• 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. – Smit Johnth May 21 '13 at 21:49
• 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. – Smit Johnth May 22 '13 at 2:44
• @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. – Paŭlo Ebermann May 23 '13 at 21:43
• @PaŭloEbermann I think your post doesn't belong here :) – Smit Johnth May 24 '13 at 1:27
• @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). – Paŭlo Ebermann May 24 '13 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.

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.

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.

• Not useful unless in the browser. Must not be implemented in JavaScript. The point is to not trust a malicious site. – Tuntable Nov 17 '17 at 5:24
• 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. – Elroy Flynn Jan 28 at 16:33