26 Oct
2008
26 Oct
'08
4:07 p.m.
The reason why we need Digest Authentication is that Windows by default
will refuse to do Basic Auth over HTTP for WebDAV requests.
There is as far as I know no way around it, except using HTTPS or double
clicking on a .reg file to allow basic authentication.
Anyway, our Authenticators will have no chance of being able to do
Digest since we don't have the password, so I don't think it's worth it
to kill ourselves for doing that, especially since this is not an issue
(I think) when using the direct MS Office webdav which is the one we
will most advertise using the "Edit" links in the Wiki.
I think the approach is:
1/ Suggest HTTPS to our users wanting to install WebDAV
2/ Put the .reg file that is necessary for users to have their Windows
perform basic auth in webdav, well available for users wanting to
perform WebDAV
3/ Document this clearly for admins
As I say, let's forget about Digest Auth and move on to more important
things.
Ludovic
Sergiu Dumitriu wrote:
Paul Libbrecht wrote:
--
Ludovic Dubost
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
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.
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?
>