27 Oct
2008
27 Oct
'08
1:22 a.m.
Sergiu Dumitriu wrote:
Niels Mayer wrote:
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.
On Sun, Oct 26, 2008 at 9:11 AM, Asiri Rathnayake
<
asiri.rathnayake(a)gmail.com> wrote:
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. 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.…
... 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.
]
and sends this to the client. The client
in turn uses this nonce value when
generating the RESPONSE hash in all following requests.
- 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/