Asiri Rathnayake wrote: > Hi Sergiu, > > On Sun, Oct 26, 2008 at 8:20 AM, Sergiu Dumitriu <[EMAIL PROTECTED]> wrote: > >> Asiri Rathnayake wrote: >>> Hi Devs, >>> >>> I have hit a wall trying to implement Digest Access Authentication for >> the >>> xwiki-webdav module. I'll try to be clear as much as possible. >>> >>> *+ INTRO* : Digest Access Authentication is used to avoid the >> transmission >>> of clear text passwords over http for authenticating users. Instead of >> the >>> clear text password, following hash (RESPONSE) will be transferred to the >>> server by client, >>> >>> HA1 = MD5(username,password,realm) >>> HA2 = MD5(method,digestURI) >>> RESPONSE = MD5(HA1,nonce,HA2) >>> >>> Here the 'nonce' is some weird string token generated by the server for >> that >>> particular client for a particular session. So the RESPONSE instead of >> the >>> clear text password will be transferred to the server. For more specific >>> information about Digest Authentication, you may refer [1]. >>> >>> *+ PROBLEM* : Simply put, the way xwiki handles authentication requires >> the >>> presentation of a clear text password by the client (which is not >> available >>> with Digest Authentication scheme). What we have with xwiki (on the >> server >>> side) is a crypted version of the original password. >>> >>> One possible solution to overcome this limitation is to store the HA1 >> value >>> in our databases (is this possible ?). This is one of the limitations of >>> Digest Authentication scheme as mentioned in [1] : >>> >>> *"There is an important problem with implementing Digest access >>> authentication. This is the requirement that either cleartext passwords >> or >>> the HA1 hashes must be known in order to perform client response >> validation" >>> * >>> >>> I would like to know what other developers have to say about this issue, >> and >>> possible workarounds ... [?] >>> >>> Thanks. >>> >>> - Asiri >>> >>> [1] http://en.wikipedia.org/wiki/Digest_access_authentication >> Hi devs, >> >> This is a serious roadblock, and it cannot be easily solved. >> >> The main idea is that whatever data we keep in the database of the wiki, >> it is accessible. Storing HA1 is as safe as storing a plaintext >> password. Anybody with edit access and a bit of cracking/hacking >> experience can get it out of the wiki. So I'm a strong -1 against >> storing any unencrypted login information. >> >> I can't see any simple and clean mechanism to work around this problem. >> There's no way we can validate the correct password. Some hacks we could >> use in the worst case are: >> >> 1. Something like Niels suggested, authenticate in a third service over >> SSL and use a generated token as the password. This is cumbersome for >> many reasons, like: this token should expire often, for security >> reasons; the need for a certificate + HTTPS configuration; adding a new >> service; increased complexity; and many others. >> >> 2. Something similar to what is done for the current password. I don't >> go into further details now since I'm sleepy, and it's too ugly to be >> taken into account seriously. >> >> 3. Use Basic auth, but force https to be used. This means that we must >> document (or link to external documentation) how to setup https on >> various containers. >> >> 4. Find the time to implement crypt password storing mechanism. This >> means that the password can also be decrypted, unlike the current hash >> mechanism. This involves more effort, and is less secure than what we >> have now (I'd like that the user's password can never be retrieved, not >> even by the wiki and server owner). >> >> 5. Try to find other ways to authenticate. >> >> >> I always try to approach the problem from a different angle, since many >> times a difficult technical question is actually the dead end of a wrong >> solution to a different problem. So, why do you need to implement Digest >> authentication? What is your scenario? What is the goal? Do you have a >> link to the WebDAV authentication specification? Can we use cookies >> instead? Can we use OpenID authentication? >> > > Well, [RFC2518 <http://www.ietf.org/rfc/rfc2518.txt>] clearly states that > all webdav servers 'MUST' support the digest authentication mechanism > (Section 17.1) : > > *"Furthermore, a WebDAV server MUST NOT send Basic > authentication credentials in a WWW-Authenticate header unless the > connection is secure. Examples of secure connections include a > Transport Layer Security (TLS) connection employing a strong cipher > suite with mutual authentication of client and server, or a > connection over a network which is physically secure, for example, an > isolated network in a building with restricted access.
Still, this does not say that Basic auth cannot be used over SSL. As Ludovic said, we should require admins to configure HTTPS connections, instead of hacking the platform to have Digest auth. > WebDAV applications MUST support the Digest authentication scheme > [RFC2069]. Since Digest authentication verifies that both parties to > a communication know a shared secret, a password, without having to > send that secret in the clear, Digest authentication avoids the > security problems inherent in Basic authentication while providing a > level of authentication which is useful in a wide range of scenarios." This does not mean that clients are forced to use Digest authentication. > Also, windows XP by default uses digest authentication and users need to > hack into their registries if they need their built-in webdav client to use > Basic Authentication instead. > > There is no technical barrier for us to keep using Basic Authentication (con > : users have to do some tweaking). But it's less secure. Having said that, > even MD5 hashes are reportedly not *that* secure : > http://en.wikipedia.org/wiki/MD5 That's why I chose SHA hashes for storing the passwords. > AFAIK either Cookies nor OpenID can be used because they are inherently > meant for browsers. (WebDAV clients are not browsers most of the time). No, they are meant for HTTP clients. Cookies can be used from non-browser clients like wget and curl, so it's not impossible for some WebDAV clients to know about cookies. Yet, this is not something we can count on yet (unless we find out that most clients can use cookies, which I doubt at the moment). I wonder if LDAP could be an answer here... -- Sergiu Dumitriu http://purl.org/net/sergiu/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
