authentication

who is trying to access the resource?

authorization

is she allowed to access the resource in this way?

accounting

ensures she is billed for the access

auditing

institution-wide retrospective on resource usage

One can consider four methods by which one might authenticate a person:

• Something the person is, such as via biometric authentication
• Something the person has, such as a crypto token (e.g., smart card or java button)
• Something the person knows, such as a password
• Something the person can do, such as the ability to encrypt or decrypt a challenge dataset

Biometrics

There is also a more subtle problem with biometrics. The link between the biometric reader device and the workstation computer is vulnerable to eavesdropping and to injection attack. If an adversary can persuade a person to authenticate, even once, through a workstation that has been compromised in this way, that person's biometric pattern can be surreptitiouly recorded. At any later time the adversary can re-inject the pattern into the link and masquerade as that person. Human beings only have ten fingers and two irises. What can be done the second time one's iris biometric is compromised?

Attempts to add security to this link merely shift the vulnerability to the point between the actual biometric reader (such as the fingerprint scanner) and the link security electronics. It is difficult to imagine how a biometrics device might reliably be protected from determined tampering yet still allow a user's finger to be inserted.

This is an especially important consideration when workstations may not be fully trusted, such as mall kiosks or ATMs encountered during foreign travel.

Passwords

Ironically, all the authentication techniques other than biometrics are ultimately secured by the humble password. Smart cards can be stolen, so they are typically activated only with the use of a PIN number, which is itself nothing more than a (particularly weak) password. Even with strong PKI techniques, the private key, whether stored on the workstation or in a crypto token, is typically protected by symmetric encryption with a password, which the user must give to allow authentication.

Network Authentication - Then and Now

Clear text passwords were still present on the wire, but a compromise of the server would no longer yield an entire database of clear text passwords. Because the server required the clear text password on the wire, posession of the hashed value alone was insufficient to authenticate.

But exposure of the hashed value left the system vulnerable to brute force attack (trying every permutation of glyphs) and to dictionary attack (trying every word in a dictionary, in the hope the user had chosen a single, correctly spelled word as her password). Eventually a shadow-password system was inaugurated, in which the real password file is no longer visible to ordinary users.

Networked computer usage is no longer exclusively over enterprise networks. Users expect to be able to perform authorized tasks while using the commodity internet. In many cases the network simply cannot be trusted. Students in dorms share a broadcast ethernet, and eavesdropping on other user sessions is as easy as running a promiscuous listen program. Those connecting via cable modem and via wireless (802.11b WiFi) are currently protected by only very weak encryption systems. Injection attack, where packets that only seem to be from their purported sources can be forged, are also technically possible. In the worst case, a network connection can be hijacked (taken over by an adversary, leaving the original client disconnected) or a “man in the middle” attack can be mounted.

One solution to this problem is to encrypt the communications link. An eavesdropper sees only the encrypted traffic. Even a hijacked connection is not useful when the adversary cannot subvert the link encryption. Today when customers purchase over the web they freely send their (confidential) credit card numbers, but typically the link from client to server is encrypted by a protocol called SSL (Secure Server Link) and thus an eavesdropping adversary cannot capture the credit card number. SSL uses public-key technology, which will be described later.

Security systems such as Kerberos avoid sending clear text passwords over the link, by basing authentication on the ability to encrypt a challenge data set. The server generates a challenge that is guaranteed to be different from any other challenge ever issued (it typically includes a date and time, to prevent playback attack). The server sends this challenge to the client, which encrypts the challenge with the password given by the user, returning this encrypted result to the server. Authentication is granted only if the result, when decrypted with the password, regenerates the original challenge dataset. Alternatively, the server can independantly encrypt the challenge with the password, then compare the returned encrypted version with the locally generated one.

While this avoids the vulnerability of sending a password over the link, an independant copy of the password is still stored at the server. If the server itself is ever compromised, an adversary can capture a large number of passwords in one exploit, making the server itself a very tempting target.

Password hashing techniques like those described above give no additional protection in this setting, because it is the residue that would be passed on the wire, not the clear-text password as before. If posession of the residue is sufficient to authenticate, then effectively the residue becomes the password, and the situation is identical to that of the previous case where the server stores copies of all the passwords, in that compromise of the server password file gives an adversary all the information she needs to impersonate a valid user.

Public Key Techniques and PKI

Applying this to the client-server example, users can safely store their decryption keys on the server, because it is the encryption key that the adversary must steal in order to impersonate. Thus an attack on the server is just not useful.

The server generates a unique challenge dataset and sends it to the client, which uses the secret (private) encryption key to encrypt the challenge. The client then returns the encrypted version to the server, which uses the non-secret (public) decryption key to decrypt the result, and only grants authentication if the original challenge is regenerated.

