Re: potential security holes in digest authorization

According to Brad Barber:
> 
> Re: the server's digest database is the same as storing passwords
> in the clear.
> 
> There's been some confusion about this.  Using the language of the draft specification,
> 
>         If I have <username> and H(A1), it is easy to generate 
> 
>         H( H(A1) + ':' + ...) and pretend to be <username>. 
> 
>         This is not true with Unix's passwd file since it stores f(passwd) 
>         where f() is a one-way function. 
> 

This is correct, but practical experience indicates that Unix's passwd
security (aka Basic authentication in HTTP) has a serious problem
because the password must be transmitted in the clear over the network.
Again digest authentication is not intended to be a strong or complete
security option.  One of its weaknesses is the server usr/password
file.   It is better than the Unix passwd scheme because generally
files on servers are more secure than internet traffic.

Digest authentication was designed with certain constraints.  Among
them were the requirements that there be (1) no potential patent restrictions
(2) no royalties and (3) no U.S. export restrictions.  It meets these 
requirements at a cost of weakened security.

> 
> I believe the problem is intrinsic to digest authentication.  The
> options that I see are:
> 
>         1) Encrypt the database.

Probably in conflict with (1), (2), and (3).

> 
>         2) Physically secure the authentication server and use a
>         minimal communications channel.  Encryption is not needed.
>         This should always be done if security is a concern.
> 

A good idea to the extent feasible.

>         3) Use end-to-end encryption and authentication as in SSL.
> 

Surely in conflict with (1), (2), and (3).


John Franks

Received on Friday, 14 July 1995 13:24:39 UTC