Re: [libmicrohttpd] digest auth TLS and POST

[Christian Grothoff]

Hi Mark,

I got it now.  The issue is that in digestauth.c:415/416, MHD hashes
the URI into the MD5 that is being generated for the nonce (timestamps
and counters are not the issue here, which is what confused me):

  MD5Update (&md5, uri, strlen(uri));
  MD5Update (&md5, ":", 1);

If you remove those two lines, the example you e-mailed me works without
any Authentication Failed responses.  Now, the issue here is that once
you do remove those lines, you loose a bit of security against a MiTM
attacker.

Say user A requests file /foo.pdf, then currently a MiTM can (with
HTTP digest auth) see /foo.pdf being transmitted, but that's it.  If
you remove the URI from the set, the MiTM can grab the authorization
code and get /secret.pdf as well.

Sadly, the browser doesn't know MHD's method for computing nonces,
and thus always uses the same nonce for different URIs, which fails
once the URI itself changes.  AFAIK there is no good choice, as there
is no way to magically tell browsers how to "properly" generate
nonces, as that's the servers domain, and re-using nonce's for different
requests goes against the security model: nonce = number used ONCE;
the fact that browsers re-use the same nonce for a different request
may (with "lesser" HTTP servers) slightly improve performance, but at
a price.

Now, theoretically one could offer an option to comment out those two
lines, but I'm unconvinced that the minimal performance improvement
for the (IMO rare) case of digest authentication is worth the additional
security risk, especially given the widespread surveillance and MiTM
attacks that are happening on the Internet today.


Happy hacking!

Christian

On 01/12/2014 05:51 PM, A. Mark wrote:
> 
> Thanks Christian,
> 
> The "problem" is not the need to re authenticate via the password or
> having the reenter the password for each request which is not an issue
> for me either. I attached the example code to clearly show the behavior.
> What happens is that every request after the initial authentication has
> MHD_INVALID_NONCE initially from the client. Then when the nonce is
> resent from the server the client then sends a valid cnonce etc. I'm
> under the assumption that the client is supposed to be able to generate
> (increment) the cnonce counter without having the nonce to be presented
> every time. So I think either the client or the server side is not
> generating the subsequent counters properly.
> 
> Please see the attached code example.
> 
> Regards Mark
> 
> 
> On Sun, Jan 12, 2014 at 5:58 AM, Christian Grothoff <address@hidden
> <mailto:address@hidden>> wrote:
> 
>     On 01/04/2014 05:03 AM, A. Mark wrote:
>     > Questions:
>     >
>     > 1) Getting a MHD_INVALID_NONCE from MHD_digest_auth_check() when
>     > authenticating on every request even when requests are one second
>     apart. Is
>     > this due to the browsers inability to generate proper cnonce?  Both
>     > Chromium and Firefox exhibit this. (the same happens with
>     > digest_auth_example)
> 
>     I've now tried to reproduce this using 'digest_auth_example'.  On the
>     first visit, I need to authenticate, then I push reload (possibly with
>     significant delay) and Firefox does NOT require me to re-enter the
>     password.  I also checked with wireshark to make sure it wasn't just
>     Firefox caching the password and submitting it on 2nd attempt, and it
>     is indeed only a single HTTP request going between client and server,
>     as one would expect.
> 
>     So I'm still unable to reproduce your issue.
> 
>     Happy hacking!
> 
>     Christian
> 
>

0x48426C7E.asc
Description: application/pgp-keys

signature.asc
Description: OpenPGP digital signature