Motivation for Using SRP

Now that we have this new password-authentication protocol, you might be wondering what the big deal is. After all, new security-related protocols and algorithms seem to be invented all the time. What is so revolutionary about SRP that distiguishes it from the rest of the pack? This page will attempt to answer that question while at the same time advancing concrete proposals regarding possible immediate uses for SRP.

The Status Quo is Unacceptable

It is generally accepted wisdom among the security community that no one really cares about security until something bad happens to them. Whether the loss is tangible (destruction of critical data or financial losses) or intangible (downtime or embarrassment), it almost always happens because existing systems were thought to be "good enough" to withstand at least casual attack. Recent years have seen a dramatic improvement in the resources available to potential intruders, along with an increase in the value of data and systems on the Internet. Not surprisingly, incidents involving weak password security are becoming increasinly common, causing more damage with each new breakin. For example, incidents at Stanford University and MIT show that even the best-run facilities are vulnerable. CERT, in its 1994 annual report, noted the threat of network-based attack in a document entitled, Ongoing Network Monitoring Attacks. Jeff Schiller of MIT believes that "just about every open network in a medium-to-large institution has sniffers on it."

In an environment where the Internet is increasingly open to eavesdroppers, weak password systems are security incidents waiting to happen. Even choosing a "good" password will not protect it from a packet sniffer. And although Kerberos is starting to gain acceptance as a secure distributed authentication system, the initial ticket-granting protocols in both Kerberos V4 and V5 (without pre-authentication) have been broken, permitting anyone with network access to the authentication server to run a password-cracker against the master password list.

The intention of this section is not to scare anyone, but instead to point out the seriousness of existing security weaknesses and to dispel the notion that it isn't worth the trouble to upgrade to a stronger system. Indeed, the cost of not upgrading will undoubtedly be far higher than any amount of time installing the SRP distribution, especially since it requires practically no change or other inconvenience for users. Dr. John D. Howard, in a paper analyzing Internet security incidents, recommended that: "Internet suppliers should provide protocols and software that encrypt these data at the source, or provide alternative systems that do not require passwords to be sent in the clear across the Internet."

The Unix Password File Format

For over two decades, the Unix operating system has used the same format for storing passwords. A file named /etc/passwd held a password entry for each user on the system that looked like:

tjw:BUbc2vSLYq9Ls:501:100:Tom Wu:/home/tjw:/bin/ksh

The second field contains a base-64 representation of a hash of the plaintext password. The advantage of storing passwords in this form instead of as plaintext is that the password file can be made world-readable without leaking password information to other users on the system.

Unix traditionally uses a DES-based hashing function to generate the password field. Although 56-bit DES is starting to show signs of age (it is believed that routine brute-forcing of DES keys will become practical within five to ten years), the most glaring problem with this password authentication scheme is that it does not handle authentication over a network very well. Ironically, the most secure authentication protocol using the standard Unix hash is simply to send the plaintext directly over the network and have the server perform the hash and comparision. This is the only way in which the password file can be used without making its entries plaintext-equivalent to the password.

Sending a password across a public network unencrypted has been shown time and time again to be a major, easily-exploited security deficiency. It is surprisingly easy to set up both general-purpose computers and specialized hardware to monitor a TCP/IP network and "sniff" packets belonging to someone else's login session. This is a common method of attack, and one that has been carried out repeatedly and effectively here at Stanford University. Both the Distributed Computing Environment and various departmental computer clusters have been targeted by intruders who proceed to install "sniffers" in strategic locations and manage to capture hundreds of passwords as they are sent in the clear, including some super-user passwords and "Kerberized" login passwords. Of course, the original Unix system security designers can't really be blamed for this sorry state of affairs, since they did not design the original system with networking in mind.

Temporary Fixes and Workarounds

Clearly, standard Unix password file authentication is unacceptable for a networked environment, especially as the amount and value of information exchanged over the Internet rises. In response to this threat, a number of security-related products have been developed in the last decade or so in an attempt to improve the security of password authentication. Since no simple, secure two-party password-only authentication systems existed when these products were designed, they worked around the problem in one of two ways: Either they used a centralized authentication server that was assumed to be secure, thus moving the burden from the individual workstation to some centralized authority, or they negotiated some form of host-based secure channel before allowing standard Unix authentication to take place. Kerberos is an example of the former, while ssh is an example of the latter. These products are discussed in a separate page.

Although these products have been around for many years, they have not managed to gain widespread use and acceptance outside the computer security community. A recent sampling of network traffic in and around Stanford showed that the vast majority (over 90%) of login sessions, even those occurring between two points on campus, used neither secure authentication nor session encryption. This despite the fact that both Kerberos and ssh are supported here.

Why have users been so reluctant to adopt strong security measures to protect themselves? Simply stated, secure products are a pain to use. Kerberos, ssh, and products like them present users with a myriad of confusing new commands and options for them to memorize. Users are constantly reminded that they are using a "security product" and invariably need to change some of their behavior to use such software effectively, since they are based on technology that does not mesh transparently with the familiar password-only authentication model that most users are accustomed to. This translates into users who either balk at the introduction of secure software or who revert to using conventional, insecure software after a short while. The end result is that only the "power users" who are security-conscious end up using the secure software, which is exactly what has happened at Stanford. Many users think, "I don't need to worry about security; I don't have anything that valuable in my account anyway." In fact, that is often true, but even one user logging in insecurely is enough for a password-sniffing attacker to gain access to your system to compromise other, less forgiving users.

