How do clients enroll using SRP?

Question

From what I understand, one of the benefits or Secure Remote Password (SRP) is that is does not require reliance on certificate authorities. In a scenario where clients need the ability to register as a new user how does this work? I can only imagine 3 scenarios none of which seem to be great:

1) Client sends password to server on enrollment so that the server can calculate the verifier for future authentication. Password is vulnerable over the wire.

2) Client calculates verifier locally and sends verifier over the network. Verifier is vulnerable over the wire and could be subjected to a dictionary attack.

3) Client enrolls using SSL and a Certificate Authority. This eliminates the benefit of not requiring a CA.

Answer 1

None of those options are great, although (1) is the worst. The bottom line is that SRP is a fantastic idea, but it's difficult to see how to deploy it. Especially as browser support is patchy - beta quality plugins for a handful of browsers.

If you want to make a practical working site now, use (3).

You could, in theory, use (2) over SSL with anonymous Diffie-Hellman so there's no CA. In that case, on your first exchange, you don't know who you're talking to. But in the future you at least are sure that it's the same site. So perhaps you sign up at first with no trust in the site, build up trust over time, and have the confidence that an attacker couldn't then impersonate the site you now trust.

It does raise some broader issues of trust and how you transact online. A lot of consumers like the model of "I know Amazon are trustworthly, I want to use them" and the existing CA model matches that quite well. If you're more into peer-to-peer, non-hierarchical arrangements, then how do you establish trust online?

Your question only covers online registration - if you have another arrangement, such as in-person registration, you may have better options.

Answer 2

First, since browsers don't support SRP, we are necessarily talking about a custom local application.

For security, it is important that the local application code is "safe". We have to assume that the user did not initially have the application, then obtained it and installed it on his computer. This must occur before the SRP enrollment. And yet users must have a way to make sure that the application code they install is the genuine, non-hostile one. Maybe they got it from a CDROM/DVD; maybe they downloaded it through a "secure channel"; maybe the binary is signed. The attacker would like to insert his own code in that application, so there MUST be some mechanism to defeat the attacker at that point.

Assuming that the application code is safe, then that application code may embed a copy of a public key owned by your server; e.g. a copy of the server's certificate. That certificate may be self-signed, or issued by a custom CA, or whatever: since the application knows a priori the server's public key, it can establish a secure tunnel with the server through SSL, and without involving an external CA: the application just checks that the certificate used by the server is bit-to-bit identical to the embedded one. At that point, you can transmit any user-chosen password without fear of hostile eavesdropping. Arguably, you could also keep on using that SSL and not do any SRP at all.

The "embedded public key" model is simple and will work -- that is, if it does not work, then this means that you have a bigger security issue that you cannot solve with any amount of SRP.

As a side note, this example shows that SRP, though a massively spiffy algorithm, is not necessarily useful in contexts where custom, server-specific application code is installed on the client side. The real goodness of SRP occurs when the client code is generic, e.g. is a Web browser which does not include any site-specific code. But we are not there yet; browsers don't know how to do SRP (for the time being...).

Answer 3

Or:

4. client registers verifier using TSL using a self signed cert.
5. client registers verifier encrypted with a servers vanilla RSA public key.

A related question talks about these options at https://security.stackexchange.com/a/78749/45960

In the context of SRP as a password proof to a website you ideally want to use a CA signed cert and HTTPS to ensure the user is registering with the correct server. You can also use HTTPS at login to protect the user identity. Then you have defence in depth. If you don't want to go with a CA signed cert then a self signed one can prevent interception of the verifier and the username but the user is more at risk of registering with a fake site. There are many reasons not to rely on just TSL and to see SRP as complimentary to to use both (eg Heartbleed) but that's a bit off-topic to the question. The bottom line being that if the password doesn't have to be copied into the memory of the server it really should not be.

The feature that "you don't need an external authority" is an angle that SRP as an extension to TSL in RFC 5054 has taken which AFAIK isn't being widely adopted. That may be because sysadmins and devops are very comfortable with TSL/HTTPS and certs and are very uncomfortable with trying something new. The bottom line is that SRP for TSL replaces the "got to get a signed cert" with "got to securely distribute the verifiers" and that implies PKI so why not just use standard CA signed certs with TLS and be on a well trod and well documented setup? The cost of a signed cert used to be a barrier but I have purchased official ones for banks at extortionate costs but also bought personal ones for as little as $25 from fairly dubious CAs. So really the "don't need a CA" angle for SRP is perhaps not as highly compelling driver for its adoption today as it may have seemed at its invention. It also creates an "either/or" frame of mind and people should be defaulting to use both; use CA TSL to prevent interception and to help against phishing and SRP as the password proof to avoid leaking the password on the server and to defend against snooping corporate web proxies.

Answer 4

Create a private key with corresponding verifier for server. Rather than use a hash of a salt and password as in typical SRP, just use a random number (mod N) and not zero for the key value. In SRP implementations, the key is typically called "x", and then the verifier is g^x (mod N).

SRP with a key of 0 is simply Diffie-Hellman.

Now do an SRP login with the roles reversed: client plays server, server plays client, server "logs in" to client using the server's private key, client authenticates server with server's public verifier.

Use the agreed-upon key (established by the SRP protocol) to encrypt the session where the client sends the client's new verifier (NOT the password) to the server. Typically, the server will send the correct values of N and g (which can be different from the N and g used to establish the server's identity) plus a random salt, then the client uses a hash of the salt and the password as the new key.

Note that the server verifier can be a public value, so can be embedded in your code on the client side without obfuscation. Since it's created using a large random number and not a password, there is no dictionary attack possible, so it's safe to be public. The private key, of course, needs to be kept secure on the server, as anyone with that key can masquerade as that server.