What's wrong with authentication?

Note: to skip directly to the authentication spoofing demo, either scroll down or click here.

When the Clemson university firewall was first put up, I had no problem with it. Sure, I was a little frustrated with having to come up with other ways of getting things done than I was used to. This, however, is something that is inherent to the firewall system -- and with good reason.

When I first heard about authentication, though, that really got to me. Authentication is a nuisance, and should be done away with. Why? It is because it is insecure. Moreover, authentication as it stands cannot be secure, as there are problems inherent in its design.

Some background

According to Cisco, there are three parts to a good firewall system: authentication, authorization, and accounting. These are the three A's of security. To put it simply:

• Authentication - having to input a username and password to gain access to a service provided by the firewall.
• Authorization - having the proper rights associated with that username and password to access the service.
• Accounting - the process of logging specified events.

There is nothing really wrong with this system. It's a good system, and despite Cisco's efforts to advertise it as if this system is something unique to their products, it is a system that has been proven over the years to work.

Where the problem lies is in the attempt that the CU firewall has made to make authentication appear transparent to the user. The firewall's authentication policy is built on top of existing protocols. Because these protocols do not provide any existing policy for authenticating to a firewall, the authentication must be done in the same manner as the authentication as specified in the RFC for the protocol. In the case of telnet, this means that the authentication message appears as a login prompt. In the case of ftp, this means that the username and password combination is simply requested twice -- once by the firewall, and again by the system which the client is actually connecting to. In the case of http, authentication is done using http 1.0 basic authorization, which has already been shown to be insecure.

Here's a sample session for the telnet protocol:

I:\>telnet atrium.musc.edu
Looking up host: atrium.musc.edu...
Trying 128.23.203.29:23...
Connected to atrium.musc.edu.  Escape key is ALT-].

authentication to Clemson University network (use your Clemson USERID and PASSWORD)
Username: pbranna
Password:

It is easy to see how this could be spoofed: simply check to see if the host is one of Clemson's IP's; if it is, then ask for authentication. The user probably won't think twice about it.

The same thing can be done with http basic authorization. Since the protocol only asks for an AuthName, the server need only specify the exact same AuthName as the CU firewall, and the user will receive the same login prompt as if authenticating to the real firewall:

I have written a small server which will demonstrate this ability. All a user would need to do is write a similar utility, place an <img src=""> marker on his/her web page, and would then be able to easily collect passwords from other CU students.

WARNING

To see a demonstration of how authentication can be spoofed, simply click here, and enter a fake userid/password combination.

Update (4/12/2000): The link above has been taken down at DCIT's request.

No, I will not give out the source code to this program, until a solution to this problem has been found and implemented. I will not be an aid to benefit script kiddies.

Possible Solutions

There are a number of possible ways around this problem. I'm partial to (1), but would be satisfied with (2). I know there are probably some other options, but here are a few:

1. Get rid of authentication altogether. This would alleviate the security issue, but would leave the University in a bad position.
2. Use an authentication utility that does not require re-authentication and which uses a dedicated protocol, rather than being slapped on top of existing protocols, preferably one which encrypts the password rather than simply encoding it.
3. Use a different password for Internet authentication than for accessing other resources. This is not only an administration headache, but would confuse users and does not solve the problem.
4. Don't do anything at all. This would be bad.