Hi Sergiu, On Sun, Oct 26, 2008 at 4:12 PM, Sergiu Dumitriu <[EMAIL PROTECTED]> wrote:
> Paul Libbrecht wrote: > > 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. > > > > Because the session is not always shared between the browser and the > WebDAV client. And to get it in the DAV session, you have to send the > password somehow. > > The nonce is not the same with the sessionID. nONCE means that it is > used once, for only one request. It should be different for the next > request. As I observed with DAVExplorer, nonce is actually used throughout a session. Upon login, the server generates a nonce value as bellow : nonce = MD5(client_ip,time_stamp,private_key); // source : [Adding Digest Access Authentication to a WebDAV Server<http://www.cs.columbia.edu/%7Ehgs/teaching/ais/1998/projects/WebDAV/report.html> ] and sends this to the client. The client in turn uses this nonce value when generating the RESPONSE hash in all following requests. Thanks. - Asiri > > > > > > > > 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? > > > -- > 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
