26 Oct
2008
26 Oct
'08
8:44 a.m.
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.
paul
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs