Red Hat Summit 红帽全球峰会支持控制台（Console）开发人员开始试用联系人

此内容没有您所选择的语言版本。

Chapter 13. Secure Remote Password Protocol

The Secure Remote Password (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.
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/ .
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, they encrypt 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 LoginModule implementation 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 server JNDI namespace.
  • A server side JAAS LoginModule implementation that uses the authentication cache managed by the SRP JMX MBean.
Figure 13.1, “The JBossSX components of the SRP client-server framework.” describes the key components involved in the JBossSX implementation of the SRP client/server framework.
The JBossSX components of the SRP client-server framework.
View larger image
The JBossSX components of the SRP client-server framework.

Figure 13.1. The JBossSX components of the SRP client-server framework.

On the client side, SRP shows up as a custom JAAS LoginModule implementation that communicates with 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:
srpServerJndiName
JNDI name of the SRPServerInterface object used to communicate with the SRP authentication server. If both srpServerJndiName and srpServerRmiUrl options are specified, srpServerJndiName takes priority over srpServerRmiUrl .
srpServerRmiUrl
RMI protocol URL string for the location of the SRPServerInterface proxy used to communicate with the SRP authentication server.
externalRandomA
Flag that specifies whether 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. If set to true , the feature is activated.
hasAuxChallenge
Flag that specifies whether 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 . If set to true , the feature is activated.
multipleSessions
Flag that specifies whether a given client may have multiple SRP log in sessions active. If set to true , the feature is activated.
Any other passed options that do not match one of the previously named options are 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 and the standard ClientLoginModule must be configured to allow SRP authentication credentials to be used for access validation to security Java EE components. An example login configuration is described in Example 13.1, “Login Configuration Entry” .

Example 13.1. Login Configuration Entry

srp {
    org.jboss.security.srp.jaas.SRPLoginModule required
    srpServerJndiName="SRPServerInterface"
    ;
            
    org.jboss.security.ClientLoginModule required
    password-stacking="useFirstPass"
    ;
};
Copy to Clipboard Toggle word wrap
On the 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. The other MBean is org.jboss.security.srp.SRPVerifierStoreService .
org.jboss.security.srp.SRPService 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
Specifies the name from which the SRPServerInterface proxy should be available. This is the location where the SRPService binds the serializable dynamic proxy to the SRPServerInterface . The default value is srp/SRPServerInterface .
VerifierSourceJndiName
Specifies the name of the SRPVerifierSource implementation the SRPService must use. The source JNDI name defaults to srp/DefaultVerifierSource .
AuthenticationCacheJndiName
Specifies the name under which the org.jboss.util.CachePolicy authentication implementation used for caching authentication information is bound. The SRP session cache is made available for use through this binding. The authentication JNDI cache defaults to srp/AuthenticationCache .
ServerPort
RMI port for the SRPRemoteServerInterface . The default value is 10099.
ClientSocketFactory
Optional custom java.rmi.server.RMIClientSocketFactory implementation class name used during the export of the SRPServerInterface . The default value is RMIClientSocketFactory .
ServerSocketFactory
Optional custom java.rmi.server.RMIServerSocketFactory implementation class name used during the export of the SRPServerInterface . The default value is RMIServerSocketFactory .
AuthenticationCacheTimeout
Cache policy timeout (in seconds). The default value is 1800 (30 minutes).
AuthenticationCacheResolution
Specifies the timed cache policy resolution (in seconds). This controls the interval between checks for timeouts. The default value is 60 (1 minute).
RequireAuxChallenge
Set if the client must supply an auxiliary challenge as part of the verify phase. This gives control over whether the SRPLoginModule configuration used by the client must have the useAuxChallenge option enabled.
OverwriteSessions
Specifies whether a successful user authentication 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. If set to false , the second user authentication attempt will succeed, however the resulting SRP session will not overwrite the previous SRP session state. The default value is false .
VerifierStoreJndiName
Specifies the location of the SRP password information store implementation that must be provided and made available through JNDI.
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
JNDI name from which the SRPVerifierStore implementation should be available. If not specified it defaults to srp/DefaultVerifierSource .
StoreFile
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;
Copy to Clipboard Toggle word wrap
An example configuration of these services is presented in Example 13.2, “The SRPVerifierStore interface” .

13.1. Understanding the Algorithm
复制链接

The appeal of the SRP algorithm is that is allows for mutual authentication of client and server using simple text passwords without a secure communication channel.

Note

Additional information on the SRP algorithm and its history can be found at http://srp.stanford.edu/.
There are six steps that are performed to complete authentication:
  1. The client side SRPLoginModule retrieves from the naming service the SRPServerInterface instance for the remote authentication server.
  2. The client side SRPLoginModule next requests the SRP parameters associated with the user name attempting the log in. There are a number of parameters involved in the SRP algorithm that must be chosen when the user password is first transformed into the verifier form used by the SRP algorithm. Rather than hard-coding the parameters (which could be done with minimal security risk), the JBossSX implementation allows a user to retrieve this information as part of the exchange protocol. The getSRPParameters(username) call retrieves the SRP parameters for the given user name.
  3. The client side SRPLoginModule begins an SRP session by creating an SRPClientSession object using the login user name, clear-text password, and SRP parameters obtained from step 2. The client then creates a random number A that will be used to build the private SRP session key. The client then initializes the server side of the SRP session by invoking the SRPServerInterface.init method and passes in the user name and client generated random number A. The server returns its own random number B. This step corresponds to the exchange of public keys.
  4. The client side SRPLoginModule obtains the private SRP session key that has been generated as a result of the previous messages exchanges. This is saved as a private credential in the login Subject. The server challenge response M2 from step 4 is verified by invoking the SRPClientSession.verify method. If this succeeds, mutual authentication of the client to server, and server to client have been completed. The client side SRPLoginModule next creates a challenge M1 to the server by invoking SRPClientSession.response method passing the server random number B as an argument. This challenge is sent to the server via the SRPServerInterface.verify method and server's response is saved as M2. This step corresponds to an exchange of challenges. At this point the server has verified that the user is who they say they are.
  5. The client side SRPLoginModule saves the login user name and M1 challenge into the LoginModule sharedState map. This is used as the Principal name and credentials by the standard JBoss ClientLoginModule. The M1 challenge is used in place of the password as proof of identity on any method invocations on Java EE components. The M1 challenge is a cryptographically strong hash associated with the SRP session. Its interception via a third partly cannot be used to obtain the user's password.
  6. At the end of this authentication protocol, the SRPServerSession has been placed into the SRPService authentication cache for subsequent use by the SRPCacheLoginModule.
Although SRP has many interesting properties, it is still an evolving component in the JBossSX framework and has some limitations of which you should be aware. Issues of note include the following:
  • Where authentication is performed, the way in which JBoss detaches the method transport protocol from the component container could allow a user to snoop the SRP M1 challenge and effectively use the challenge to make requests as the associated user name. Custom interceptors can be used to prevent the issue, by encrypting the challenge using the SRP session key.
  • The SRPService maintains a cache of SRP sessions that time out after a configurable period. Once they time out, any subsequent Java EE component access will fail because there is currently no mechanism for transparently renegotiating the SRP authentication credentials. You must either set the authentication cache timeout quite high, or handle re-authentication in your code on failure.

    Note

    The SRPService supports timeout durations up to 2,147,483,647 seconds, or approximately 68 years.
  • There can only be one SRP session for a given user name by default. The session is classed as stateful, because the negotiated SRP session produces a private session key that can be used for encryption and decryption between the client and server. JBoss supports multiple SRP sessions per user, however it is not possible to encrypt data with one session key, and decrypt it with another.
To use end-to-end SRP authentication for Java EE component calls, you must configure the security domain under which the components are secured to use the org.jboss.security.srp.jaas.SRPCacheLoginModule. The SRPCacheLoginModule has a single configuration option named cacheJndiName that sets the JNDI location of the SRP authentication CachePolicy instance. This must correspond to the AuthenticationCacheJndiName attribute value of the SRPService MBean.
The SRPCacheLoginModule authenticates user credentials by obtaining the client challenge from the SRPServerSession object in the authentication cache and comparing this to the challenge passed as the user credentials. Figure 13.2, “SRPCacheLoginModule with SRP Session Cache” illustrates the operation of the SRPCacheLoginModule.login method implementation.
SRPCacheLoginModule with SRP Session Cache
View larger image
SRPCacheLoginModule with SRP Session Cache

Figure 13.2. SRPCacheLoginModule with SRP Session Cache

返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务，以及可以信赖的内容，帮助红帽用户创新并实现他们的目标。 了解我们当前的更新.

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情，请参阅红帽博客.

關於紅帽

我们提供强化的解决方案，使企业能够更轻松地跨平台和环境（从核心数据中心到网络边缘）工作。

Theme

© 2025 Red Hat