8

I have a simple question: Is it possible to use Digest-Authentication with a XMLHTTPRequest?

If the answer is no, what's the technical reason? Or if it is possible - how can I do that?

Thanks a lot … google has no good answer so far :-/

EDIT:

Thanks for the answers. Modifying the header to match the digest authentication-scheme, after a nonce has been received, seems to be a solution.

But what I was really looking for was that I could change my current call: xmlhttp.open("GET", url, false, username, password); to sth. like that xmlhttp.open("GET", url, false, username, password, "DIGEST");

That’s also part of my initial question: Why does the open-method not offer the option to make a digest-request?

Maybe there is js-lib one could recommend that lets me do that - as you imagine I don't really want to change the one and simple xmlhttp.open to multiple requests and first get a nonce.

user880625
  • 246
  • 1
  • 3
  • 11
  • What have you tried so far? If your server page requires Digest auth (returning a 401 to unauthenticated requests), and you pass a username and password into your XHR open() call, everything should work just fine. – EricLaw Aug 23 '11 at 13:08
  • Have you done it ? I would be really apreciate some code. Thanks! – vrunoa May 23 '12 at 21:41

6 Answers6

9

You can do it no problem. Just follow the parts of the specs you feel like ;)
https://www.rfc-editor.org/rfc/rfc2617
and is all you are missing to start writing your authentication library
http://pajhome.org.uk/crypt/md5/
on the client side.

pre-exchange user name and password
Hey I want to authenticate ----> server
Ok here is a nonce/salt ----> client
here is a md5 hash sum of my username password timestamp and the salt -----> server
I just hased up your password and username the same way you did and they are the same ----->client
Those are the basics of it.

I left out that you need to include the URI of the requested resource in the hashsum!!!!
Of course you do this with every request you make for a resource to the server that way some one intercepting the hash could only view the content you requested and could not make a request for a miscellaneous resource.This method does not secure the data just access to it.

Community
  • 1
  • 1
Tegra Detra
  • 24,551
  • 17
  • 53
  • 78
  • I disagree. Anyone can ask for a nonce to the server. How do you want to transport that safely to the client-side? – Chielus Aug 23 '11 at 10:59
  • 5
    You don`t it is just to make it more difficult to figure out your password from the md5 and make each authentication attempt unique. http://en.wikipedia.org/wiki/Cryptographic_nonce. This way some one can not man in the middle you hash and re authenticate with it at another time. In fact they use a nonce in Oauth. I know what you are thinking that`s still totally insecure but the purpose of this type of authentication is just to preserve your user name and password. It is very basic. – Tegra Detra Aug 23 '11 at 11:05
  • 1
    I want to add that this digest method needs the server to know the password in plain. for a even more secure method, see rfc8146 – Maxi Wu Aug 18 '17 at 07:11
6

Have a look at this article : https://web.archive.org/web/20130227152456/http://marcin-michalski.pl/2012/11/01/javascript-digest-authentication-restful-webservice-spring-security-javascript-ajax/. It explains how to do JavaScript client for Digest Authentication with SpringSecurity in the server side. The code is available in github : https://github.com/Arrowgroup/JSDigestAuth

DCCoder
  • 1,587
  • 4
  • 16
  • 29
Marcin Michalski
  • 1,266
  • 13
  • 17
2

I have coded a full workflow for this, it's not difficult at all once you are using an external library for MD5 (I use Crypto-js).

The greatest issue you might have is that on the first server 401 reply any of the most used browsers will open a dialog box for getting your credentials. As far as I have seen there is not easy way to circumvent this: How can I supress the browser's authentication dialog?

To solve it, I modified the webserver which I coded from a C# codeplex project. On the first request the client passes a "Warning" header saying "Do not raise a 401". The server creates the challenge and sends it back with a custom, non-401 HttpException (I use 406 for the moment, which is "not acceptable" in HTTP). The client creates the hash and sends it back.

I can post some code snippets if anyone's interested, this is kind of an old question.

Community
  • 1
  • 1
malber
  • 1,053
  • 4
  • 16
  • 24
  • This doesn't seem to be true for Safari, when it receives 401 over an XHR. – wprl May 08 '13 at 03:52
  • What do you mean by "this"? "this" = "the browser opens a dialog box also for XHR 401"? If that is the case, there is no need for the warning header trick. Widely-compatible solutions would still require a workaround. – malber May 08 '13 at 07:44
0

You really shouldn't care which authentication method site uses, as long as your browser support it.

If you specify username and password to open method and dont't mess with Authorization header, XMLHttpRequest.send() would first try to send request without authentication, receive 401 response with WWW-Authenticate header, and retry request, providing name and password according to authorization method requested by site.

(Although there can be some extra event handlers fired during this two-stage process).

Victor Wagner
  • 1
0

To avoid the default browser authentication dialog you just set the WWW-Authenticate as Digest/YourString (ex. your realm). It is all in the first response, not so tragically.. My custom code it was working perfectly until yesterday and now I'm trying to debug something strange that is happened suddenly, still trying to understand..

Vangelis
  • 1
  • 2
0

The best way to do this is by using SSL. I don't think any other safe solution exists (correct me if i'm wrong)

Chielus
  • 632
  • 8
  • 18
  • 1
    Digest is more secure than Basic + SSL! Check out RFC 2617, the section on security. – wprl May 08 '13 at 03:50
  • 1
    Without SSL, an MitM attacker (e.g. hostile or compromised proxy; say at a public WiFi access point) can inject arbitrary JavaScript (or simply links) to the HTML. This way the attacker's requests will originate from the users' browser, thus the server won't have any chance to tell that these are _not_ from the user. The attacker does not even need to figure out the password. – robert4 Sep 26 '13 at 13:13