W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2002

FW: Digest auth the wrong solution?

From: Jim Whitehead <ejw@cse.ucsc.edu>
Date: Wed, 9 Oct 2002 17:04:10 -0700
To: "WebDAV" <w3c-dist-auth@w3.org>

Accidentally caught by the spam filter. I have added
<dstone@trinity.unimelb.edu.au> to the accept2 list.

- Jim

-----Original Message-----
From: Daniel Stone [mailto:dstone@trinity.unimelb.edu.au]
Sent: Wednesday, October 09, 2002 4:46 PM
To: w3c-dist-auth@w3.org
Subject: [Moderator Action] Digest auth the wrong solution?

Hi all,
I'm writing MoulDAVia, a Python-based WebDAV server. Basically, it has
interchangable backends for both authentication and retreiving/storing
files/properties; the end aim is to have the configurable per-location
(e.g. a shared area with no authentication and a home directory-based area
with LDAP auth, depending on path, etc).
Anyway, I've hit a bit of a snag trying to stay RFC-compliant: digest
As far as I can tell, there's no real way to do digest authentication,
without knowing the password server-side. For the LDAP backend, which will
be the default (the default mode of operation will be home directories
until I get the whole per-location thing sorted), authentication is
performed by attempting to bind to LDAP as the given user/password pair,
and seeing if that succeeds or not. At no stage does the server know the
*real* password, only what the client gives it.
Which, as far as I can tell, leaves me in a bit of a quandary trying to
implement digest authentication. Is there any real way to do this without
knowing the passwords server-side?
I'm beginning to think that requiring digest auth is the wrong solution,
and requiring a method of authentication stronger than base64 (e.g. digest
or SSL), would be better. SSL isn't an issue to provide, but digest - now
that's a snag. :)
Any ideas?

Daniel Stone                                <dstone@trinity.unimelb.edu.au>
Developer, Trinity College, University of Melbourne
Received on Wednesday, 9 October 2002 20:23:46 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:27 UTC