Show Table of Contents
10.6. The Secure Remote Password (SRP) Protocol
The SRP protocol is an implementation of a public key exchange handshake described in the Internet standards working group request for comments 2945(RFC2945). The RFC2945 abstract states:
This document describes a cryptographically strong network authentication mechanism known as the Secure Remote Password (SRP) protocol. This mechanism is suitable for negotiating secure connections using a user-supplied password, while eliminating the security problems traditionally associated with reusable passwords. This system also performs a secure key exchange in the process of authentication, allowing security layers (privacy and/or integrity protection) to be enabled during the session. Trusted key servers and certificate infrastructures are not required, and clients are not required to store or manage any long-term keys. SRP offers both security and deployment advantages over existing challenge-response techniques, making it an ideal drop-in replacement where secure password authentication is needed.
Note: The complete RFC2945 specification can be obtained from http://www.rfc-editor.org/rfc.html. Additional information on the SRP algorithm and its history can be found at http://www-cs-students.stanford.edu/~tjw/srp/.
SRP is similar in concept and security to other public key exchange algorithms, such as Diffie-Hellman and RSA. SRP is based on simple string passwords in a way that does not require a clear text password to exist on the server. This is in contrast to other public key-based algorithms that require client certificates and the corresponding certificate management infrastructure.
Algorithms like Diffie-Hellman and RSA are known as public key exchange algorithms. The concept of public key algorithms is that you have two keys, one public that is available to everyone, and one that is private and known only to you. When someone wants to send encrypted information to you, then encrpyt the information using your public key. Only you are able to decrypt the information using your private key. Contrast this with the more traditional shared password based encryption schemes that require the sender and receiver to know the shared password. Public key algorithms eliminate the need to share passwords.
The JBossSX framework includes an implementation of SRP that consists of the following elements:
- An implementation of the SRP handshake protocol that is independent of any particular client/server protocol
- An RMI implementation of the handshake protocol as the default client/server SRP implementation
- A client side JAAS
LoginModuleimplementation that uses the RMI implementation for use in authenticating clients in a secure fashion - A JMX MBean for managing the RMI server implementation. The MBean allows the RMI server implementation to be plugged into a JMX framework and externalizes the configuration of the verification information store. It also establishes an authentication cache that is bound into the JBoss server JNDI namespace.
- A server side JAAS
LoginModuleimplementation that uses the authentication cache managed by the SRP JMX MBean.
Figure 10.14, “The JBossSX components of the SRP client-server framework.” gives a diagram of the key components involved in the JBossSX implementation of the SRP client/server framework.

