Competitive Analysis of SRP

The landscape of Internet security changes by the month, with new products being introduced constantly. These products can be evaluated by categorizing the technologies that they use to obtain their security properties. This document lists some of the more popular authentication products and analyzes how their security compares to strong password mechanisms like SRP and, in some cases, how SRP can be used to add password security to existing infrastructures.

Multifactor Authentication

The strongest forms of authentication involve the combination of more than one authentication factor: When combined properly, these techniques force an intruder to compromise several factors before being able to mount a meaningful attack.

Cryptographic smart cards - These are physical tokens that contain a CPU and enough memory to store private keys and perform cryptographic operations like digital signatures with them. They are usually PIN-protected and offer some form of hardware-based tamper-resistance, which is supposed to make them useless without the human-memorized PIN.

Under the right circumstances, they offer a high degree of security. They are also expensive to issue, require the installation of special card readers, and are difficult to deploy on a large scale, which has been an impediment to their adoption, especially in the United States.

Arcot authentication - Arcot Systems offers a software-based alternative to hardware authentication tokens that bypasses many of the limitations faced by smart cards while maintaining the security properties of a multifactor system. By using a technique known as cryptographic camouflage, Arcot can store tokens entirely in software and protect them from brute force attack, a problem that plagues other software-based solutions.

Strong Password Authentication

Although most strong password systems are single-factor systems, they can be combined with an additional factor, like a software or hardware token, to construct a multifactor system. What distinguishes strong password systems from other, weaker one-factor methods is the level of security that they leverage from that one factor. A strong password system protects even low-entropy ("guessable") passwords from off-line attack, even against adversaries with complete access to the network. They also exchange a session key to enable both data confidentiality and integrity after authentication has been confirmed.

SRP - Developed in 1997, SRP is a strong password authentication protocol that is now widespread among Open Source and commercial products. SRP does not expose passwords to either passive or active network intruders, and it stores passwords as a "non-plaintext-equivalent" one-way hash on the server. SRP is available as part of standard Telnet and FTP implementations, and is being rapidly incorporated into Internet protocols that require strong password authentication.

SRP is described in [Wu98]

EKE, SPEKE - EKE, or Encrypted Key Exchange, was developed by Bellovin & Merritt in 1992, and is one of the earliest examples of secure password technology. David Jablon invented SPEKE (Strong Password Exponential Key Exchange) in 1996, as well as a variable-modulus variant of SPEKE while some people also refer to as PDM. Both EKE and SPEKE passwords that are "plaintext-equivalent" to the real password, which means that an intruder who breaks into a server protected by EKE or SPEKE and captures the password database would subsequently be able to impersonate all the users on the system. EKE and SPEKE have variants that guard against this attack, but only with a significant performance loss.

EKE is described in [BM92].
SPEKE is described in [Jab96]. SPEKE is licensed by Entrust for use in their TruePass product.

AMP, SNAPI, AuthA, OKE, etc. - The current groundswell of interest in password authentication technology has spurred a large number of proposals for new authentication protocols, all offering different combinations of security, performance, and license availability. Standards bodies like the IEEE P1363 working group have formed entire study groups to help sort out the veritable alphabet soup that has resulted.

AMP is described in [Kwon00]
SNAPI is described in [MS99]
AuthA is described in [BR00]
OKE is described in [Lu97]

Pseudo-Strong Authentication

This category of methods is called "pseudo-strong" because while they are better than plaintext passwords, they have also have some well-known security problems that make them vulnerable in real-world deployments. Another distinguishing characteristic of these methods is that they inhabit the "no-man's land" of the technology quadrant: There are methods out there that offer better security while being equally easy to use, and there are also methods out there that are equally strong yet easier to use. It should therefore come as no surprise that SRP-based variants of these methods are quickly coming to market, since they preserve the ease-of-use that makes products based on these methods easy to deploy and use, while offering better security against well-known attacks.

SSH Public Key Authentication - SSH, or "Secure Shell", is a protocol that uses various key exchange methods to encrypt session traffic for remote logins and TCP/IP port forwarding. Although it uses well-known algorithms to perform both session key establishment and session encryption, its security is heavily dependent on the security of the method used to authenticate the user. In many cases, the user authentication method is the weak link in the chain.

To use SSH Public Key Authentication, a user must generate a public and private key, keep the private key on his client, and install the public key on the server. The server can later verify the user's possession of his private key for authentication purposes. Unfortunately, most users of this method store this private key at the client, protected only with a memorized passphrase. This enables an attacker who captures the encrypted private key to perform a dictionary attack, recover the private key, and impersonate the user. This problem is magnified when multiple users share a single client, like a UNIX or Linux server, or place their home directories on a common fileserver, and is further compounded in situations where regular backups are made, such as in most business and academic environments. A single successful penetration can result in the compromise of a significant percentage of a user community if they are required to use this form of authentication.

