← Back to Blog

The Use of Secure Remote Password in LoginTC

December 06, 2013 • William Morrison

When dealing with client/server architectures communicating over insecure networks, implementing secure authentication becomes a challenge. All sorts of attacks are possible, ranging from sniffing network traffic for offline brute force guessing of passwords to active impersonation. Even when the network is secured, securely storing passwords is clearly a difficulty for many companies, as evidenced by the many high profile leaks that have occurred lately, affecting tens of millions of people. Furthermore, even protections such as SSL/TLS are not sufficient to guarantee strong authentication, as evidenced by the multiple attacks on the protocol in the past that necessitate revisions and new versions.

An Overview of Secure Remote Password

The Secure Remote Password (SRP) protocol is a cryptographic protocol that provides a zero-knowledge proof-of-knowledge, and allows a client to prove knowledge of a password, or any other data, without revealing what that data actually is. It was developed at Stanford University between 1997 and 1998, and updated in 2002 to improve security even further.

SRP has some very nice cryptographic properties.

• The client never has to store the password or any other data locally.
• The server never knows the client’s password.
• Replay attacks are impossible.
• Even if an attacker records an entire successful authentication, they don’t have enough data to brute force the password offline.
• SRP provides perfect forward secrecy. The shared secret derived is different each time, and no private keys are needed that could be stolen.
• Even if the server is hacked and the password verifiers are stolen, an attacker can’t use the verifiers to authenticate as a client without an expensive brute force search.
• If more security is desired, larger public parameters can be chosen.

The SRP protocol has been widely standardized, including RFC 5054 by the IETF, requires no external infrastructure or trusted third parties, and can operate securely over insecure networks. It also has the benefit that no passwords or password equivalents are ever stored on the server, so even if an attacker manages to dump the server database, they can’t use that data to determine passwords, or even authenticate with the server, unless they perform expensive brute force calculations. Finally, it is unencumbered by patents, has an open source reference implementation released under a permissive license, and is implemented by multiple cryptographic libraries as part of SSL/TLS.

A Two Step Protocol

To use SRP, a client must go through a setup phase before they can authenticate. In this phase, the client chooses a password and calculates a verifier, which it sends to the server. This verifier is not password equivalent, like a hash of the password would be, and it cannot be used to authenticate. It is used by the server only to verify that the password is known by the client during the authentication protocol.

In the authentication protocol, the client gets the password from the user and uses this as input to the SRP protocol. If the password is correct, the SRP protocol derives a strong shared secret between the client and server through a process similar to a Diffie-Helmann exchange. The client then proves that it knows the correct password by proving that it derived the same secret value as the server. It does this by hashing the shared secret together with other values that the server knows, and sending the hash to the server as a proof. The server calculates its own hash from the same values and the secret it derived. If the hashes match, the client must have had the correct password.

How LoginTC Uses Secure Remote Password

LoginTC uses SRP for more than just passwords. As a multi-factor authentication solution, we need to verify not only that a user knows their PIN or password, but also that they have the correct device. We can’t trust a client to just tell us what device they’re using, as an attacker could lie about that, so we need something better. We also need to protect tokens from being moved to different devices, both by backups, and by malicious attackers.

When a user loads a token for the first time, they lock it with a PIN. This PIN is combined with device IDs and a per-token device secret to create a final piece of data, the token secret. We create the SRP verifier for this token secret, and send that to the server, which stores it for future use. Note that the client does not store either the token secret or the verifier, it forgets them as soon as it is done using them.

At some point, the user will want to approve a request. To do this, they will need to recalculate the token secret. This requires them to know the PIN, the device IDs, and the device secret at the time of authentication. Once they create their token secret, they can use it as an input to the SRP protocol, which proves their knowledge of the correct token secret to the server.

The Token Secret

The approach LoginTC takes is to create a piece of data, known as the token secret, when the token is loaded, and during each request. This token secret includes all the information that we need to prove to the server in a single neat package, and acts as the “password” for the purposes of the SRP protocol, never leaving the device, and never being stored on the device. Currently, it is composed of the PIN, a random per-token device secret, and device IDs provided by the platform. Each piece of the token secret has a part to play.

The PIN is retrieved from the user at authentication time, and never stored in any form on the device. Knowledge of the PIN fufills the “something you know” factor. LoginTC can use more than just a PIN if needed too. Administrators can choose to require passwords, and even define the acceptable strength of those passwords if they want more security.

The per-token device secret helps fufill the “something you have” factor. When the token is loaded, the client generates a random secret for the token and stores it on the device, protected by any methods offered by the client platform. If an attacker cannot steal or guess this secret, they cannot derive the correct token secret, even if they know all the other information.

The device IDs are used to prevent backups from accidentally moving the token to another device, providing more protection for the “something you have” factor. At authentication time, a device ID is retrieved using platform provided APIs, making it a dynamically generated device identifier. Even if the PIN is the same, and the per-token secret has been backed up to a new device, the device ID will be different from the one that was used when the token was loaded. This will cause the derived token secret to be different, and the authentication attempt will fail.

We calculate the token secret by combining the PIN, device secret, and device IDs using PBKDF2, giving us two security benefits. First, PBKDF2 can be configured to take longer by increasing the number of iterations, which slows down any brute force attacks if an attacker has managed to dump the server database and stolen the verifiers. We can even use different numbers of iterations for different tokens, allowing us to increase the security that PBKDF2 provides when tokens are loaded on faster devices. Second, the PBKDF2 calculation only ever happens on the client, so a denial-of-service attack that tries to tie up a server by making it perform lots of PBKDF2 calculations won’t work, as it might with a regular password checking system like many servers use today.

Benefits of Using Secure Remote Password

We use a single run of the SRP protocol to prove the token secret, which contains all the required information to authenticate, so an attacker cannot guess the different parts piece by piece but must guess everything correctly at once. This is a major strength when dealing with cryptographic protections, and failure to do this has led to the cryptographic failure of some high profile applications. NTLM hashes, used for Windows authentication, and WPS, used in many home wireless routers, both suffer from weaknesses due to disregarding this important idea.

Furthermore, the use of SRP in conjunction with the token secret also makes implementation details about the derivation of this secret transparent to the server. All the server cares about is whether the token secret that the client calculated is the same one that the client used when it loaded the token. This gives us extra flexibility to make things even more secure on the client side, by taking advantage of any features offered by the platform to tie the token to the device.

The SRP protocol is nice from the network perspective, but it provides benefits on the server as well. Remember that the verifier cannot be used to authenticate as a client without first performing an expensive brute force calculation. This is a very important property, because it makes the server’s database less valuable to an attacker, deterring them from trying an attack in the first place. It is a similar concept to correct hashing of passwords, but comes as a built in benefit of using SRP.

Conclusion

The use of SRP is a huge step forward, and allows us to complement other approaches to security, such as the use of SSL/TLS for all network connections and the ability of the push network to route requests securely to the right device. This layered approach provides the best possible assurance of strong authentication for your users, and allows us to improve security even further by taking advantage of any platform specific protections. Combining this strong technical security with great user experience makes LoginTC the best multi-factor authentication available today.

← Back to Blog