User passwords should never leave the browser

The OpenSSL Hearbeat incident taught us an important lesson – user passwords should never leave the confines of the browser and be sent across the network.

But how can that be achieved?

Enter the Secure Remote Password

A solution that is not widely known has existed for over a decade and it’s called Secure Remote Password or SRP for short. SRP is an ingenious cryptographic protocol for user authentication based on the principle of zero knowledge password proof.

How does SRP work?

The common approach when a user signs up is to ask her for a name and password, which then get saved on the server. Servers may save the password in plain text, which is bad in case the server gets compromised and the credentials get stolen. People tend to reuse passwords a lot, which means that once a user password gets compromised, the attacker has a chance of more than 50% to gain access to other services and web sites where the person is subscribed.

To mitigate against this servers employ a technique of storing the password in hashed form, typically mixed with a salt and passed one or more times (the more the better for security) through a SHA1 or PBKDF2 algorithm so that in case the server gets compromised, reconstructing the password through brute force dictionary attacks becomes impractical (or at least buy enough time to notify users of the breach and let them change the passwords).

Unfortunately, storing the password in hashed form on the server side doesn’t prevent password leaks when the Transport Level Security (or TLS / SSL) fails, as was the case with the Heartbeat incident. To eliminate this particular risk we must ensure that the user’s password is never transmitted across the network. The Secure Remote Password protocol does just that.

When a user registers with an SRP-enabled website, the password gets entered in the browser and a piece of JavaScript computes the so-called verifier from it – a very long cryptographic number which can be used to check the password, but is not the password itself; the actual password is discarded by the JavaScript once the verifier is computed. This verifier then gets sent over the network to the server to create the user’s account.

When the user logs in the the SRP-enable website, the input password is again processed by a piece of JavaScript to produce a cryptographic number, which is passed over the network to the server, and which the verifier (installed previously during registration) can check for whether it was derived from the password or not, thus completing the user authentication. Note again that the password itself does not leave the user’s computer. What browser and server exchange is cryptographic number based on the verifier and password.

The properties of the SRP protocol make it resistant to eavesdropping and man-in-the-middle attacks. A TLS/SSL channel is not technically required to secure the message exchange in the SRP protocol, but if used can add an additional layer of protection.

Combining SRP with PBKDF2 for even greater overall security

To make brute force attacks against leaked SRP verifiers from a compromised server harder, we recommend using multiple iterations (1000+) of PBKDF2 on the input password in JavaScript. Using PBKDF2 with SRP in this way can significantly up the security of the entire authentication system. It also can save on the server bills, since the CPU-intensive PBKDF2 iterations happen not on the server, but on the user’s computer, inside their browser.

How to implement SRP + PBKDF2

Connect2id offers a comprehensive open source Java library for SRP servers and clients, as well as a command-line tool for testing and debugging purposes.

There also exist a number of JavaScript libraries, to perform the necessary modulus and PBKDF2 computations inside the browser. Google and Mozilla have recognised the importance of having native support of crypto operations inside the browser as evidenced by the WebCrypto API effort at the W3C which is quickly approaching completion.

To sum up, all required technology for SRP and PBKDF2 is there, so there’s no excuse to not make authentication for users more secure.

Enabling SRP for LDAP authentication

We have also added Secure Remote Password support to our Json2Ldap middleware, so that businesses can easily implement SRP authentication against their existing LDAP directory servers. Get in touch with us to find out more about this option.