Unfortunately, practical public key systems use keys that are too large for human beings to reliably remember. At the time of this writing (July 2001) 512-bit keys were considered weak, 1024-bit keys were the operational standard, and 2048 bit keys were being considered for high-security work. (For the purpose of comparison, a 2048 bit number would be roughly 614 digits when expressed in decimal.) Because it is just not feasable to expect a human being to reliably remember a multi-hundred-digit number (or even be able to reliably enter it in on a keyboard!), these schemes usually store the private key in symmetrically encrypted form, either on the workstation's hard disk or in a crypto token, and require a password or pass phrase to decrypt the private key for use.

Both these alternatives have their advantages and disadvantages. Storing the private key on the workstation requires a reliable backup for the workstation's disk storage, and additional support for propagation when the workstation is being upgraded. It also ties a worker to a specific workstation, making it difficult to work from an alternative location, such as at home or at a collaborative meeting site.

Storing the private key on a crypto token allows authentication from different work sites, but the crypto token can be lost, or accidently left at home, and there is significant expense both in the tokens themselves and in equipping every workstation with the associated token reader device. At the time of this writing smart cards could be bought for $10 per person and a typical USB smart card reader could be bought for $20 per workstation. These costs would probably preclude universal campus usage of crypto tokens.

Another technique is to use a keyserver. Typically the workstation makes a request to the keyserver, which returns a symmetrically encrypted copy of the private key. Some known transformation is used on the user's password to derive the symmetric key that allows decryption of the keyserver response. However, if an adversary can obtain an encrypted private key from the keyserver, she can conduct a brute force attack or a dictionary attack against it at her leisure. For this reason, many keyserver systems require a residue of the user's password to be supplied along with every keyserver request. It is vitally important that this residue be distinct from the password residue used to decrypt the keyserver response, as the keyserver must store the residue used to validate the request, but should not store the residue used to unlock the private key.

However, an adversary can still eavesdrop on the keyserver response from a valid authentication, so unless the user, the keyserver, and all network links between them are trusted, the keyserver scheme is still vulnerable to brute force and dictionary attack.

For more information visit http://www.oit.umd.edu/middleware/pki.html

Compromise of Workstation vs Compromise of Link

It would be possible to protect against the compromise of a workstation, by equipping a crypto token with a display unit and keyboard. The token would display the purpose for which authentication is desired (to protect against substitution attack) and the pass phrase would be typed directly into the crypto token, so a keyboard watcher on the compromised workstation could not see it. The challenge passed to the token and its response would be encrypted with public key techniques so the workstation could not profitably alter either message. Such a token would be considerably more expensive than a typical smart card, and if made too smart could itself be vulnerable to virus attack. The device would have to be just smart enough, and no smarter.

It is certainly not clear, however, that authenticating a user on a compromised workstation is a good idea, in the larger scheme of things. The workstation could subtly alter the work process in progress, or siphon off sensitive data to a lurking adversary. Compromise of the workstation is a threat that must be seriously considered.

Application Servers

Proxy Server

This method is somewhat more complicated than it first seems, because a web session consists of many separate connections, typically a different connection is made for each page element. The server must keep track of authenticated users, and allow their traffic (and only their traffic) to pass. It is not clear by what method a particular user can be disambiguated. While for single-user workstations the IP address may suffice, there are many ways more than one user can share a single IP address. Many SOHO (Small Office/Home Office) networks share a single IP address among many users via the technique of IP Masquerading, also called Network Address Translation (NAT). Even a mainframe running Lynx or a multi-user Citrix configuration may confuse an attempt to disambiguate “users” via IP address.

Single Redirect

Double Redirect with Cookie

If the required cookie is not present, the application server returns a response (2) redirecing the browser to the authentication server (3). After satisfying whatever authentication is required, the authentication server returns to the workstation both a valid cookie and a redirection back to the application server (4). When the browser accesses the application server a second time (5), the required cookie is present, so the application server allows access.

Of course, precautions must be taken to prevent the cookie from being forged. Either a symmetric key or an asymmetric key technique can be used for this purpose.

Because a cookie is required, and only the authentication server can create one, an adversary cannot simply bypass the authentication server. However, this method does require modifications to the application web servers, to require the cookie and to perform the appropriate redirection if it is not present.

Another unfortunate disadvantage is that some security-conscious users explicitly disable cookies and would thus be rejected by such a system.

Analysis

For low-security authentication the picture is less clear. Conventional challenge-response systems like Kerberos have a security vulnerability in that the authentication server contains a database of clear text passwords, so an exploit of that server yields a very tempting payoff. But there will be at most a small number of authentication servers (only enough for network reliability) and standard techniques can be used to harden them against attack.

Public Key systems do not store any private keys on the server, but unless a physical crypto token is present, the private keys must either be stored on the workstation's hard disk or be distributed via a keyserver. The vulnerability in both cases is that an adversary may secretly obtain the encrypted private key (by reading the workstation's backup tapes or eavesdropping on a keyserver response during a valid authentication) and then conduct a brute force or dictionary attack at her leisure, over a period of weeks or months.

Because the workstation is inexpensive hardware and not under the direct physical control of the security authority, hardening it against exposure of the encrypted private key is much more difficult.