It has been said that main cost of security is not necessarily the cost of the secure software itself, but the cost of re-educating all the users and teaching them how to use the new software. Users like security, but they have in general proven very unwilling to sacrifice convenience to obtain it. Systems like Kerberos and ssh are wonderful utilities and programs that offer good security for those willing to put up with them. The next generation of secure systems will take things a step further, integrating security into applications like remote logins and file transfers at a level completely transparent to the user. Secure connections will gradually become the lowest common denominator, and network security will be as ubiquitous as networking itself is today.

A Better Way to Store Passwords

It should be clear to the casual reader by now that the Unix password file format needs updating if we want to place the system on the network and be able to sleep at night. It should also be clear that we want to avoid encumbering users with extraneous issues like key generation, private/public key files, or certificates if we expect our system to be used by any significant population of users.

If we model the algorithm used to turn plaintext passwords into hashes as a function f() that accepts the password as its argument, we can analyze the password file format in mathematical terms. The DES-based hash used by Unix, when represented as a function, does not have a useful mathematical structure. In other words, the mapping between the input and output, while deterministic, does not possess any interesting mathematical properties that might allow it to participate in a secure authentication protocol without being plaintext-equivalent to the password. Its only property of note is that it is difficult to invert.

Instead of using a "dead" one-way function for f(), our proposal is to substitute a more mathematically interesting, but secure, function for f(). The new f() is defined as:

f(p) = g ** H(s, p) (mod N)

where H() is a one-way hash, s is a random salt, and g and N are system-wide parameters. Astute readers will note that the output of f() corresponds exactly to the value v in the SRP protocol, while the term H(s, p) is merely x. Although x is plaintext-equivalent to the password, the final computation in f() performs an exponentiation in a prime field to calculate v. Taking v and inverting the exponentiation to obtain x is known as the "Discrete Logarithm Problem" and is believed to be very time-consuming. As long as this holds true, v is not plaintext-equivalent to the password.

To store the values v and s in a file, we convert them to base 64 ASCII. The password database itself is stored in a file named /etc/tpasswd. Its entries resemble the following:

tjw:C7.3L96NpXtYOOtS0MjVCBo9vMOOxgj3uVp.3i.vZDurfI2Il4r5aNP2YmO2QAkF:g8uXvjuoWitxTpITPiItL:1

The first field contains the username, the second field contains the encoded value of v, the third field contains the encoded salt, and the last field indicates which set of parameters to use for N and g. The list of parameters is stored in a separate file, /etc/tpasswd.conf, whose entries look like:

1:kCiZAR85BB8zgUQpiIhPUWGLsDcnJD64K6kxXvQrxJLPM/hD3sMkeNlsFuqxvCv/:IaJGJcoVxLVU7hY1OKD6ODEq1YdPogtv74FZdYUvlyM1r5B1LNT2CiARrJOelgLu

The first field corresponds to the index field in the password database, while the second and third fields hold N and g respectively. The /etc/tpasswd file does not actually replace the old /etc/passwd file entirely. It simply holds the password information for each user, and it can be made either world-readable or readable only to privileged system code. It is the analogue of the shadow password file /etc/shadow found on most newer Unix systems.

In a standalone environment, this new password file format isn't all that different from what we had before. We've used a different one-way hash function to generate the hashed passwords, and passwords can still be set and verified by running the plaintext through the hash function. The new exponentiating hash function also has the nice feature that the field size can be increased to make either a brute-force discrete-log attack or a dictionary attack on the password file more difficult. Still, the new format is fundamentally similar to the standard Unix password file format.

The big benefit comes when you add networking to the picture. The password database now contains all the information a server needs to negotiate the server side of the SRP protocol. The careful choice of the "live" hash function f() enables the server to construct a challenge that can only be answered correctly by a client who knows the actual password. Since the SRP protocol also exchanges session keys while authenticating, the client and server can also encrypt their communications once authentication succeeds. The end result is a password file format that can survive being compromised (stolen) by an intruder yet can be used to verify passwords securely over an untrusted network.

Securing system services

With this new password file format in place, it is now possible for networked services like Telnet (remote login) and FTP (file transfer) to perform secure, password-only authentication over the network. Since this authentication is password-only, it can be done in a manner completely transparent to the user. Had SRP been developed a few years earlier, the ongoing effort to incorporate it into existing applications might not be necessary today.

Prototype implementations of SRP-enhanced Telnet and FTP have been written and deployed in our local research group. More detailed information on each of these utilities will be provided on a separate page. Recent traffic analysis within our group's local network indicates that over half the session traffic is now encrypted, and we expect that figure to increase as SRP-enabled systems and utilities become more widely used around Stanford and in the outside world.

SRP authentication doesn't stop with just Telnet and FTP, either. The protocol can be used to secure any service with a password. POP (mail), IMAP, NNTP (news), and HTTP (Web) are just some examples of protocols that can benefit from secure authentication and encryption services. Services like Kerberos, NIS, and NIS+ can also be upgraded to support the SRP-aware password system, thus enabling interoperability with existing SRP implementations. SRP's greatest contribution to the field of secure networking is its ability to negotiate both strong authentication and encryption with nothing more than a password from the user. The user can go about his business, knowing that his communications are being encrypted and that his password is safe from prying eyes, but not having to do anything special to make it happen.

Back