RE: Digest Authentication

Sigh, this debate has been going on for eight years.

There are two potential points of vulnerability for a password, in storage
and in transit.

If you have a system that protects the password in storage and in transit
then it can be used as a public key system, therefore any system based on a
symetric key alone cannot provide protection in both cases.

The reason I first proposed Digest Authentication is that the vulnerabilty
of a password in transit is considerably greater than the vulnerability in
storage for practically any conceivable network application. The original
Moris analysis of the one way encryption scheme in UNIX considered only the
vulnerability of stored passwords because networking was not common at the
time.

The original Moris analysis is in any case hopelessly flawed, in the
original paper the proposal is made that read protecting the password file
in addition to encryption is a bad idea and should be dimissed as 'security
through obscurity'. It took several generations of password crackers before
the UNIX sysadmin world silently abandoned that particular piece of nonsense
and started using shaddow password files.

At the time the proposal was made public key encryption was encumbered by
the Diffie-Hellman and RSA patents, hence there was a need for a symetric
key scheme designed to protect the key in transit.

The second issue the digest authentication design attempts to address is
limiting the risks involved in sharing passwords between sites.

The Basic authentication scheme, even over SSL is vulnerable to practically
every scenario in which the Digest scheme is vulnerable in addition to many
in which the Digest scheme is secure. If the attacker is presumed to have
read access to a critical systen file such as the password file it is
unreasonable to assume that the attacker cannot gain write access to the web
server executable, or for that matter gain access to whatever security
sensitive resource that was meant to be protected.


Today a much better approach than Digest Authentication would be to use a
federated authentication system such as SAML being standardized in the OASIS
standards group.


		Phill

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault
> Sent: Tuesday, October 16, 2001 7:09 PM
> To: Dylan Barrell
> Cc: WebDAV
> Subject: RE: Digest Authentication
>
>
> I agree that storing A1 is little better than storing the
> password.  I just
> disagree with your nonce issue and conclusion.
>
> If you plan to support transport layer security, how do you
> intend to get
> the password from the client?  Using Basic auth within a TLS-secured
> communication can be very secure indeed.
>
> lisa
>
> > -----Original Message-----
> > From: Dylan Barrell [mailto:dbarrell@opentext.com]
> > Sent: Tuesday, October 16, 2001 2:44 PM
> > To: Lisa Dusseault
> > Cc: WebDAV
> > Subject: RE: Digest Authentication
> >
> >
> > Lisa,
> >
> > But the passwd is a portion of A1. So how is storing this
> different from
> > storing the password?
> >
> > I am saying that neither basic nor digest is good enough -
> and so there is
> > no added benefit of implementing digest when the real solution is
> > transport
> > layer security or some other authentication mechanism like kerberos.
> >
> > --Dylan
> >
> > > -----Original Message-----
> > > From: Lisa Dusseault [mailto:lisa@xythos.com]
> > > Sent: Tuesday, October 16, 2001 4:38 PM
> > > To: Dylan Barrell
> > > Cc: WebDAV
> > > Subject: RE: Digest Authentication
> > >
> > >
> > > Dylan,
> > >
> > > I'm not sure I understand your nonce issue. You do not
> need to store
> > > the password on disk in the clear. In order to compute
> (or verify) the
> > > the client's authenticator you need to have the value
> H(A1). For the
> > > MD5 authentication scheme A1 is:
> > >
> > > A1       = unq(username-value) ":" unq(realm-value) ":" passwd
> > >
> > > (see RFC 2617 S 3.2.2.2).
> > >
> > > This is a fixed value for any user so it can be stored on disk
> > > directly.
> > >
> > > There's no need to use a fixed nonce in order to use a fixed H(A1)
> > > since the nonce is not an input to A1.
> > >
> > > Perhaps what you're referring to here is that compromise of H(A1)
> > > on a given server allows the attacker to impersonate the user to
> > > that server. However, this is not the same as compromise of the
> > > password since it does not permit the attacker to impersonate the
> > > user to any other server, even if the user has used the
> same password
> > > on that user.
> > >
> > > Admittedly, this problem does not exist with basic auth. However,
> > > most people consider sniffing a more serious threat than password
> > > file theft, which is why DAV so strongly "encourages" digest.
> > >
> > > What threat model are you concerned with here?  Would you be
> > > implementing BASIC if you don't implement DIGEST, or is neither
> > > good enough?  What would be good enough?
> > >
> > > Lisa
> > >
> > > > -----Original Message-----
> > > > From: w3c-dist-auth-request@w3.org
> > > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Dylan Barrell
> > > > Sent: Tuesday, October 16, 2001 11:37 AM
> > > > To: Dirk-Willem van Gulik
> > > > Cc: WebDAV
> > > > Subject: RE: Digest Authentication
> > > >
> > > >
> > > > We did think of this solution, but that means that we
> always have
> > > > to use the
> > > > same nonce value and we end up getting no security improvement
> > > over basic
> > > > authentication - so the argument that it is more secure than
> > > > basic is bogus
> > > > if you do this.
> > > >
> > > > --Dylan
> > > >
> > > > > -----Original Message-----
> > > > > From: Dirk-Willem van Gulik [mailto:dirkx@webweaving.org]
> > > > > Sent: Tuesday, October 16, 2001 2:02 PM
> > > > > To: Dylan Barrell
> > > > > Cc: WebDAV
> > > > > Subject: Re: Digest Authentication
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Tue, 16 Oct 2001, Dylan Barrell wrote:
> > > > >
> > > > > > Digest Authentication requires that a server store its
> > > > > passwords in such a
> > > > > > way that they be available in clear text format.
> > > > >
> > > > > Actually though your implementation -could- store the password
> > > > on disk as
> > > > > plain text - most do not; and it is technically not
> > required. Some bad
> > > > > implementations do store it plain - but (for example)
> the apache web
> > > > > server stores the password as a hash (md5 or crypt) on the
> > > server side.
> > > > >
> > > > > See http://cvs.apache.org -> apache-1.3 ->
> > src/support/htpasswd.c and
> > > > > src/support/htdigest.c to get an idea of the code).
> > > > >
> > > > > So it is not a requirement - just an implementation choise.
> > > > >
> > > > > It is true that with normal basic auth the password goes over
> > > > the wire in
> > > > > the clear; but with digest auth this is not the case.
> > > > >
> > > > > Dw
>
>

Received on Wednesday, 17 October 2001 02:16:07 UTC