This system is still being used to this day, primarily for UNIX systems. Although the 56-bit DES cipher on which it is based is starting to show signs of age, the most glaring problem with this system in a networked environment is that it does not address the issue of how to transmit the password securely to the server for verification. Indeed, the vast majority of implementations today still send the password completely in the clear.
Unfortunately, challenge-response systems as a whole suffer from deficiencies that make them insecure for modern networked applications. The issues page discusses three major problems with these systems and gives some examples of how they have been and will continue to be exploited. There are a number of such protocols used in active systems today, and nearly all of them suffer from the insecurities described on the issues page.
EKE is discussed in [BM92].
Likewise, SPEKE is based on Diffie-Hellman, but the password is now used to influence the selection of the generator parameter in the session-key generation function. Technical details on all these protocols can be found at the Integrity Science Web site. These protocols have been subjected to some analysis, which indicates that they resist dictionary attacks and provide forward secrecy. However, the EKE family does not address the problem of plaintext- equivalence of passwords. They operate on the assumption that the server knows the same password as the client.
DH-EKE and SPEKE are described in [Jablon96].
A-EKE is proposed in [BM94]. A vulnerability in A-EKE is covered in [STW95].
The security advantages of one-time passwords is clear: An intercepted password is useless to an attacker. The inconvenience of one-time passwords is equally clear: Users need to manage either a list of passwords or client software that computes the one-time passwords on the fly. And then there is the problem of regenerating a list of passwords every time the user runs out.
Kerberos requires a great deal of administrative overhead, and it changes the fundamental authentication model for users, sacrificing some transparency in the process. It also does not handle authentication very well when the user and host are in different administrative domains. Kerberos is suited mostly for centrally-managed clustered networks, where the same authentication service is needed for all users. It is not well-suited for smaller clusters or standalone systems, where the overhead of a separate, secure authentication server is unacceptable.
In 1989, the Kerberos 4 TGT protocol was broken and a dictionary
attack found against it by Bellovin and Merritt; see
[BM89] for details.
In a sense, this places Kerberos in the uncomfortable position
of being both inconvenient and weak.
Kerberos V5, however, addresses this problem nicely by allowing
for preauthentication methods like SRP, which eliminate the
threat of dictionary attack.
Recently, a new product called
has made the rounds of the security community.
Ssh is basically an implementation of RSA written by non-US citizens,
so the version distributed from Finland escapes US export restrictions.
It offers host-based security and session encryption based on
host-generated RSA keys.
It is designed to replace the Berkeley 'r' commands like
rsh that use a system of trusted hosts.
Unlike Kerberos, ssh does not require a centralized authentication server to operate. Like Kerberos, however, ssh requires that users and administrators learn new sets of commands and new key management techniques to keep systems secure. To negotiate a partially secure file transfer, for example, a user must remember to do:
$ ssh -L 1234:remote-server.stanford.edu:21 remote-server (in a different window) $ ftp myhost 1234instead of the customary
$ ftp remote-serverAlthough ssh also provides the
scpcommand for copying files between systems, it does not provide the same functionality as full-blown FTP. Nevertheless, the SRP distribution will be adding an
scp-style authenticated file copy command.
Ssh consists of a large amount of code, most of which runs either as root or set-uid root. This makes auditing and verification of code difficult and time- consuming. SRP, by contrast, uses a non-setuid client, and the server code is a small patch to existing daemons. By emphasizing design simplicity, SRP minimizes the potential damage that bugs can cause, and programs can be tested more easily for conformance to specifications.
The final "issue" with ssh, though, is that it runs afoul of export regulations and RSA patent issues once inside the US. While it is legal for a US citizen to download ssh, he could not write his own SSH-enabled application and re-export it from a Web site. In addition, a commercial user would require a BSAFE license from RSA. To be fair, export regulations also prevent the exportation of SRP with strong encryption. However, SRP can perform secure authentication without the benefit of any encryption, while SSH needs encryption to protect the cleartext passwords over the network. This was, in fact, one of the original design parameters of SRP; it was intended to offer as much security as possible in a configuration that coexisted with export regulations.
In equation form:
(SRP Telnet/FTP) - (strong encryption) = protected password + clear session
(SSH/SCP) - (strong encryption) = cleartext password + clear session = rlogin/rcp
It is somewhat disturbing to note that while the overall issue of system security is beginning to attract an increased amount of attention, most existing systems still do not employ strong forms of authentication. Since strong authentication had not been invented when the Telnet protocol and other remote access standards were being decided, the world was saddled with a huge installed base of weak authentication mechanisms and all the security problems associated with them. Only the truly security-conscious users and administrators have so far taken it upon themselves to install one of the forms of "inconvenient but safe" authentication mechanisms in the form of add-on software. It is hoped that authentication systems like SRP will be able to bring true security to a greater number of users and move beyond the obsolete protocols of the past.