W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1995

Re: potential security holes in digest authorization

From: John Franks <john@math.nwu.edu>
Date: Fri, 14 Jul 1995 15:09:33 -0500 (CDT)
Message-Id: <199507142009.PAA01467@hopf.math.nwu.edu>
To: Dave Kristol <dmk@allegra.att.com>
Cc: bradb@geom.umn.edu, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
According to Dave Kristol:
> bradb@geom.umn.edu (Brad Barber) said:
>   > I'm glad to see that you are considering digest authorization 
>   > for HTTP.  I noticed a few security holes that may be of
>   > concern:
>   > 
>   > - the server's digest database of H(<username> : <realm> : <password>) should
>   > receive highest security.  To the knowledgeable user, it is the same as 
>   > storing passwords in the clear.  This is a weakness of the digest
>   > method.  The passwd file in UNIX that is used for "basic" authorization
>   > may be released without compromising strong passwords.
>   [...]
> I would like to propose that <password> be replace by H(<password>).
> The client would pass to the server
> 	H(<username> : <realm> : H(<password>))
> The server could store in its user/password file
> 	user-name:H(<password>)
> That way the password would neither be passed in the clear nor stored
> in the clear.

Under the current proposal what is stored in the server user/password
file is 
	user:H(<username> : <realm> : <password>)

So gaining illicit access to the server password file does not
compromise the password.  Of course, it *does* grant illicit access to
the documents on that server in that realm.  I believe this is what
Brad Barber was referring to when he said the password file needed to
receive highest security.

It is important that the server store what it does under this
proposal, because people tend to use the same password for multiple
purposes and this way the owner of the server password file does not
have access to the actual password.

Replacing the password with H(password) would simply make H(password)
the new password.

This is not intended to be the ultimate security system, just an major
improvement over basic authentication.

John Franks
Received on Friday, 14 July 1995 13:11:56 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:14 UTC