3

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.

3

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.

  • I'm only interested in online registration. Also, in my scenario I'm looking at enrollment through an application (not a browser). There is no confidential information being exchanged. I'm only interested in preventing impersonation, not encryption. Does this change anything? – BahKoo Jan 31 '14 at 16:48
  • @BahKoo - this is an application that you develop, and your users download and run on their systems? Your server could use a self-signed certificate, that is also embedded in the application. That would let you do SSL from app to server, securely, and without a CA. It doesn't solve how the users download the application in the first place. – paj28 Jan 31 '14 at 17:10
  • Yes. It's an app I develop and users download. Self-signed certificates look like they might work for me. What is the problem with users downloading the application? If the download was available to everyone would there be a problem? – BahKoo Jan 31 '14 at 17:13
  • @BahKoo - not a problem for you, but how do your users know to trust what they download? – paj28 Jan 31 '14 at 20:02
  • How do browsers handle this? Browsers can be downloaded freely without a secure connection. – BahKoo Jan 31 '14 at 20:40
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...).

  • Hi, you are mentioning of a "generic SRP implementation". What if I write a Javascript library that implements SRP using some Crypto JS library? Why should the SRP implementation be lower in the stack? Thanks! – Evan P Nov 27 '14 at 17:00
  • 1
    SRP makes sense when you want to establish a secure tunnel with authentication. Javascript is downloaded; if you can safely run some Javascript code that asks for your password, then this means that you are already connected to the right server, at which point there is no reason to use SRP. – Thomas Pornin Nov 27 '14 at 17:39
  • Why not, securely download Static content over TLS, and implement SRP in a higher level (Javascript) for the information that is exchanged regarding user authentication? – Evan P Nov 28 '14 at 9:30
  • i strongly disagree with the idea "if you use secure tunnel to the right server there is no need for SRP". Heartbleed, app errors printing passwords to logs, decrypting corperate webproxies scanning for user bad behaviour, decryption at the service load balances, are all risks. A breach to a locked down machine running intrusion detection will first snoop passively before installing a root kit which could hit a tripwire. Sending the password off the client machine is a bad idea, period. SRP as a password-proof over TSL is better than sending a password over TSL. SRP & TSL are complimentary. – simbo1905 Jan 9 '15 at 20:06
1

Or:

  1. client registers verifier using TSL using a self signed cert.
  2. 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.

  • Bonus points for SRP as complementary. I think there are some interesting non-web use-cases where it might be ideal as a stand-alone security mechanism... – JCx Jan 11 '15 at 16:20
1

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.

  • What does your suggestion provide that TLS doesn't? – user49075 Apr 18 '15 at 10:08
  • Means you only need to have an SRP implementation, not TLS (and all of the consequent code required by that). – Steve Peltz Apr 18 '15 at 10:14
  • Hmm, that's cute. +1 – user49075 Apr 18 '15 at 10:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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