The Future of Secure Remote Password (SRP)

  • Written By: Brenda Coulson
  • Published On: March 3 2003



Introduction

The Secure Remote Password (SRP) is the latest in strong password-based authentication protocols. It holds great promise as a way to strongly authenticate a user without the usual risks of dictionary attack(s) faced by other password-based authentication schemes. Yet despite its deficiencies, the industry de-facto standard remains the password-based authentication scheme.

The current insecure schemes remain in place because of their conveniences, requiring no client software and only requiring the client to remember a single password. The providers of these systems hope the shortcomings will go unnoticed. The situation is slightly improved by the use of HTTPS, which provides encryption over the network, but it does not address the possibility of an attack on the password database.

To address the entire problem, a new family of protocols called Encrypted Key Exchange (EKE) was introduced. The newest addition to this family is SRP (Secure Remote Password). The need for a secure alternative is even greater now than when EKE was introduced due to the growing number of channels being used to transact business.

This article explores the possibilities for SRP in today's multi-channel world, specifically how it improves upon the inherent insecurity of password authentication and the obstacles to overcome to succeed.

This is Part One of a two-part article. This part presents the case for SRP.

Part Two will discuss the obstacles to acceptance of SRP and makes suggestions as to how it can gain acceptance.

History of SRP

The focus on strong authentication mechanisms came under scrutiny in the early 1990s with the Internet boom and the ever-growing need to authenticate people across insecure channels. Historically, when an application requires strong authentication, it has been believed that small passwords were insufficient and that a large password would prevent common dictionary attacks. Yet large random passwords have their own problem people fail to memorize them. More than likely, the user will need to write down the password to remember it, thereby compromising its security if the piece of paper gets into the wrong hands.

So we turn to biometrics or PKI (storing large cryptographic keys on smart cards) for help. Although an effective means of security, it has its own set of issues. With the ever-increasing power of computers, the acceptable key size for smart cards or similar authentication mechanisms is becoming prohibitively large not to mention the possibility of theft of the physical card and the cost. As for biometrics, its inconvenience prohibits its widespread acceptance. So we return to password-based authentication schemes and ask can we allow small easy to remember passwords without compromising security?

The real question to ask is "how to prove that you know a small secret without revealing it", commonly known as the Zero Knowledge Password Proof (ZKPP). Fortunately, a new family of protocols was introduced to solve this very problem, the first of which was Exponential Key Exchange (EKE) introduced in 1992 followed swiftly by SPEKE (Simple Password Exponential Key Exchange) in 1996.

These protocols are based on the Diffie-Hellman exchange, except a password rather than a fixed public number forms the base of the exchange. The protocol has two stages, a key exchange where the two parties in question negotiate a Diffie-Hellman key based on a shared secret (password), and a verification stage where they prove to each other that they know the same session key. There have been several proposed extensions and improvements to SPEKE: A-EKE (Augmented EKE), B-EKE (differs from SPEKE in that the password verifier is not a plain-text equivalent of the password), and finally SRP (functionally equivalent to A-EKE and B-EKE with performance improvements).

Secure Remote Password (SRP) does not require the password to be sent across the network. The System has a verifier derived from the password. There are a series of handshakes between the client and server. Once all the handshakes are complete, if everything verifies, then the user has been authenticated without exchanging enough information for a hacker to perform an easy dictionary attack.

SRP is built on the premise that the user can choose a "weak" password without impacting the strength of the authentication scheme, the exact question we set out to answer. Once the user is authenticated, an open secure session is established for communication. To further thwart attack, SRP uses temporary keys, so each session is different. Below is a very simplified description of the SRP-3 client-server handshake.

  • Client sends server username or other unique identifier for server lookup.

  • Server retrieves verifier (v), generator (g) and salt(s) based on Client's unique id.

  • Server sends salt (s) to Client.

  • Client computes x (private key) using s and password (P).

  • Client computes random number (a) and ephemeral public key (A) based on g and a.

  • Client sends A to Server.

  • Server computes random number (b) and ephemeral public key (B) based on b, g and v.

  • Server sends B and randomly generated parameter, u to Client.

  • Client computes common exponential value (S) from B, g, a, x and u.

  • Server computes common exponential value (S) from A, v, u, and b.

  • Both sides hash the exponential value S to create a session key K.

  • Client computes M[1] a hash based on K, A, and B.

  • Client sends M[1] to server as proof that it has the correct session key.

  • Server computes M[1] and verifies that it matches the version sent by the Client.

  • Server computes M[2] a hash based on A, M[1] and K

  • Server sends M[2] to Client as proof that it has the correct session key.

  • Client verifies M[2], accepting it only if it matches value provided by Server.

  • All future transactions during this session' must include the session key in their transmission for authorization purposes.

