Java Reference
In-Depth Information
realm="CustomerDB Realm",
nonce="12dcde223152321ab99cd",
uri="/customers/333",
qop="auth",
nc=00000001,
cnonce="43fea",
response="11132fffdeab993421",
opaque="aa9321534253bcd00121"
The
nonce
and
opaque
attributes are a copy of the values sent with the earlier
WWW-
Authenticate
header. The
uri
attribute is the base URI you are invoking on. The
nc
attrib-
ute is a request counter that should be incremented by the client with each request. This pre-
vents hostile clients from replaying a request. The
cnonce
attribute is a unique key generated
by the client and can be anything the client wants. The
response
attribute is where all the
meat is. It is a hash value generated with the following pseudocode:
H1
=
md5
(
"username:realm:password"
)
H2
=
md5
(
"httpmethod:uri"
)
response
=
md5
(
H1
+
":nonce:nc:cnonce:qop:"
+
H2
)
If our username is
bburke
and our password
geheim
, the algorithm will resolve to this
pseudocode:
H1
=
md5
(
"bburke:CustomerDB Realm:geheim"
)
H2
=
md5
(
"GET:/customers/333"
)
response
=
md5
(
H1
+
":12dcde223152321ab99cd:00000001:43fea:auth:"
+
H2
)
When the server receives this request, it builds its own version of the response hash using its
stored, secret values of the username and password. If the hashes match, the user and its cre-
dentials are valid.
One advantage of this approach is that the password is never used directly by the protocol.
For example, the server doesn't even need to store clear-text passwords. It can instead initial-
ize its authorization store with prehashed values. Also, since request hashes are built with a
nonce
value, the server can expire these nonce values over time. This, combined with a re-
quest counter, can greatly reduce replay attacks.
The disadvantage to this approach is that unless you use HTTPS, you are still vulnerable to
man-in-the-middle attacks, where the middleman can tell a client to use Basic Authentication
to obtain a password.
