Niels Mayer wrote: > On Sun, Oct 26, 2008 at 9:11 AM, Asiri Rathnayake < > [EMAIL PROTECTED]> wrote: > >> 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. >> > > ... Which is why you can have an external "HTTPS-accessible shadow-login > program" invoked once per DAV session, to change Xwiki's password to the > MD5Password computed from the nonce/session-key. In my previous email I > called this DAV login service "davlogin" (e.g. > https://.../davlogin?user=foo&md5pass=0x0123456789ABCDEF > ) > > Of course, this would have side-issues like making web-login to a user > account in Xwiki difficult since the password would be set to the last > session's Md5Password. I guess you could have another program "davlogout" to > restore the normal Xwiki password. And another table in the db to store the > regular password. > > Yes it's a hack. > > The next question is there a way to accomplish the exact same thing in code > to achieve the same goal, but without the hack. > > For example, by adding a new special parameter to any DAV-originated > request, to enable authentication based on a new MD5Password column in the > database. The MD5Password would be used for authentication for any requests > using the special-parameter (e.g. '?dav=true). Basically the same code used > currently that looks up the regular password in Xwiki, should have a switch > on if "?dav=true" to select lookup using the MD5Password column or the > regular password column. (a pretty simple and trivial/scopable change). > > Also needed, an external way of setting the user-associated entry in the new > MD5Password column to the password for the current DAV session. (akin to > https://.../davlogin mentioned above). > > This new MD5Password db column represents the MD5Passwords for all active > DAV sessions on a given wiki, while the rest of xwiki continues to work the > same with the old password mechanism, as long as you don't give the new > parameter ?dav=true. >
This is getting totally out of control. I'm against this for many reasons: - We're trying hard to abstract the storage mechanism. There is no database, no table, no column. Currently there is no password column, it is just an xwiki property like any other. And as I said before, anything stored in the wiki is retrievable. - Changing the user's password is not acceptable. This means that he cannot use both the webdav and the browser at the same time. And if he forgets to logout, he won't be able to access the wiki normally. - Disabling the feature for "Admin" is not good. There is nothing special about the Admin account, it is just a name we chose for a default account. It could be called anyway, what matters is the rights set in the wiki. There is nothing special in XWiki, everything is a document, and all documents are equal (except those with programming rights). We should not have special cases in our code. - This is not going to work anyway, since we still can't store HA1 and be able to read it back, and storing RESPONSE is not practicle, since it depends on the visited URL. What I'm saying is that the only thing that can be done with a hashed value is to obtain a cleartext value from the client, hash it and compare it with what is stored in the wiki. Without the full, unencrypted text, there's no way we can make use use of the stored value. And since RESPONSE depends on the visited URL (and in a more secure version on the whole request body), this makes impossible this external "login" service. - Although some implementations do use the same nonce for a full session, this is wrong. The specification clearly states that the nonce should be uniquely generated for each authentication request (see http://tools.ietf.org/html/rfc2617#page-9 ), and by its name NONCE means that it should be used only once. - The WebDAV component should be a component, and components don't have strong bounds to other components. So, making special cases for WebDAV is wrong. - And the most important reason for me is that this is ugly. The right code should be clean, simple and elegant, not a complete hack messing around all the platform, just so that we comply with the flawed Digest authentication mechanism. Requiring that the password is plainly available on the server is crazy. If any MS product fails because of this, then it is just another sign of their stupid vendor lock-in attempts, and I will not succumb to them. I don't mean to offend anybody, I'm just speaking from a technical point of view. -- Sergiu Dumitriu http://purl.org/net/sergiu/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
