digest CheckAuth assumes nonce-count always increases

[kmanley]

The digest module CheckAuth function makes the reasonable assumption that the client-sent nonce-count ("nc") always increases. Unfortunately, in practice, because a client can have multiple connections to a server, some possibly through proxies and/or via AJAX, client-sent nonce-counts don't always increase from the POV of the server. Strictly the requirement is that a nonce-count is not reused, not that it always increases. I am observing this as I try to use go-http-auth in a real world setting. I will send a PR to either track nonces with a bitmap or add an option to turn off nc checking. Thank you for open sourcing this excellent lib.
References:
https://lists.w3.org/Archives/Public/ietf-http-wg/2003JulSep/0006.html
https://code.google.com/p/chromium/issues/detail?id=37526

[abbot]

Keep in mind that turning off nc checking defeats the purpose of nc. Since nc should be a request counter (per rfc, https://tools.ietf.org/html/rfc2617#section-3.2.2), out-of-order values seem to be possible only if the same nonce is reused on multiple connections to the same server, which seems to be a broken client side implementation (e.g. rfc explicitly allows server to even force new per-request nonce values to clients, using next-nonce, https://tools.ietf.org/html/rfc2617#section-4.3). Do you have a (preferably simple) way to reproduce this?

[kmanley]

It's not just broken clients (which exist), it's also possible to get out of order nc values due to ajax requests, proxies between client and server, etc. In my case I've used go-http-auth to implement auth in a proxy server and I routinely see out of order ncs while surfing through my proxy. Some googling indicates Apache, Squid, etc have settings to deal with this by turning off nc checking.

I made a local change to optionally disable nc checking via a flag in the DigestAuth struct, will send you a PR soon