Potential For Success

Ever since its inception, the SRP authentication protocol has received considerable attention and has great potential for ultimate adaptation throughout the industry due to a number of reasons. Pure Strength of Numbers There is a strong mathematical algorithm behind the protocol, although this article does not provide details on the algorithm such information can be accessed at http://srp.stanford.edu/ndss.html.

Spoof Proof

SRP is full proof against the most common dictionary attacks. One of the main shortcomings of previous authentication mechanisms is their susceptibility to dictionary attacks the ability to guess a password by trying all possible permutations. Even if the password is transferred encrypted, if the password is stored plain text on the server, an attacker can gain access to persistent storage and suddenly the security of your system is compromised. SRP addresses this problem in two ways. First, it mandates that the password is never sent, plain text or otherwise, across the network. Second, the password is not stored at the server, but rather two pieces of information are stored a password verification base element and a verifier (a password-based public key), are stored.

Multi-Channel Support

Provides secure authentication mechanism for insecure network channels. Herein lies the greatest promise of SRP. With the plethora of channels in today's world, a need for a way to authenticate a client based on a small' secret is critical. For instance, clients need to access their enterprises and e-business sites via cellular phones, PDAs, set top boxes, voice gateways, and potentially others. Many of these devices are constrained by physical resources (CPU, memory) as well as available input (small numeric keypads) not to mention the fact that they are sending data over unprotected wireless networks.

Providing a way to strongly authenticate these users without installing cryptographic tokens, without requiring long random passwords and without requiring third-party involvement is extremely valuable. Also the ability to provide a consistent authentication mechanism across these channels is ideal for e-business vendors and enterprise systems targeting multiple channels. For cellular phones, PDAs, and set top boxes, a J2ME application could provide the smart client software. Ideally, SRP could be built into the protocol layer itself (see Obstacles to Endorsement below for more details).

Growing Acceptance in the Industry

Growing acceptance by a number of the big players in the field is promising.

  • o JBoss (www.jboss.org) , makers of the leading open-source J2EE application server, now contains an implementation of SRP in its security extension, JBossSX (for JBoss 2.4 and higher). The implementation is protocol-independent but defaults to RMI.

  • Cryptix, a provider of open-source cryptographic toolkits, offers an open source Java implementation of SRP SASL. SourceForge is doing development although it is still a Cryptix project. It provides authentication support for connection-based protocols based on SASL (Simple Authentication and Security Layer) RFC 2222. It is often used with popular Internet protocols such as POP3, IMAP, SMTP, and LDAP.

    • http://www.ietf.org/internet-drafts/draft-burdis-cat-srp-sasl-07.txt (web site containing draft for SRP implementation of SASL mechanism).

    • Acceptance of the SASL into the Java programming language is pending. The Java Community Process accepted the final draft of the JSR 28 in March, 2002. In September 2002, a maintenance update (the first maintenance release) was proposed (version 1.1). It should be fully integrated into a future release of the JDK.

  • Large selection of telnet software products, both commercial and open source, that support SRP, including a Java Telnet Applet enabling the user to authenticate via SRP in a telnet session initiated from within a web browser. All remaining communication between the applet and the server are over telnet rather than HTTP, but it does allow a web user to be authenticated via SRP.

The data points above are testimony to the future of SRP, however there are still some obstacles to overcome before widespread acceptance.

This concludes Part One of a two-part article.

Part Two will discuss Obstacles to Acceptance of SRP and how they can be overcome.

About The Author

Brenda Coulson is a Software Architect at Cysive, Inc. where she works in Product Development on the Cymbio Interaction Server. Brenda is a Sun Certified Java Programmer and Java Developer, and holds a BS degree from James Madison University.

Brenda may be reached at bcoulson@cysive.com.

References

Glossary

  • Dictionary Attack is a term used to describe an attack on the password storage. Typically, the attacker sniffs the encrypted password from storage or the network and then tries to guess the associated plain-text password by trying all permutations (something easily done today by a computer program).

  • EKE is Encrypted Key Exchange developed by Steve Bellovin and Michael Merritt of Bell Labs in 1992.

  • A-EKE is an augmented version of EKE

  • B-EKE is the second augmented version of EKE

  • DH-EKE Diffie-Hellman Encrypted Key Exchange

  • SRP is Secure Remote Password

  • SPEKE is Simple Password Exponential Key Exchange

  • ZKPP Zero Knowledge Password Proof
 
comments powered by Disqus