Secure Application-Level Remote Password Protocol

Question

I am writing a Java EE application that allows new users to register and then register on the Internet. I store a db credentials.

Now there are several ways to do this, for example:

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

Reading some articles, it seems that a secure remote password access protocol (SRP) is the way to go.

But then, after reading some other articles, it seems that it is used only at some low-level levels, for example. such as TLS / SSL itself.

I still think it's recommended to use the secure remote password protocol at the application level.

It is right? Or are there some good reasons why this is not required at the application level?

Answer 1

There are several tradeoffs to consider. Firstly, sending raw passwords via an SSL link is quite safe if and only if the client correctly verifies the server’s SSL certificate. However, even with the correct validation of the SSL certificate, sending the raw password to the server is not completely ideal. A hacked server can set a user password. Because passwords are often reused elsewhere, this type of exposure can have serious consequences.

The advantage of SRP is that it avoids both of these problems. The user password never leaves your computer, and proper SSL certificate verification is not required. SRP mutual authentication properties make SSL certificates redundant. In fact, some applications use this to completely avoid the headaches associated with properly managing SSL certificates. They simply use anonymous self-signed certificates on the servers for data encryption purposes only and leave authentication to the application level at the application level.

In particular, to your question, I think that the applicability of SRP to low-level use at the application level really depends on your application. It can function well in both arenas, but where it works best it really comes down to a certain set of design limitations that you work with.

Answer 2

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

If your users register or reset their SRP password authentication over the network, you need to encrypt the connection; since the verifier must be kept secret so that it is not exposed to an offline brute force attack. TLS / SSL / HTTPS are perfect for this. They are well installed, encrypt all data and provide protection for server certificates, which try to ensure that the browser does not talk to the spoofing server.

SRP means that the password that the user authenticates does not cross the network. If your users use a computer supplied by the company through a web proxy, then HTTPS can decrypt and track . The Hearbleed error also indicates that well-configured HTTPS can have problems. Notebook makers have deliberately compromised HTTPS on laptops that they sell with Superfish so that they can place ads on encrypted pages. Root certificates can be compromised as deployed by the French government to track employees. Even with perfect encryption settings, an application may accidentally skip passwords in logs; whereas SRP does a one-time password proof using randomized inputs. Thus, SRP protects the password from exiting the client machine, which is inherently more secure than having its memory (from where it can be leaked) on two machines.

As a result, people should use both SRP and HTTPS / TLS / SSL.