Re: [xwiki-devs] Digest Authentication & XWiki

Why can't this all be in the session? All this is session specific anyways. Or? I believe the nonce is very similar to the sessionId which is stored and exchanged up-and-down with every request just as the digest auth.

Le 26-oct.-08 à 03:50, Sergiu Dumitriu a écrit : > 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?