24 Oct
2008
24 Oct
'08
1:50 p.m.
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
26 Oct
26 Oct
2:24 a.m.
On Fri, Oct 24, 2008 at 4:50 AM, Asiri Rathnayake <
asiri.rathnayake(a)gmail.com> wrote:
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].
FYI, a nonce isn't that weird (
http://en.wikipedia.org/wiki/Cryptographic_nonce )
Cryptographic nonce: In security
engineering<http://en.wikipedia.org/wiki/Security_engineering>ng>,
a *nonce* stands for *number used
once*[1]<http://en.wikipedia.org/wiki/Cryptographic_nonce#cite_note-0>…
is similar in spirit to a Nonce
word <http://en.wikipedia.org/wiki/Nonce_word>). It is often a
random<http://en.wikipedia.org/wiki/Randomness>or
pseudo-random <http://en.wikipedia.org/wiki/Pseudo-random> number issued in
an authentication
protocol<http://en.wikipedia.org/wiki/Authentication_protocol>to
ensure that old communications cannot be reused in
*replay attacks <http://en.wikipedia.org/wiki/Replay_attack>*. For instance,
nonces are used in HTTP <http://en.wikipedia.org/wiki/HTTP> digest access
authentication <http://en.wikipedia.org/wiki/Digest_access_authentication>to
calculate an
MD5
<http://en.wikipedia.org/wiki/MD5>password<http://en.wikipedia.org/wiki/Password>.
The nonces are different each time that the 401 authentication
challenge response
code <http://en.wikipedia.org/wiki/List_of_HTTP_status_codes> is presented,
and each client request has a unique sequence number, thus making replay
attacks and dictionary
attacks<http://en.wikipedia.org/wiki/Dictionary_attack>virtually
impossible.
*+ 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"
It appears that the presented password response is crypted by a one-time-pad
or session-key <http://en.wikipedia.org/wiki/Session_key>. One thought is a
quick hack: Have an external "login" mechanism outside of Xwiki accessible
over HTTPS:// which changes the password expected to be presented on Xwiki's
end to "RESPONSE=MD5(HA1,nonce,HA2)." In other words, each DAV session, you
need to call "davlogin" presenting the new session key. On successful
authentication, "davlogin" sets Xwiki's mysql db password for the given
user
to "RESPONSE=MD5(HA1,nonce,HA2)." Where "nonce" is the current DAV
session
key.
In other words, you sort of reach-around into the db and twiddle the Xwiki
password of the given user, so that you can directly present your
MD5password, transmit it in the clear (it's already encrypted), and
authenticate directly on that MD5password-string matching exactly -- a sort
of "one time password" version of a "one time pad." Xwiki then
authenticates
based on it's understanding of a password (in the clear), when actually the
password is the MD5password setup specifically for that session. (just
disable the "feature" for "Admin" :-) )
I'm sure there's some better way of doing, this...
Also has this situation changed and how does it affect your plans in the
microsoft world:
http://en.wikipedia.org/wiki/Digest_access_authentication#Browser_Implement…::
A 2002 analysis by eWeek Labs concluded that Internet
Explorer<http://en.wikipedia.org/wiki/Internet_Explorer>Version 5.0,
as well as later versions, implements digest authentication in
a way that does not comply with RFC 2617<http://tools.ietf.org/html/rfc2617>17>.
As a result, Internet Explorer cannot be used as a web client for a server
that complies with the digest authentication
standard.[1]<http://en.wikipedia.org/wiki/Digest_access_authentication#c…
Finally, is there any ways to reuse existing work. For example, in Struts
this appears relatively straightforward:
( http://www.ddj.com/security/184405885?pgno=1 )
Struts distribution includes a comprehensive JSP HTML tag library that
provides support for interacting with input forms. These tags let you define
HTML forms, checkboxes, input text fields, text areas, radio buttons, and
the like. From Listing One <http://www.ddj.com/security/184405885?pgno=1#l1>,
you can see that integration requires two things be done:
- Calling JavaScript library's *fsSignData* function in HTML form's
*onSubmit
*event.
- Defining a hidden variable to receive PKCS#7 digital signature.
HTML TagLib's *form* tag handles the rendering of HTML forms in the Struts
framework. I introduced a new tag called *signform* that extends the
functionality of the form tag to handle the just mentioned changes. For
this, I created a new Java Class called *SignFormTag* in the
org.apache.struts.taglib.html package that extends and overwrites some of
the methods of the class *FormTag*, which is also in the same package.
Methods *renderFormStartElement()* and *renderSignFormScript()* are
overwritten to call the *fsSignData* function on HTML form's
*onsubmit*event handler. Method
*doEndTag()* is overwritten to introduce the hidden variable that receives
the returned digital signature. Figure
3<http://www.ddj.com/showArticle.jhtml?documentID=ddj0411b&pgno=4>…
the UML class diagram.
This tag creates the hidden variable *<formname>_signature* into which the
digital signature is stored. For example, if the form name is *leaveform* as
defined in Listing One <http://www.ddj.com/security/184405885?pgno=1#l1>,
this tag introduces a hidden variable named *leaveform_signature,* which can
be accessed in the server-side script (Controller).
Further, the *SignForm* tag generates a JavaScript function
named*<formname_sign(form, sigHolder)>
*, where *formname* is the name of the form defined as part of the *
<html:signform>* tag. *form* and *sigHolder* are variables representing HTML
*form* and hidden variable to store a digital signature, respectively. It
also creates a suitable form *onsubmit* event handler that calls the *
formname_sign* function when users press the Submit button on *form*. Any *
onSubmit* function that is defined as part of the Struts framework will be
internally called by this new generated function. This is done behind the
scenes and Struts developers are completely oblivious from this. The only
modification that you have to do is to use the *<html:signform>* tag in
place of the *<html:form>* tag to design signed web forms. This greatly
simplifies the development effort required to create secure web form
applications. Listing Two
<http://www.ddj.com/security/184405885?pgno=1#l2>demonstrates the
aforementioned leave example in Listing
One <http://www.ddj.com/security/184405885?pgno=1#l1>, but is now using the
extended Struts framework.
--
Niels
http://nielsmayer.com
3:50 a.m.
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/
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
11:42 a.m.
Paul Libbrecht wrote:
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?
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
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?
>
5:11 p.m.
Hi Sergiu,
On Sun, Oct 26, 2008 at 4:12 PM, Sergiu Dumitriu <sergiu(a)xwiki.com> wrote:
Paul Libbrecht 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/WebD…
]
and sends this to the client. The client in turn uses this nonce value when
generating the RESPONSE hash in all following requests.
Thanks.
- Asiri
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?
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
6:37 p.m.
On Sun, Oct 26, 2008 at 9:11 AM, Asiri Rathnayake <
asiri.rathnayake(a)gmail.com> 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.…
... 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.
--
Niels
http://nielsmayer.com
]
and sends this to the client. The client
in turn uses this nonce value when
generating the RESPONSE hash in all following requests.
27 Oct
27 Oct
12:04 a.m.
Niels Mayer wrote:
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.
- 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/
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.
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/
28 Oct
28 Oct
1:59 a.m.
Sergiu --
I am in no way tied to my "hack" so no offense taken ... I just saw Asiri's
message of being "stuck" and I thought I'd mention a potential way of
getting un-stuck. The second approach I suggested as "non-hack" and
supersedes some of the limitations&stupidities of my first attempt. I was
just throwing out an idea, not trying to challenge the world :-)
However, since this would largely be a hack into the existing authentication
system, why not just "plug-in"
an authentication system that is more appropriate ... which brings me to the
following:
Is there any reason why you can't front Xwiki with Apache HTTPD running
http://httpd.apache.org/docs/2.2/mod/mod_auth_digest.html ?? Combine that
with what Ludovic suggested in
http://n2.nabble.com/Using-Apache-Basic-Authentication-API-credentials-and-…
specify a custom authentication in Xwiki via:
xwiki.authentication.authclass=com.xpn.xwiki.user.xwiki.impl.AppServerTrustedAuthServiceImpl
Then write your own AppServerTrustedAuthServiceImpl, which gets the
user-name (and potentially other credentials) from the mod_digest_auth
Apache plugin....
For example, with Apache talking to Java via mod_proxy_ajp setting
ProxyPass /davxwiki/ ajp://127.0.0.1:8009/xwiki/
setup mod_digest_auth to "protect" the web-accessible space 'davxwiki/'
via
digest-authentication. This allows a special digest-auth supporting xwiki at
URL http://.../davxwiki/... for use w/ DAV.
Here's a brief summary of mod_auth_digest:
This module implements HTTP Digest Authentication
(RFC2617<http://www.faqs.org/rfcs/rfc2617.html>)l>),
and provides a more secure alternative to
mod_auth_basic<http://httpd.apache.org/docs/2.2/mod/mod_auth_basic.html&…
.
Using Digest Authentication
Using MD5 Digest authentication is very simple. Simply set up authentication
normally, using AuthType Digest and
AuthDigestProvider<http://httpd.apache.org/docs/2.2/mod/mod_auth_digest.…
of the normal AuthType
Basic and
AuthBasicProvider<http://httpd.apache.org/docs/2.2/mod/mod_auth_basic.ht…er>.
Then add a
AuthDigestDomain<http://httpd.apache.org/docs/2.2/mod/mod_auth_digest.ht…
containing at least the root URI(s) for this protection space.
Appropriate user (text) files can be created using the
htdigest<http://httpd.apache.org/docs/2.2/programs/htdigest.html>toolt;tool.
Example:
<Location /private/>
AuthType Digest
AuthName "private area"
AuthDigestDomain /private/ http://mirror.my.dom/private2/
AuthDigestProvider file
AuthUserFile /web/auth/.digest_pw
Require valid-user
</Location>
....
Sergiu Dumitriu said:
- 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.
When i talk of "column" in the db .. I'm speaking generally and not of the
specific implementation. The basic operation of adding another table of
MD5passwords (session passwords) via the chosen abstraction mechanism
shouldn't be an issue.
- 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.
This wouldn't happen in the "non-hack" version I spoke of subsequently.
Unless a dav-login was used, xwiki would see the exact same code-path for
all operations. If a dav-login occurred, then authentication would occur
through the separare "table" of MD5passwords.
And certainly this wouldn't be needed w/ a mod_auth_digest-based
implementation suggested above.
- 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.
This wouldn't be needed with the "non-hack" version suggested by my second
email, nor with the mod_auth_digest-based implementation.
............
On Sun, Oct 26, 2008 at 5:22 PM, Sergiu Dumitriu <sergiu(a)xwiki.com> wrote:
Sergiu Dumitriu wrote:
reasons:
--
Niels
http://nielsmayer.com
Niels Mayer wrote:
> On Sun, Oct 26, 2008 at 9:11 AM, Asiri Rathnayake <
> asiri.rathnayake(a)gmail.com> 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.…
>>> ]
>> 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
- 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.
29 Oct
29 Oct
8:11 p.m.
Actually, my "hack" and "non-hack" suggestions appear to be
implementation
dependent, e.g.:
http://www.webreference.com/internet/apache/chap5/3/ (Apache: The Definitive
Guide, 3rd Edition):
A different nonce is sent the next time, so that the Bad Guy can't use the
captured digest to gain access.
It looks like the ability to send a nonce-repeatedly allows for a potential
replay-attack; this appears to be a "feature" of mod_auth_digest and
potentially exploited by tools like http://www.davexplorer.org , of which
Asiri noted:
As I observed with DAVExplorer, nonce is actually used
throughout a
session.
Upon login, the server generates a nonce value as bellow :
Regarding this, the Apache Definitive Guide says:
MD5 digest authentication is implemented in Apache, using mod_auth_digest,
for two reasons. First, it provides one of the two fully compliant reference
HTTP 1.1 implementations required for the standard to advance down the
standards track; second, it provides a test bed for browser implementations.
It should only be used for experimental purposes, particularly since it
makes no effort to check that the returned nonce is the same as the one it
chose in the first
place.[4]<http://www.webreference.com/internet/apache/chap5/3/#FOOTNOTE-…
*4.* It is unfortunate that the nonce must be returned as part of the
client's digest authentication header, but since HTTP is a stateless
protocol, there is little alternative. It is even more unfortunate that
Apache simply believes it! An obvious way to protect against this is to
include the time somewhere in the nonce and to refuse nonces older than some
threshold.
So anyways, this is a roundabout way of saying that both my "hack" and
"non-hack" versions using the nonce as a "session key" would be, um,
...
hacks. :-) But that can be seen by definition: because a nonce is a "number
used once" (per web request) and needs to change to prevent a replay-attack
of login information from a previously captured web-response.
Therefore, my last suggestion of using apache/mod_auth_digest (which is a
ref implementation of the spec) and a custom xwiki.authentication.authclass
still stands as the preferred approach
to get Digest Authentication working in Xwiki for the purpose of WebDAV
use/spec-compliance.
On Mon, Oct 27, 2008 at 5:59 PM, Niels Mayer <nielsmayer(a)gmail.com> wrote:
Sergiu --
I am in no way tied to my "hack" so no offense taken ... I just saw
Asiri's
message of being "stuck" and I thought I'd mention a potential way of
getting un-stuck. The second approach I suggested as "non-hack" and
supersedes some of the limitations&stupidities of my first attempt. I was
just throwing out an idea, not trying to challenge the world :-)
However, since this would largely be a hack into the existing
authentication system, why not just "plug-in"
an authentication system that is more appropriate ... which brings me to
the following:
Is there any reason why you can't front Xwiki with Apache HTTPD running
http://httpd.apache.org/docs/2.2/mod/mod_auth_digest.html ?? Combine that
with what Ludovic suggested in
http://n2.nabble.com/Using-Apache-Basic-Authentication-API-credentials-and-…
specify a custom authentication in Xwiki via:
xwiki.authentication.authclass=com.xpn.xwiki.user.xwiki.impl.AppServerTrustedAuthServiceImpl
Then write your own AppServerTrustedAuthServiceImpl, which gets the
user-name (and potentially other credentials) from the mod_digest_auth
Apache plugin....
For example, with Apache talking to Java via mod_proxy_ajp setting
ProxyPass /davxwiki/ ajp://127.0.0.1:8009/xwiki/
setup mod_digest_auth to "protect" the web-accessible space
'davxwiki/'
via digest-authentication. This allows a special digest-auth supporting
xwiki at URL http://.../davxwiki/... for use w/ DAV.
Here's a brief summary of mod_auth_digest:
This module implements HTTP Digest Authentication
(RFC2617<http://www.faqs.org/rfcs/rfc2617.html>)l>),
and provides a more secure alternative to
mod_auth_basic<http://httpd.apache.org/docs/2.2/mod/mod_auth_basic.html&…
.
Using Digest Authentication
Using MD5 Digest authentication is very simple. Simply set up
authentication normally, using AuthType Digest and
AuthDigestProvider<http://httpd.apache.org/docs/2.2/mod/mod_auth_digest.…
of the normal AuthType
Basic and
AuthBasicProvider<http://httpd.apache.org/docs/2.2/mod/mod_auth_basic.ht…er>.
Then add a
AuthDigestDomain<http://httpd.apache.org/docs/2.2/mod/mod_auth_digest.ht…
containing at least the root URI(s) for this protection space.
Appropriate user (text) files can be created using the
htdigest<http://httpd.apache.org/docs/2.2/programs/htdigest.html>toolt;tool.
Example:
<Location /private/>
AuthType Digest
AuthName "private area"
AuthDigestDomain /private/ http://mirror.my.dom/private2/
AuthDigestProvider file
AuthUserFile /web/auth/.digest_pw
Require valid-user
</Location>
....
Sergiu Dumitriu said:
--
Niels
http://nielsmayer.com
- 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.
When i talk of "column" in the db .. I'm speaking generally and not of the
specific implementation. The basic operation of adding another table of
MD5passwords (session passwords) via the chosen abstraction mechanism
shouldn't be an issue.
- 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.
This wouldn't happen in the "non-hack" version I spoke of subsequently.
Unless a dav-login was used, xwiki would see the exact same code-path for
all operations. If a dav-login occurred, then authentication would occur
through the separare "table" of MD5passwords.
And certainly this wouldn't be needed w/ a mod_auth_digest-based
implementation suggested above.
- 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.
This wouldn't be needed with the "non-hack" version suggested by my second
email, nor with the mod_auth_digest-based implementation.
............
On Sun, Oct 26, 2008 at 5:22 PM, Sergiu Dumitriu <sergiu(a)xwiki.com> wrote:
Sergiu Dumitriu wrote:
reasons:
--
Niels
http://nielsmayer.com
Niels Mayer wrote:
> On Sun, Oct 26, 2008 at 9:11 AM, Asiri Rathnayake <
> asiri.rathnayake(a)gmail.com> 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.…
>>> ]
>> 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
- 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.
26 Oct
26 Oct
5:03 p.m.
Hi Sergiu,
On Sun, Oct 26, 2008 at 8:20 AM, Sergiu Dumitriu <sergiu(a)xwiki.com> wrote:
Asiri Rathnayake wrote:
Well, [RFC2518 <http://www.ietf.org/rfc/rfc2518.txt>] clearly states that
all webdav servers 'MUST' support the digest authentication mechanism
(Section 17.1) :
*"Furthermore, a WebDAV server MUST NOT send Basic
authentication credentials in a WWW-Authenticate header unless the
connection is secure. Examples of secure connections include a
Transport Layer Security (TLS) connection employing a strong cipher
suite with mutual authentication of client and server, or a
connection over a network which is physically secure, for example, an
isolated network in a building with restricted access.
WebDAV applications MUST support the Digest authentication scheme
[RFC2069]. Since Digest authentication verifies that both parties to
a communication know a shared secret, a password, without having to
send that secret in the clear, Digest authentication avoids the
security problems inherent in Basic authentication while providing a
level of authentication which is useful in a wide range of scenarios."
*
Also, windows XP by default uses digest authentication and users need to
hack into their registries if they need their built-in webdav client to use
Basic Authentication instead.
There is no technical barrier for us to keep using Basic Authentication (con
: users have to do some tweaking). But it's less secure. Having said that,
even MD5 hashes are reportedly not *that* secure :
http://en.wikipedia.org/wiki/MD5
AFAIK either Cookies nor OpenID can be used because they are inherently
meant for browsers. (WebDAV clients are not browsers most of the time).
Thanks.
- Asiri
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
27 Oct
27 Oct
12:23 a.m.
Asiri Rathnayake wrote:
Hi Sergiu,
On Sun, Oct 26, 2008 at 8:20 AM, Sergiu Dumitriu <sergiu(a)xwiki.com> wrote:
Still, this does not say that Basic auth cannot be used over SSL. As
Ludovic said, we should require admins to configure HTTPS connections,
instead of hacking the platform to have Digest auth.
Asiri Rathnayake wrote:
Well, [RFC2518 <http://www.ietf.org/rfc/rfc2518.txt>] clearly states that
all webdav servers 'MUST' support the digest authentication mechanism
(Section 17.1) :
*"Furthermore, a WebDAV server MUST NOT send Basic
authentication credentials in a WWW-Authenticate header unless the
connection is secure. Examples of secure connections include a
Transport Layer Security (TLS) connection employing a strong cipher
suite with mutual authentication of client and server, or a
connection over a network which is physically secure, for example, an
isolated network in a building with restricted access. 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?
WebDAV applications MUST support the Digest
authentication scheme
[RFC2069]. Since Digest authentication verifies that both parties to
a communication know a shared secret, a password, without having to
send that secret in the clear, Digest authentication avoids the
security problems inherent in Basic authentication while providing a
level of authentication which is useful in a wide range of scenarios."
This does not mean that clients are forced to use Digest authentication.
Also, windows XP by default uses digest authentication
and users need to
hack into their registries if they need their built-in webdav client to use
Basic Authentication instead.
There is no technical barrier for us to keep using Basic Authentication (con
: users have to do some tweaking). But it's less secure. Having said that,
even MD5 hashes are reportedly not *that* secure :
http://en.wikipedia.org/wiki/MD5
That's why I chose SHA hashes for storing the passwords.
AFAIK either Cookies nor OpenID can be used because
they are inherently
meant for browsers. (WebDAV clients are not browsers most of the time).
No, they are meant for HTTP clients. Cookies can be used from
non-browser clients like wget and curl, so it's not impossible for some
WebDAV clients to know about cookies. Yet, this is not something we can
count on yet (unless we find out that most clients can use cookies,
which I doubt at the moment).
I wonder if LDAP could be an answer here...
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
5801
days inactive
5806
days old
13 comments
5 participants
participants (5)
-
Asiri Rathnayake -
Ludovic Dubost -
Niels Mayer -
Paul Libbrecht -
Sergiu Dumitriu