implement HTTP Digest Auth method for better security

[yegor256]

Let's implement HTTP Digest Auth method for better security

[davvd]

@carlosmiranda could you please pick this up? This article explains how we work. Any technical questions you may ask right here

[davvd]

@carlosmiranda Task's budget is 30 mins (see this for explanation)

[davvd]

@carlosmiranda since there is no activity in the last few days in this task I decided to ask you to let us know what's going on... How are things going?

[carlosmiranda]

Is there a document that I can refer to that shows how to implement HTTP Digest?

[yegor256]

sure: http://en.wikipedia.org/wiki/Digest_access_authentication

[yegor256]

more officially http://tools.ietf.org/html/rfc2617

[carlosmiranda]

Hmmm... I'm sort of looking at where I could start implementing this in our code. I know we're doing HTTP Basic in Htpasswd.java, do we need a new class to do the same for HTTP Digest?

[yegor256]

Basic authentication is implemented in SecuredHost class. I think we should try to implement Digest there as well, in the same class. But maybe I'm wrong and we'll need an extra class. Try to investigate..

[carlosmiranda]

From what I'm reading, HTTP Digest would require us to be maintain some sort of session state, specifically to keep track of the nonces and opaque directives. Seems a little complicated considering what we've got so far. Don't you think HTTP Basic over SSL (#84) would be better, considering that doing that will take care of securing everything?

https://stackoverflow.com/questions/11923607/do-you-still-need-to-use-digest-authentication-if-you-are-on-ssl

[yegor256]

Digest is stateless. Of course, a server may maintain a list of nonces issued, but it's not mandatory.

Yes, SSL is a much better protection, we'll implement it as well. But I think that Digest is rather easy to implement and it will give some extra value to our users... Don't think so?

[carlosmiranda]

HTTP itself is stateless of course (what was I thinking?). Hmmm, all right... would this mean that we'd make this the default behavior, also?

Apologies for taking a bit of time with this, I still haven't imagined how exactly to implement it, even in a more abstract manner...

[carlosmiranda]

Okay, I think I'm beginning to understand how this will work now. So in the example below:

HA1 = MD5( "Mufasa:[email protected]:Circle Of Life" )
    = 939e7578ed9e3c518a452acee763bce9

HA2 = MD5( "GET:/dir/index.html" )
    = 39aff3a2bab6126f332b942af96d3366

Response = MD5( "939e7578ed9e3c518a452acee763bce9:\
                dcd98b7102dd2f0e8b11d0f600bfb0c093:\
                00000001:0a4f113b:auth:\
                39aff3a2bab6126f332b942af96d3366" )
        = 6629fae49393a05397450978507c4ef1

1. Does this mean that, in our initial implementation, the server doesn't have to keep track of the nonces or the nonce counter? For now it can just accept whatever the client sends, so long as the hashes match up. I'm thinking we can make this a puzzle for a later task.

2. Will our default HTTP 401 challenge ask for Basic or Digest, by default? Is there a way, based on the very first request (the one that will result in a HTTP 401 response) to determine what kind of challenge the server will be sending?

3. How do we determine what the value of "opaque" is?

[carlosmiranda]

@yegor256 , any thoughts regarding the above questions?

[yegor256]

The most important is your question no.2. Indeed, if we will ask for Basic, we will always receive it, never Digest. Looks like it's pointless to implement Digest.

I'm closing this task as "completed". We did a proper investigation and agreed that it's not necessary to have Digest together with Basic.

[davvd]

@carlosmiranda I just added 30 mins to your account, many thanks for your contribution..