A Variation on Digest Authentication for MUSIC/SP Web Server

Background

MUSIC/SP's httpd (web server) supports Basic authentication, which is ok but sends the password in clear text over the network (actually base64 encoding, which is equivalent to clear text) - obviously a security problem. There is a more secure scheme called Digest authentication - see RFC 2617 www.ietf.org/rfc/rfc2617.txt - that uses a random challenge from the server and MD5 or SHA1 digests. It's a bit complicated, involving several new HTTP header items, etc. I would like to support Digest auth in MUSIC's httpd at some point in the future.

Meanwhile, the following method can be used.

How it works

It's a variation on Digest authentication, but much simpler and easier to support at the server end. It requires a little more manual work by the human at the client end, using the md5pw program (see the Sim390 download page). Versions of the md5pw command are available for Windows and Unix/Linux. The idea is to still use the Basic authentication protocol (which almost all browsers and servers support), but use an implied challenge string.

The implied challenge string consists of the client's IP address and the current date and time (or a partial date and time). The password is added to the end of the challenge, and the MD5 digest of the resulting string is calculated, as 32 lower-case hex digits. The MD5 digest is sent in place of the actual password, in the browser's username/password dialog box. This is transparent to the browser.

The server, which knows the correct MUSIC/SP password, calculates its own MD5. If it matches the MD5 from the client, access is allowed. If not, it assumes the password is the actual password (not an MD5 digest) and checks it normally. The password itself is never sent over the network. If the MD5 is intercepted by an attacker, it would be very difficult to determine the password from it (assuming the password is not short and not a common word), even if the attacker knows the exact challenge. Since the MD5 includes the client's IP address, an attacker can't replay it from some other IP address. Also, including the date and time limits how far into the future the MD5 digest will be acceptable to the server.

The format of the implied challenge string is, in longest form:

n1.n2.n3.n4-yyyymmddhhmm

where n1.n2.n3.n4 is the client's IP address. The client can leave off up to 6 characters from the end of the date/time, to control how long the MD5 digest will be valid: from about 1 minute up to the remainder of the current month. The server tries each of the 7 possible challenges (based on the server's current date and time) and allows access if any of the resulting MD5 digests matches the MD5 from the client. (The server only has to do this if the password looks like an MD5 digest i.e. is 32 hex digits.)

An example

Say the current date/time at the server is 2006-02-03 10:30:15, the client's IP address is 132.206.25.10, and the password is mypass1. The client wants the authentication to be valid for the rest of this hour, so he/she uses challenge string 132.206.25.10-2006020310 and uses it in an md5pw command (in a local command window). The md5pw command prompts for the password and gives the MD5 digest of 206.25.10-2006020310mypass1 as e8510d9ac44044b80f9c0d66a09edf11. Here's what it looks like on Windows:

c:\data>md5pw 132.206.25.10-2006020310
Calculates MD5 digest of Challenge + password
Using challenge string: 132.206.25.10-2006020310
Enter password: *******
MD5 digest in hex: e8510d9ac44044b80f9c0d66a09edf11

The user enters the MD5 digest, by copy-and-paste, into the password field in the browser's username/password dialog box. The server does the same MD5 calculation, using each of the 7 variations of the challenge string:

132.206.25.10-200602031030
132.206.25.10-20060203103
132.206.25.10-2006020310
132.206.25.10-200602031
132.206.25.10-20060203
132.206.25.10-2006020
132.206.25.10-200602

The 3rd one matches, so access is allowed. The browser automatically sends the same MD5 for future HTTP requests, and it works until 11:00 i.e. until the hour changes, at which point authentication fails and the browser displays the username/password dialog box again.

Discussion

It's not quite as good as Digest auth, but almost as secure, and much better than plain Basic auth. Sure, it's vulnerable to a replay attack if an attacker can spoof the client IP address, but Digest auth also has that problem. Also, the user has the freedom to use it or not, depending on whether security is an issue. As always, the user should use a long password (at least 8 characters is recommended, 10 is better) which is not a common word, since an attacker who intercepts the MD5 digest can do rapid password guessing off-line, in a brute-force attempt to "crack" the password.

To make life easier for the user, and to help in cases where the user's IP address varies or is not known to the user, MUSIC/SP can provide a web page CGI program that echoes the client's IP address and displays the possible challenge strings (as ready-made md5pw commands) for the current date and time. You can try such a web page now at http://musicm.mcgill.ca/echoip. The underlying CGI program $tcp:echoip.rex is distributed, along with the new httpd, in the misc9.arc update to the MUSIC/SP Demo system. For instructions on how to set up the echoip CGI on your system, see the comments in $tcp:echoip.rex.

Notes:

To use this authentication scheme in MUSIC/SP's web server, you need to apply update misc9.arc to the 6.1 Demo system, or use version 6.2 of the Demo system.
Currently, it only works for authentication of system (Code Table) userids, not for userids in password files created by the HTPASSWD utility. This is because HTPASSWD files store the password in MD5 digest form -- the authentication scheme needs the actual password. This will be fixed in a later update, by allowing passwords to optionally be stored in plain-text form. (But the password file itself will still be encrypted.)

For more info about access control and authentication in MUSIC/SP's web server, see webaccess.htm. Some of the features described there do not work exactly as advertised in earlier versions of httpd, so you should apply the misc9.arc update (which fixes several minor problems) before experimenting on your Demo system, or use version 6.2 of the Demo system.

- Dave Edwards, Feb 4, 2006

Last updated Feb 9, 2006