Why is SRP not widely used?

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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.