SSH Public Key Authentication is similar to Client-side SSL Certificate Authentication, as it shares the same vulnerability to a stolen-credential attack, and it also has the same difficulties in coping with roaming users, who frequently must log in from different locations. Some implementations of SSH allow the private key to be stored in hardware, which improves security in exchange for more deployment obstacles.

SSH Password Authentication - Nearly all implementations of SSH support what is known as "Password Authentication", in which the client sends its password directly to the server, hoping that the encrypted connection will protect it in transit. The security of this method is highly dependent on the particular method of server authentication being used. Keep in mind that an attacker who successfully bypasses server authentication in this case gets the plaintext passwords of any users who subsequently attempts to log in, and can do so undetectably.

One commonly-used method of server authentication is "ad-hoc" distribution of server public keys. The server sends the client its (non-certified) public host key, and the client uses this to encrypt a session key and send it to the server. The actual protocol is slightly more complicated, but what matters is that the client has no way of knowing if the host public key it received was in fact the right one, which makes this protocol susceptible to Man In The Middle (MITM) attacks in practice. Although the client tries to keep track of previously-received host keys, there is no way for it to know if a change in host keys is legitimate or the beginning of an attack, so users will in most cases either ignore the warning that SSH spits out or inundate the help desk (if there is one) every time a host key expires or the network configuration changes for any reason.

Some versions of SSH support PKI-based distribution of host keys, which improves the security of server authentication, but then requires the deployment of a PKI. Sites must then purchase server certificates from third parties like VeriSign or Thawte, or they must install and administer their own certification authorities. In any case, strengthening server authentication doesn't address the real problem with password authentication, which is that the user's password is being sent out in a reversibly-encrypted form.

Keep in mind that the problems with SSH mentioned above apply specifically to the authentication methods discussed above, and not to the product or protocol as a whole, which offers a number of useful features. SRP authentication is already available as an authentication method in OpenSSH and LSH, both of which are Open Source implementations of SSH. Since SRP leaks no information about the password, it does not depend on the strength of the underlying server authentication. A site that uses SRP authentication with SSH can use ad-hoc public-key distribution, which has none of the costs associated with a PKI, while enjoying protection against both passive and active (MITM) attacks, since the SRP exchange also performs an integrity-check of the SSH server's host key.

Password-protected Client-side SSL/TLS Certificates - To initiate a conventional, server-authenticated SSL connection, a Web server provides a certificate from a well-known CA (Certificate Authority), which the Web browser can verify. SSL also provides a mode in which the client can send a certificate to the Web server, which can verify it and use its contents to authenticate the client. The corresponding private key, which resides on the user's PC, is protected with a passphrase. An attacker who captures this encrypted private key can brute-force the passphrase to obtain the private key and impersonate the user, which is the same problem that affects SSH Public Key Authentication. Likewise, it is possible to store these private keys in hardware tokens, which trades off security for convenience.

As is the case for SSH, SRP authentication is being added to SSL/TLS in the form of SRP ciphersuites. When implementations of this protocol become available, they will offer a more secure SSL-based alternative to password-protected client-side certificates, without incurring any convenience or deployment penalties.

Default Preauthentication in Kerberos V5 - To fix the password security weaknesses in Kerberos V4, version 5 added preauthentication, which forces a client to prove knowledge of his password before the server starts an authentication session. The default form of preauthentication Kerberos V5 is an encrypted timestamp: The user converts his password into an encryption key, which the encrypts a binary representation of the current time. If the server is able to decrypt the client's message and obtain a timestamp within a given window, authentication proceeds. Unfortunately, an attacker who intercepts this message can perform an off-line brute-force attack against this message and obtain the user's password.

Since Kerberos V5 allows for different authentication methods to be plugged in, proposals for strong password mechanisms such as SRP have been advanced. As is the case with SSH, the addition of strong password technology would improve the security and viability of the underlying Kerberos V5 infrastructure while maintaining its password-based ease of use.

Weak Authentication

Although it would be nice to be able to say that weak authentication methods are mentioned here for historical interest, the truth is that an embarrassingly large amount of Internet traffic is secured with these legacy technologies. In some cases, there is a legitimate reason for making these choices - a common reason is that the authentication must work without installing additional client software.

Unfortunately, users of these systems ultimately sacrifice security for the convenience of backward-compatibility. If it is necessary to settle for the lowest common denominator to satisfy all users, then it is in all users' best interests to raise that lowest common denominator to support a level of security that includes strong password authentication. The "worst offenders", in no particular order:

Back