Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Change cnonce values more frequently #50
When using only 1 second precision, curl doesn't change cnonce values frequently enough for all uses.
For example, issuing the following command multiple times within a few seconds to a recent Tomcat causes authentication failures (after one success):
curl --digest -utest:test http://tomcat.test.com:8080/manager/list
This is because curl uses the same cnonce for several seconds, but doesn't increment the nonce counter. Tomcat correctly interprets this as a replay attack and rejects the request.
When microsecond-precision is available, this commit causes curl to change cnonce values much more frequently.
Yeah, I was thinking that it was a bit short, but then I wouldn't be able to claim a one-line fix. :-D
If the cnonce changes enough (has enough entropy, if we want to get formal), then the length shouldn't matter too much. A couple of quick Google searches show that there isn't really any consensus on cnonce length and RFC 2617 is silent on the matter. Most implementations seem to use around 8 bytes, but Java uses 40. I like powers of 2 myself, so how does 32 bytes sound?
Ah, dang. I was working on a slightly different approach and forgot to withdraw my pull request. What you committed should work, but since long integers will never fill the 32-byte buffer (on architectures using integers smaller than 128 bits, anyways), we'll have a lot of base64-encoded zeroes in the cnonce.
If you'd like, I can provide a different method that scatters the bits over the entire 32-byte buffer before encoding it to base64.