Figure 10.14. The JBossSX components of the SRP client-server framework.
On the client side, SRP shows up as a custom JAAS
LoginModule implementation that communicates to the authentication server through an org.jboss.security.srp.SRPServerInterface proxy. A client enables authentication using SRP by creating a login configuration entry that includes the org.jboss.security.srp.jaas.SRPLoginModule. This module supports the following configuration options:
- principalClassName: This option is no longer supported. The principal class is now always
org.jboss.security.srp.jaas.SRPPrincipal. - srpServerJndiName: The JNDI name of the
SRPServerInterfaceobject to use for communicating with the SRP authentication server. If bothsrpServerJndiNameandsrpServerRmiUrloptions are specified, thesrpServerJndiNameis tried beforesrpServerRmiUrl. - srpServerRmiUrl: The RMI protocol URL string for the location of the
SRPServerInterfaceproxy to use for communicating with the SRP authentication server. - externalRandomA: A true/false flag indicating if the random component of the client public key A should come from the user callback. This can be used to input a strong cryptographic random number coming from a hardware token for example.
- hasAuxChallenge: A true/false flag indicating that a string will be sent to the server as an additional challenge for the server to validate. If the client session supports an encryption cipher then a temporary cipher will be created using the session private key and the challenge object sent as a
javax.crypto.SealedObject. - multipleSessions: a true/false flag indicating if a given client may have multiple SRP login sessions active simultaneously.
Any other options passed in that do not match one of the previous named options is treated as a JNDI property to use for the environment passed to the
InitialContext constructor. This is useful if the SRP server interface is not available from the default InitialContext.
The
SRPLoginModule needs to be configured along with the standard ClientLoginModule to allow the SRP authentication credentials to be used for validation of access to security J2EE components. An example login configuration entry that demonstrates such a setup is:
srp {
org.jboss.security.srp.jaas.SRPLoginModule required
srpServerJndiName="SRPServerInterface"
;
org.jboss.security.ClientLoginModule required
password-stacking="useFirstPass"
;
};
On the JBoss server side, there are two MBeans that manage the objects that collectively make up the SRP server. The primary service is the
org.jboss.security.srp.SRPService MBean, and it is responsible for exposing an RMI accessible version of the SRPServerInterface as well as updating the SRP authentication session cache. The configurable SRPService MBean attributes include the following:
- JndiName: The JNDI name from which the SRPServerInterface proxy should be available. This is the location where the
SRPServicebinds the serializable dynamic proxy to theSRPServerInterface. If not specified it defaults tosrp/SRPServerInterface. - VerifierSourceJndiName: The JNDI name of the
SRPVerifierSourceimplementation that should be used by theSRPService. If not set it defaults tosrp/DefaultVerifierSource. - AuthenticationCacheJndiName: The JNDI name under which the authentication
org.jboss.util.CachePolicyimplementation to be used for caching authentication information is bound. The SRP session cache is made available for use through this binding. If not specified it defaults tosrp/AuthenticationCache. - ServerPort: RMI port for the
SRPRemoteServerInterface. If not specified it defaults to 10099. - ClientSocketFactory: An optional custom
java.rmi.server.RMIClientSocketFactoryimplementation class name used during the export of theSRPServerInterface. If not specified the defaultRMIClientSocketFactoryis used. - ServerSocketFactory: An optional custom
java.rmi.server.RMIServerSocketFactoryimplementation class name used during the export of theSRPServerInterface. If not specified the defaultRMIServerSocketFactoryis used. - AuthenticationCacheTimeout: Specifies the timed cache policy timeout in seconds. If not specified this defaults to 1800 seconds(30 minutes).
- AuthenticationCacheResolution: Specifies the timed cache policy resolution in seconds. This controls the interval between checks for timeouts. If not specified this defaults to 60 seconds(1 minute).
- RequireAuxChallenge: Set if the client must supply an auxiliary challenge as part of the verify phase. This gives control over whether the
SRPLoginModuleconfiguration used by the client must have theuseAuxChallengeoption enabled. - OverwriteSessions: A flag indicating if a successful user auth for an existing session should overwrite the current session. This controls the behavior of the server SRP session cache when clients have not enabled the multiple session per user mode. The default is false meaning that the second attempt by a user to authentication will succeed, but the resulting SRP session will not overwrite the previous SRP session state.
The one input setting is the
VerifierSourceJndiName attribute. This is the location of the SRP password information store implementation that must be provided and made available through JNDI. The org.jboss.security.srp SRPVerifierStoreService is an example MBean service that binds an implementation of the SRPVerifierStore interface that uses a file of serialized objects as the persistent store. Although not realistic for a production environment, it does allow for testing of the SRP protocol and provides an example of the requirements for an SRPVerifierStore service. The configurable SRPVerifierStoreService MBean attributes include the following:
- JndiName: The JNDI name from which the
SRPVerifierStoreimplementation should be available. If not specified it defaults tosrp/DefaultVerifierSource. - StoreFile: The location of the user password verifier serialized object store file. This can be either a URL or a resource name to be found in the classpath. If not specified it defaults to
SRPVerifierStore.ser.
The
SRPVerifierStoreService MBean also supports addUser and delUser operations for addition and deletion of users. The signatures are:
public void addUser(String username, String password) throws IOException; public void delUser(String username) throws IOException;
An example configuration of these services is presented in Example 10.10, “The SRPVerifierStore interface”.
10.6.1. Providing Password Information for SRP
The default implementation of the
SRPVerifierStore interface is not likely to be suitable for your production security environment as it requires all password hash information to be available as a file of serialized objects. You need to provide an MBean service that provides an implementation of the SRPVerifierStore interface that integrates with your existing security information stores. The SRPVerifierStore interface is shown in.
Example 10.10. The SRPVerifierStore interface
package org.jboss.security.srp;
import java.io.IOException;
import java.io.Serializable;
import java.security.KeyException;
public interface SRPVerifierStore
{
public static class VerifierInfo implements Serializable
{
/**
* The username the information applies to. Perhaps redundant
* but it makes the object self contained.
*/
public String username;
/** The SRP password verifier hash */
public byte[] verifier;
/** The random password salt originally used to verify the password */
public byte[] salt;
/** The SRP algorithm primitive generator */
public byte[] g;
/** The algorithm safe-prime modulus */
public byte[] N;
}
/**
* Get the indicated user's password verifier information.
*/
public VerifierInfo getUserVerifier(String username)
throws KeyException, IOException;
/**
* Set the indicated users' password verifier information. This
* is equivalent to changing a user's password and should
* generally invalidate any existing SRP sessions and caches.
*/
public void setUserVerifier(String username, VerifierInfo info)
throws IOException;
/**
* Verify an optional auxiliary challenge sent from the client to
* the server. The auxChallenge object will have been decrypted
* if it was sent encrypted from the client. An example of a
* auxiliary challenge would be the validation of a hardware token
* (SafeWord, SecureID, iButton) that the server validates to
* further strengthen the SRP password exchange.
*/
public void verifyUserChallenge(String username, Object auxChallenge)
throws SecurityException;
}
The primary function of a
SRPVerifierStore implementation is to provide access to the SRPVerifierStore.VerifierInfo object for a given username. The getUserVerifier(String) method is called by the SRPService at that start of a user SRP session to obtain the parameters needed by the SRP algorithm. The elements of the VerifierInfo objects are:
- username: The user's name or id used to login.
- verifier: This is the one-way hash of the password or PIN the user enters as proof of their identity. The
org.jboss.security.Utilclass has acalculateVerifiermethod that performs that password hashing algorithm. The output passwordH(salt | H(username | ':' | password))as defined by RFC2945. HereHis the SHA secure hash function. The username is converted from a string to abyte[]using the UTF-8 encoding. - salt: This is a random number used to increase the difficulty of a brute force dictionary attack on the verifier password database in the event that the database is compromised. It is a value that should be generated from a cryptographically strong random number algorithm when the user's existing clear-text password is hashed.
- g: The SRP algorithm primitive generator. In general this can be a well known fixed parameter rather than a per-user setting. The
org.jboss.security.srp.SRPConfutility class provides several settings for g including a good default which can obtained viaSRPConf.getDefaultParams().g(). - N: The SRP algorithm safe-prime modulus. In general this can be a well known fixed parameter rather than a per-user setting. The
org.jboss.security.srp.SRPConfutility class provides several settings forNincluding a good default which can obtained viaSRPConf.getDefaultParams().N().
So, step 1 of integrating your existing password store is the creation of a hashed version of the password information. If your passwords are already store in an irreversible hashed form, then this can only be done on a per-user basis as part of an upgrade procedure for example. Note that the
setUserVerifier(String, VerifierInfo) method is not used by the current SRPSerivce and may be implemented as no-op method, or even one that throws an exception stating that the store is read-only.
Step 2 is the creation of the custom
SRPVerifierStore interface implementation that knows how to obtain the VerifierInfo from the store you created in step 1. The verifyUserChallenge(String, Object) method of the interface is only called if the client SRPLoginModule configuration specifies the hasAuxChallenge option. This can be used to integrate existing hardware token based schemes like SafeWord or Radius into the SRP algorithm.
Step 3 is the creation of an MBean that makes the step 2 implementation of the
SRPVerifierStore interface available via JNDI, and exposes any configurable parameters you need. In addition to the default org.jboss.security.srp.SRPVerifierStoreService example, the SRP example presented later in this chapter provides a Java properties file based SRPVerifierStore implementation. Between the two examples you should have enough to integrate your security store.

Where did the comment section go?
Red Hat's documentation publication system recently went through an upgrade to enable speedier, more mobile-friendly content. We decided to re-evaluate our commenting platform to ensure that it meets your expectations and serves as an optimal feedback mechanism. During this redesign, we invite your input on providing feedback on Red Hat documentation via the discussion platform.