Sergiu Dumitriu wrote: > 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.
To clarify things a bit, the specification says that the nonce is generated whenever a 401 response is sent. This does not mean after every client request, but there are no strict rules for this. It could expire after a certain amount of time, or after a number of uses, or who knows. By default, Apache httpd is configured so that nonces expire after 5 minutes. Since we're making the server, we can decide our own strategy for this expiration, so we could make it behave like a session. > - 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
