Secure Remote Password protocol on application level

Question

I'm writing a Java EE application, which allows new users to register themselves and then log in over the Internet. I'm storing the credentials an a db.

Now, there are several ways to do that, e.g.:

• send username and password, preferably over a TLS/SSL connection
• send username and a hashcode of the password, preferably over a TLS/SSL connection
• use the Secure Remote Password protocol (preferably over a TLS/SSL connection ?)

Reading some articles, it seems the Secure Remote Password Protocol (SRP) is the way to go.

But then reading some other articles it seems as this is only used on some low-level layers, e.g. such as TLS/SSL itself.

I still think, it's recommended to use the Secure Remote Password Protocol on application level.

Is this correct? Or are there some good reasons why this is not needed on application level?

Answer 1

There are a few tradeoffs to consider. First, sending raw passwords over an SSL link is reasonably secure if, and only if, the client is properly validating the server's SSL certificate. However, even when proper SSL certificate validation is preformed, sending the raw password to the server is not completely ideal. A hacked server could expose the user's password. As passwords are frequently re-used in other places, this kind of exposure has potentially serious implications.

An advantage to SRP is that it avoids both of these issues. The users's password never leaves their machine and proper SSL certificate validation is not necessary. The mutual-authentication properties of SRP renders SSL certificates redundant. In fact, some applications take advantage of this to completely avoid the headaches associated with proper SSL certificate management. They just use anonymous, self-signed certificates on the servers for data encryption purposes only and leave the authentication up to application-level SRP.

Specifically to your question, I think applicability of SRP to low-level vs application-level use really depends on your application. It can function well in both arenas but where it's best employed really boils down to the particular set of design constraints you're working with.

Answer 2

People should use SRP over TLS/SSL as they are complimentary.

If your users register or reset their SRP password verifier over the network then you need to encrypted the connection; as the verifier should to be kept secret so that it is not subjected to an offline brute force attack. TLS/SSL/HTTPS are perfect for this. They are well established, encrypt all data, and gives the protection of server certificates which try to ensure that the browser does not talk to a spoofing server.

SRP means that the password your users authenticate with does not cross the network. If your users use a company supplied computer going via a corporate web proxy then HTTPS may be decrypted and monitored. The Hearbleed bug also shows that well configured HTTPS can have problems. Laptop manufacturers have deliberately compromised HTTPS on the laptops they sell with Superfish so they can inject ads into encrypted pages. There could be compromised root certificates as deployed by the French government to snoop on employees. Even with a perfect encryption setup an application may leak passwords into logs by accident; whereas SRP does a one-time password proof using randomised inputs. So SRP protects the password from leaving the client machine which is inherently more secure than having it come into memory (from where it can be leaked) on two machines.

The upshot is that people should use both SRP and HTTPS/TLS/SSL.