by Rik Farrow <rik@spirit.com>
In 1996, I found myself standing in front of crowd of people predicting the death of passwords. Passwords had been used as a method for authenticating users to computer systems since (at least) the 1960's, and passwords had become the number one way to break-into systems. With the development of authentication devices, biometrics, and software-based one time passwords, it seemed only reasonable that a deficient system would bite the dust within a couple of years. Confidently, I predicted the end of passwords by the year 2000.
Nothing could be further from the truth. Today, most commercial systems still use passwords, and many computer breakins still involve capturing or guessing passwords. The use of networking has compounded the problem, as most network protocols that use passwords manage to reveal them to eavesdroppers, or make it possible to crack passwords based on sniffed information.
Spurred on my the obvious problems with passwords, and embarrassing security incidents involving sniffed passwords, researchers and vendors have been working hard at fixing the problem. One of the more interesting solutions turns out to be free, and might soon be appearing on a computer near you. Secure Remote Password uses mathematical tricks to improve on the security passwords that we use. But first, let's take a look at other ways passwords are used on networks.
Once upon a time, passwords made a lot of sense. Passwords are cheap, easy to use, and the implementation easy to write. Early password systems permitted timeshare users to enter their usernames and passwords, and log into the mainframe securely. Timesharing systems in the past had complete control over the communications media (serial lines, IBM 3270 terminals, etc.) and that meant chances for eavesdropping were minimal. And a select priesthood controlled the mainframes computers. Until the late 1970's, system engineers stored plaintext passwords in files, confident that no mere mortal could find the passwords or read them.
As computer systems systems became more accessible, storing plaintext passwords became unfeasible, and the custom changed to one of storing password equivalents created by hashing the plaintext password and storing the hash. When you logged in, the password you entered was hashed, and the hash compared to the stored password equivalent. If the computed hash matched the stored hash, you must know the password, and were permitted to login.
Using hashes, and storing these password equivalents worked well enough, until networking became popular. In the early days of networking, programmers simply extended the techniques used for local authentication to remote authentication. Protocols like TELNET and FTP simply send the user's name and password across the network to the remote server, which then uses the hashing algorithm and tries to match the result to the stored password equivalent. At this point, you can guess that there is a problem with this approach--what happens if someone sniffs (eavesdrops) and captures the username and the password as it traverses the network? While the answer to this is obvious (the password is no longer a secret for the eavesdropper), TELNET and FTP, as well as other protocols (POP and HTTP's Basic Authentication) still send passwords in the clear.
By 1994, hackers had written sniffers designed specifically to capture the passwords sent by the TELNET, FTP, and rlogin protocols, as well as software designed to hide the sniffers themselves. Hackers installed sniffers on ISP's networks, as this was both the logical place to collect the most passwords, and also (at the time) poorly secured sites as well. And progress has not stopped, with better sniffers and the technology used to hide them (rootkits and trojans) still improving all the time.
Some people were not content with the status quo, and developed
new methods for network authentication. The most common
technique, still used by Microsoft file sharing (and SAMBA)
is called challenge-response. This
techniques shuns the transmission of the password itself across
the network. Instead, the server transmits a challenge, which
the client operates upon, using some permutation of the user's
password, and then transmits a response to the server. The
server, also knowing the user's password or password equivalent,
can check to see if the remote user knows the correct password
password by performing the same operation the client completed.
The password, as well as any password equivalent, never traverses
the network.
Sounds great? While challenge-response does represent a big improvement over transmitting the plaintext passwords across the network, these techniques still leave a lot to be desired when it comes to security. An eavesdropper, instead of sniffing the plaintext passwords, instead sniffs the challenge and the response. While these data do not directly yield the password, an attacker can try either a dictionary or brute force approach by operating on the challenge until they compute a matching response. The l0pht's l0phtcrack tool (see Resources) includes both the network sniffer as well as a password guesser in one, easy-to-use package that works against common versions of Microsoft's challenge-response authentication.
Worse still, if an attacker can capture the password equivalents that are stored on a server (the SAM in the case of NT 4), these password equivalents can then be used to log into other servers, as long as the owners of these accounts are using the same passwords on the other servers (which is pretty much the rule).
A popular way to get around the password problem is not to use them. Instead, hardware devices, using encryption, produce one time passwords (OTP). The RSA SecurID card generates a new password every time interval, and the user authenticate by entering a PIN and the six digit number currently appearing on the card. CryptoCard instead requires that the user enter a challege to the card, which is encrypted, then typed in as the response. In both of these cases, even if the response is captured it cannot be replayed, nor used to guess the password. This technique can also be done (carefully) using software instead of hardware.
Hardware tokens that generate passwords appear to be a great idea, so why isn't everybody using them? The answer comes down to money. The tokens themselves don't cost that much (under $100US), but when you decide to give all 20,000 of your employees or students a token, well, that suddenly gets into serious money. Then there is the problem with lost tokens, the administration necessary to update the authentication server's database, and the authentication server itself also costs money and must be securely maintained. These reasons have prevented wider use of token-based authentication, even though it is much more secure than the use of passwords.
Smartcards can be used for authentication as well. You unlock your Smartcard by using a PIN, and it can then perform challenge-response using a secret that you could never remember like a 128 bit key, and which is also not subject to brute force attacks. But, again, special hardware is required (the Smartcards themselves, and the readers). Still, Smartcard techology is popular in many parts of the world outside of the US.
Biometrics provides yet another approach to authentication. Instead of providing something you know (the password), or something you have (a password from a token), you can use something about your body as a form of authentication. But this runs into some of the same issues as the hardware tokens--every terminal must be equipped with a device that can collect the biometric data. These collection devices can be cheap, and even easy-to-use (Siemens sells a biometric mouse), but biometrics still faces the money issue, as well as resistance from users.
Suppose there was a way to make passwords safer to use of networks? That is, instead of sending passwords, password equivalents, or responses, researchers developed methods for secure authentication that work securely even in the presence of eavesdroppers. Indeed, several different methods have been developed for doing just this.
Bellovin and Merritt developed the Encrypted Key Exchange, or EKE, which not only manages to authenticate a user to a server, as a by-product EKE also manages to securely communicate an encryption key. EKE has fostered a whole family of authentication protocols, each improving on the last. For example, EKE requires a shared secret for its exchange, and if this secret is lost, past sessions, even though encrypted, could be exposed. The shared secret itself is a password-equivalent, and thus can be used to impersonate a user if captured from the server.
In 1998, a new protocol was developed at Stanford University, partially in response to an incident involving sniffed passwords. Secure Remote Password (SRP) attempts to solve many of the problems related to the use of passwords. In SRP, passwords are not sent across the network. Instead, a salt, two random numbers, and two message digests are exchanged during authentication. How this mathematical marvel manages this feat is revealed in the RFC and related paper. Basicly, SRP relies on discrete exponentiation of large prime numbers, a computationally expensive operation, a technique also used by Diffie-Hellman exponential key exchange. While this operation is relatively slow (taking a noticeable fraction of a second), authentication to a server takes place relatively rarely. And a slow algorithm makes cracking passwords much more difficult if an attacker does capture the authentication information stored on the server.
SRP differs from EKE and its descendants other important ways. Instead of relying on a shared secret, neither the client nor the server stores a password or password equivalent. In SRP, the server stores a salt value and a verifier. The verifier functions like a public key in that it is mathematically related to the user's password. Because the server does not store a password equivalent (something that can be used to impersonate a user), SRP provides stronger security than EKE, as well as providing what is called forward security (later loss of the verification secret does not result in disclosure of previous encrypted sessions).
And, like the EKE family, SRP authentication results in secure key exchange. SRP is Open Source, and SRP-enabled TELNET and FTP software can be downloaded by US and Canadian residents for free. A Java implementation, written outside of the US, is also freely available.
Will SRP make passwords safe? While SRP fixes many of the problems with passwords, it still is not the ultimate solution. SRP works better than protocols like SSH when it comes to trojan servers. Hackers have written a trojan SSH (Secure Shell) server that collects the user's password during login. If someone writes an SRP trojan server, the server will not collect the user's password or password equivalent, making impersonation impossible using SRP.
But SRP is still vulnerable to trojan clients, and to client-side attacks such as keyboard sniffers. The widely-publicised incident last November, where Microsoft's internal networks were penetrated, involved a trojan on a Microsoft employee's home system that captured keystrokes, including the employee's password. The attacker then used the password to authenticate with a Microsoft PPTP server, and gained internal access. SRP could just as easily fall prey to keystroke capture.
SRP represents an improvement in password authentication. But for stronger security, tokens, Smartcards and biometrics are still the wave of the future.
The Internet standard for SRP (RFC2945): http://www.ietf.org/rfc/rfc2945.txt
Stanford student's analysis of SRP, with links to information about
other authentication protocols:
http://www-cs-students.stanford.edu/~tjw/srp/analysis.html
Another article comparing benefits of SRP: http://www.attrition.org/~wrlwnd/crypto/srp/telnet.html
An example, Open Source, implementation of SRP in Java: http://www.cryptix.org/products/jce/index.html
An example of a tool that can capture a challenge-response authentication protocol and efficiently guess the secret password using brute force: http://www.l0pht.com/l0phtcrack/
Information about biometrics: http://www.biometrics.org/ and
http://www.afb.org.uk/
[end]