[xwiki-devs] Digest Authentication & XWiki
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
On Fri, Oct 24, 2008 at 4:50 AM, Asiri Rathnayake < [email protected]> 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>, a *nonce* stands for *number used once*[1]<http://en.wikipedia.org/wiki/Cryptographic_nonce#cite_note-0>(it 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_Implementa...:: 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>. 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#cite_note-eweek-0> 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>depicts 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
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/
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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
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/
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:
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?
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
Hi Sergiu, On Sun, Oct 26, 2008 at 4:12 PM, Sergiu Dumitriu <[email protected]> wrote:
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.
As I observed with DAVExplorer, nonce is actually used throughout a session. Upon login, the server generates a nonce value as bellow : nonce = MD5(client_ip,time_stamp,private_key); // source : [Adding Digest Access Authentication to a WebDAV Server<http://www.cs.columbia.edu/%7Ehgs/teaching/ais/1998/projects/WebDAV/report.html> ] and sends this to the client. The client in turn uses this nonce value when generating the RESPONSE hash in all following requests. Thanks. - Asiri
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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Sun, Oct 26, 2008 at 9:11 AM, Asiri Rathnayake < [email protected]> wrote:
As I observed with DAVExplorer, nonce is actually used throughout a session. Upon login, the server generates a nonce value as bellow : nonce = MD5(client_ip,time_stamp,private_key); // source : [Adding Digest Access Authentication to a WebDAV Server< http://www.cs.columbia.edu/%7Ehgs/teaching/ais/1998/projects/WebDAV/report.h...
] 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. -- Niels http://nielsmayer.com
Niels Mayer wrote:
On Sun, Oct 26, 2008 at 9:11 AM, Asiri Rathnayake < [email protected]> wrote:
As I observed with DAVExplorer, nonce is actually used throughout a session. Upon login, the server generates a nonce value as bellow : nonce = MD5(client_ip,time_stamp,private_key); // source : [Adding Digest Access Authentication to a WebDAV Server< http://www.cs.columbia.edu/%7Ehgs/teaching/ais/1998/projects/WebDAV/report.h...
] and sends this to the client. The client in turn uses this nonce value when generating the RESPONSE hash in all following requests.
... Which is why you can have an external "HTTPS-accessible shadow-login program" invoked once per DAV session, to change Xwiki's password to the MD5Password computed from the nonce/session-key. In my previous email I called this DAV login service "davlogin" (e.g. https://.../davlogin?user=foo&md5pass=0x0123456789ABCDEF )
Of course, this would have side-issues like making web-login to a user account in Xwiki difficult since the password would be set to the last session's Md5Password. I guess you could have another program "davlogout" to restore the normal Xwiki password. And another table in the db to store the regular password.
Yes it's a hack.
The next question is there a way to accomplish the exact same thing in code to achieve the same goal, but without the hack.
For example, by adding a new special parameter to any DAV-originated request, to enable authentication based on a new MD5Password column in the database. The MD5Password would be used for authentication for any requests using the special-parameter (e.g. '?dav=true). Basically the same code used currently that looks up the regular password in Xwiki, should have a switch on if "?dav=true" to select lookup using the MD5Password column or the regular password column. (a pretty simple and trivial/scopable change).
Also needed, an external way of setting the user-associated entry in the new MD5Password column to the password for the current DAV session. (akin to https://.../davlogin mentioned above).
This new MD5Password db column represents the MD5Passwords for all active DAV sessions on a given wiki, while the rest of xwiki continues to work the same with the old password mechanism, as long as you don't give the new parameter ?dav=true.
This is getting totally out of control. I'm against this for many reasons: - We're trying hard to abstract the storage mechanism. There is no database, no table, no column. Currently there is no password column, it is just an xwiki property like any other. And as I said before, anything stored in the wiki is retrievable. - Changing the user's password is not acceptable. This means that he cannot use both the webdav and the browser at the same time. And if he forgets to logout, he won't be able to access the wiki normally. - Disabling the feature for "Admin" is not good. There is nothing special about the Admin account, it is just a name we chose for a default account. It could be called anyway, what matters is the rights set in the wiki. There is nothing special in XWiki, everything is a document, and all documents are equal (except those with programming rights). We should not have special cases in our code. - This is not going to work anyway, since we still can't store HA1 and be able to read it back, and storing RESPONSE is not practicle, since it depends on the visited URL. What I'm saying is that the only thing that can be done with a hashed value is to obtain a cleartext value from the client, hash it and compare it with what is stored in the wiki. Without the full, unencrypted text, there's no way we can make use use of the stored value. And since RESPONSE depends on the visited URL (and in a more secure version on the whole request body), this makes impossible this external "login" service. - Although some implementations do use the same nonce for a full session, this is wrong. The specification clearly states that the nonce should be uniquely generated for each authentication request (see http://tools.ietf.org/html/rfc2617#page-9 ), and by its name NONCE means that it should be used only once. - 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/
Sergiu Dumitriu wrote:
Niels Mayer wrote:
On Sun, Oct 26, 2008 at 9:11 AM, Asiri Rathnayake < [email protected]> wrote:
As I observed with DAVExplorer, nonce is actually used throughout a session. Upon login, the server generates a nonce value as bellow : nonce = MD5(client_ip,time_stamp,private_key); // source : [Adding Digest Access Authentication to a WebDAV Server< http://www.cs.columbia.edu/%7Ehgs/teaching/ais/1998/projects/WebDAV/report.h...
] and sends this to the client. The client in turn uses this nonce value when generating the RESPONSE hash in all following requests.
... Which is why you can have an external "HTTPS-accessible shadow-login program" invoked once per DAV session, to change Xwiki's password to the MD5Password computed from the nonce/session-key. In my previous email I called this DAV login service "davlogin" (e.g. https://.../davlogin?user=foo&md5pass=0x0123456789ABCDEF )
Of course, this would have side-issues like making web-login to a user account in Xwiki difficult since the password would be set to the last session's Md5Password. I guess you could have another program "davlogout" to restore the normal Xwiki password. And another table in the db to store the regular password.
Yes it's a hack.
The next question is there a way to accomplish the exact same thing in code to achieve the same goal, but without the hack.
For example, by adding a new special parameter to any DAV-originated request, to enable authentication based on a new MD5Password column in the database. The MD5Password would be used for authentication for any requests using the special-parameter (e.g. '?dav=true). Basically the same code used currently that looks up the regular password in Xwiki, should have a switch on if "?dav=true" to select lookup using the MD5Password column or the regular password column. (a pretty simple and trivial/scopable change).
Also needed, an external way of setting the user-associated entry in the new MD5Password column to the password for the current DAV session. (akin to https://.../davlogin mentioned above).
This new MD5Password db column represents the MD5Passwords for all active DAV sessions on a given wiki, while the rest of xwiki continues to work the same with the old password mechanism, as long as you don't give the new parameter ?dav=true.
This is getting totally out of control. I'm against this for many reasons:
- We're trying hard to abstract the storage mechanism. There is no database, no table, no column. Currently there is no password column, it is just an xwiki property like any other. And as I said before, anything stored in the wiki is retrievable. - Changing the user's password is not acceptable. This means that he cannot use both the webdav and the browser at the same time. And if he forgets to logout, he won't be able to access the wiki normally. - Disabling the feature for "Admin" is not good. There is nothing special about the Admin account, it is just a name we chose for a default account. It could be called anyway, what matters is the rights set in the wiki. There is nothing special in XWiki, everything is a document, and all documents are equal (except those with programming rights). We should not have special cases in our code. - This is not going to work anyway, since we still can't store HA1 and be able to read it back, and storing RESPONSE is not practicle, since it depends on the visited URL. What I'm saying is that the only thing that can be done with a hashed value is to obtain a cleartext value from the client, hash it and compare it with what is stored in the wiki. Without the full, unencrypted text, there's no way we can make use use of the stored value. And since RESPONSE depends on the visited URL (and in a more secure version on the whole request body), this makes impossible this external "login" service. - Although some implementations do use the same nonce for a full session, this is wrong. The specification clearly states that the nonce should be uniquely generated for each authentication request (see http://tools.ietf.org/html/rfc2617#page-9 ), and by its name NONCE means that it should be used only once.
To clarify things a bit, the specification says that the nonce is generated whenever a 401 response is sent. This does not mean after every client request, but there are no strict rules for this. It could expire after a certain amount of time, or after a number of uses, or who knows. By default, Apache httpd is configured so that nonces expire after 5 minutes. Since we're making the server, we can decide our own strategy for this expiration, so we could make it behave like a session.
- The WebDAV component should be a component, and components don't have strong bounds to other components. So, making special cases for WebDAV is wrong. - And the most important reason for me is that this is ugly. The right code should be clean, simple and elegant, not a complete hack messing around all the platform, just so that we comply with the flawed Digest authentication mechanism. Requiring that the password is plainly available on the server is crazy. If any MS product fails because of this, then it is just another sign of their stupid vendor lock-in attempts, and I will not succumb to them.
I don't mean to offend anybody, I'm just speaking from a technical point of view.
-- Sergiu Dumitriu http://purl.org/net/sergiu/
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-mod_auth_mda-for-Xwiki-single-sign-on---(was-Re%3A-urgent-regarding-Xwiki-building)-td661771.html<http://n2.nabble.com/Using-Apache-Basic-Authentication-API-credentials-and-mod_auth_mda-for-Xwiki-single-sign-on---%28was-Re%3A-urgent-regarding-Xwiki-building%29-td661771.html>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>), 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.html#authdigestprovider>instead of the normal AuthType Basic and AuthBasicProvider<http://httpd.apache.org/docs/2.2/mod/mod_auth_basic.html#authbasicprovider>. Then add a AuthDigestDomain<http://httpd.apache.org/docs/2.2/mod/mod_auth_digest.html#authdigestdomain>directive 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>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 <[email protected]> wrote:
Sergiu Dumitriu wrote:
Niels Mayer wrote:
On Sun, Oct 26, 2008 at 9:11 AM, Asiri Rathnayake < [email protected]> wrote:
As I observed with DAVExplorer, nonce is actually used throughout a session. Upon login, the server generates a nonce value as bellow : nonce = MD5(client_ip,time_stamp,private_key); // source : [Adding Digest Access Authentication to a WebDAV Server<
http://www.cs.columbia.edu/%7Ehgs/teaching/ais/1998/projects/WebDAV/report.h...
] and sends this to the client. The client in turn uses this nonce value when generating the RESPONSE hash in all following requests.
... Which is why you can have an external "HTTPS-accessible shadow-login program" invoked once per DAV session, to change Xwiki's password to the MD5Password computed from the nonce/session-key. In my previous email I called this DAV login service "davlogin" (e.g. https://.../davlogin?user=foo&md5pass=0x0123456789ABCDEF )
Of course, this would have side-issues like making web-login to a user account in Xwiki difficult since the password would be set to the last session's Md5Password. I guess you could have another program "davlogout" to restore the normal Xwiki password. And another table in the db to store the regular password.
Yes it's a hack.
The next question is there a way to accomplish the exact same thing in code to achieve the same goal, but without the hack.
For example, by adding a new special parameter to any DAV-originated request, to enable authentication based on a new MD5Password column in the database. The MD5Password would be used for authentication for any requests using the special-parameter (e.g. '?dav=true). Basically the same code used currently that looks up the regular password in Xwiki, should have a switch on if "?dav=true" to select lookup using the MD5Password column or the regular password column. (a pretty simple and trivial/scopable change).
Also needed, an external way of setting the user-associated entry in the new MD5Password column to the password for the current DAV session. (akin to https://.../davlogin mentioned above).
This new MD5Password db column represents the MD5Passwords for all active DAV sessions on a given wiki, while the rest of xwiki continues to work the same with the old password mechanism, as long as you don't give the new parameter ?dav=true.
This is getting totally out of control. I'm against this for many reasons:
- We're trying hard to abstract the storage mechanism. There is no database, no table, no column. Currently there is no password column, it is just an xwiki property like any other. And as I said before, anything stored in the wiki is retrievable. - Changing the user's password is not acceptable. This means that he cannot use both the webdav and the browser at the same time. And if he forgets to logout, he won't be able to access the wiki normally. - Disabling the feature for "Admin" is not good. There is nothing special about the Admin account, it is just a name we chose for a default account. It could be called anyway, what matters is the rights set in the wiki. There is nothing special in XWiki, everything is a document, and all documents are equal (except those with programming rights). We should not have special cases in our code. - This is not going to work anyway, since we still can't store HA1 and be able to read it back, and storing RESPONSE is not practicle, since it depends on the visited URL. What I'm saying is that the only thing that can be done with a hashed value is to obtain a cleartext value from the client, hash it and compare it with what is stored in the wiki. Without the full, unencrypted text, there's no way we can make use use of the stored value. And since RESPONSE depends on the visited URL (and in a more secure version on the whole request body), this makes impossible this external "login" service. - Although some implementations do use the same nonce for a full session, this is wrong. The specification clearly states that the nonce should be uniquely generated for each authentication request (see http://tools.ietf.org/html/rfc2617#page-9 ), and by its name NONCE means that it should be used only once.
To clarify things a bit, the specification says that the nonce is generated whenever a 401 response is sent. This does not mean after every client request, but there are no strict rules for this. It could expire after a certain amount of time, or after a number of uses, or who knows. By default, Apache httpd is configured so that nonces expire after 5 minutes. Since we're making the server, we can decide our own strategy for this expiration, so we could make it behave like a session.
- The WebDAV component should be a component, and components don't have strong bounds to other components. So, making special cases for WebDAV is wrong. - And the most important reason for me is that this is ugly. The right code should be clean, simple and elegant, not a complete hack messing around all the platform, just so that we comply with the flawed Digest authentication mechanism. Requiring that the password is plainly available on the server is crazy. If any MS product fails because of this, then it is just another sign of their stupid vendor lock-in attempts, and I will not succumb to them.
I don't mean to offend anybody, I'm just speaking from a technical point of view.
-- Niels http://nielsmayer.com
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> *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 <[email protected]> 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-mod_auth_mda-for-Xwiki-single-sign-on---(was-Re%3A-urgent-regarding-Xwiki-building)-td661771.html<http://n2.nabble.com/Using-Apache-Basic-Authentication-API-credentials-and-mod_auth_mda-for-Xwiki-single-sign-on---%28was-Re%3A-urgent-regarding-Xwiki-building%29-td661771.html>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>), 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.html#authdigestprovider>instead of the normal AuthType Basic and AuthBasicProvider<http://httpd.apache.org/docs/2.2/mod/mod_auth_basic.html#authbasicprovider>. Then add a AuthDigestDomain<http://httpd.apache.org/docs/2.2/mod/mod_auth_digest.html#authdigestdomain>directive 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>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 <[email protected]> wrote:
Sergiu Dumitriu wrote:
Niels Mayer wrote:
On Sun, Oct 26, 2008 at 9:11 AM, Asiri Rathnayake < [email protected]> wrote:
As I observed with DAVExplorer, nonce is actually used throughout a session. Upon login, the server generates a nonce value as bellow : nonce = MD5(client_ip,time_stamp,private_key); // source : [Adding Digest Access Authentication to a WebDAV Server<
http://www.cs.columbia.edu/%7Ehgs/teaching/ais/1998/projects/WebDAV/report.h...
] and sends this to the client. The client in turn uses this nonce value when generating the RESPONSE hash in all following requests.
... Which is why you can have an external "HTTPS-accessible shadow-login program" invoked once per DAV session, to change Xwiki's password to the MD5Password computed from the nonce/session-key. In my previous email I called this DAV login service "davlogin" (e.g. https://.../davlogin?user=foo&md5pass=0x0123456789ABCDEF )
Of course, this would have side-issues like making web-login to a user account in Xwiki difficult since the password would be set to the last session's Md5Password. I guess you could have another program "davlogout" to restore the normal Xwiki password. And another table in the db to store the regular password.
Yes it's a hack.
The next question is there a way to accomplish the exact same thing in code to achieve the same goal, but without the hack.
For example, by adding a new special parameter to any DAV-originated request, to enable authentication based on a new MD5Password column in the database. The MD5Password would be used for authentication for any requests using the special-parameter (e.g. '?dav=true). Basically the same code used currently that looks up the regular password in Xwiki, should have a switch on if "?dav=true" to select lookup using the MD5Password column or the regular password column. (a pretty simple and trivial/scopable change).
Also needed, an external way of setting the user-associated entry in the new MD5Password column to the password for the current DAV session. (akin to https://.../davlogin mentioned above).
This new MD5Password db column represents the MD5Passwords for all active DAV sessions on a given wiki, while the rest of xwiki continues to work the same with the old password mechanism, as long as you don't give the new parameter ?dav=true.
This is getting totally out of control. I'm against this for many reasons:
- We're trying hard to abstract the storage mechanism. There is no database, no table, no column. Currently there is no password column, it is just an xwiki property like any other. And as I said before, anything stored in the wiki is retrievable. - Changing the user's password is not acceptable. This means that he cannot use both the webdav and the browser at the same time. And if he forgets to logout, he won't be able to access the wiki normally. - Disabling the feature for "Admin" is not good. There is nothing special about the Admin account, it is just a name we chose for a default account. It could be called anyway, what matters is the rights set in the wiki. There is nothing special in XWiki, everything is a document, and all documents are equal (except those with programming rights). We should not have special cases in our code. - This is not going to work anyway, since we still can't store HA1 and be able to read it back, and storing RESPONSE is not practicle, since it depends on the visited URL. What I'm saying is that the only thing that can be done with a hashed value is to obtain a cleartext value from the client, hash it and compare it with what is stored in the wiki. Without the full, unencrypted text, there's no way we can make use use of the stored value. And since RESPONSE depends on the visited URL (and in a more secure version on the whole request body), this makes impossible this external "login" service. - Although some implementations do use the same nonce for a full session, this is wrong. The specification clearly states that the nonce should be uniquely generated for each authentication request (see http://tools.ietf.org/html/rfc2617#page-9 ), and by its name NONCE means that it should be used only once.
To clarify things a bit, the specification says that the nonce is generated whenever a 401 response is sent. This does not mean after every client request, but there are no strict rules for this. It could expire after a certain amount of time, or after a number of uses, or who knows. By default, Apache httpd is configured so that nonces expire after 5 minutes. Since we're making the server, we can decide our own strategy for this expiration, so we could make it behave like a session.
- The WebDAV component should be a component, and components don't have strong bounds to other components. So, making special cases for WebDAV is wrong. - And the most important reason for me is that this is ugly. The right code should be clean, simple and elegant, not a complete hack messing around all the platform, just so that we comply with the flawed Digest authentication mechanism. Requiring that the password is plainly available on the server is crazy. If any MS product fails because of this, then it is just another sign of their stupid vendor lock-in attempts, and I will not succumb to them.
I don't mean to offend anybody, I'm just speaking from a technical point of view.
-- Niels http://nielsmayer.com
-- Niels http://nielsmayer.com
Hi Sergiu, On Sun, Oct 26, 2008 at 8:20 AM, Sergiu Dumitriu <[email protected]> wrote:
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?
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
-- Sergiu Dumitriu http://purl.org/net/sergiu/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Asiri Rathnayake wrote:
Hi Sergiu,
On Sun, Oct 26, 2008 at 8:20 AM, Sergiu Dumitriu <[email protected]> wrote:
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?
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.
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.
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/
participants (5)
-
Asiri Rathnayake -
Ludovic Dubost -
Niels Mayer -
Paul Libbrecht -
Sergiu Dumitriu