Tuesday, April 3, 2012

RFC 2069 digest auth generator

I had a bad problem with mod_proxy vs chromium vs a gwt based app. Every other browser worked fine except chromium for no obvious reason. The server was returning 403 only to chromium. And also without proxy Chromium was working fine.

After quadruple-checking everything is configured correctly I thought maybe digest (server only allows digest auth) generation is wrong with chromium... I saw a couple of digest auth issues in its bug tracker still opened.

So here's the digest generator:
# user:realm:password
# request_method:request_uri

getFirst () {
echo -n "$1"
md5get () {
local dat="$1"
echo -n `getFirst $(md5sum -b <(printf "%s" "$dat"))`

HA1=`md5get "$HA1"`
HA2=`md5get "$HA2"`
echo responce=`md5get "$res"`
usage: run script with user:realm:password as first param, request_method:request_uri as second param and nonce as third param; for RFC 2617 you can adjust the values of HA1 and H2 you pass to the script, that's described in the wikipedia article below.
./digest_auth.sh "admin:SecureRealm:securepassword" "POST:/management" 6ec791feebb1f853f4757330ffed1d8e

useful for: verifying client is computing values correctly looking at tcpdump/wireshark log
references: http://en.wikipedia.org/wiki/Digest_access_authentication
how story ended: It turned out only chromium always sends a header named "Origin". It also seems that header can give some CSRF protection so perhaps mod_proxy should learn to handle it. For the time being though this Apache HTTPD directive gets rid of the beast:
RequestHeader unset Origin