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. 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." * 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 AFAIK either Cookies nor OpenID can be used because they are inherently meant for browsers. (WebDAV clients are not browsers most of the time). Thanks. - Asiri > > -- > Sergiu Dumitriu > http://purl.org/net/sergiu/ > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
