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.
is Part One of a two-part article. This part presents the case for SRP.
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.
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
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
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 a hash based on K, A, and B.
Client sends M to server as proof that it has the correct session key.
Server computes M and verifies that it matches the version sent by the
Server computes M a hash based on A, M and K
Server sends M to Client as proof that it has the correct session key.
Client verifies M, 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
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.
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.
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
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,
(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.
concludes Part One of a two-part article.
Two will discuss Obstacles to Acceptance of SRP and how they can be overcome.
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
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
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