Java Reference
In-Depth Information
bburke:geheim will be YmJ1cmtlOmdlaGVpbQ== . Put all this together, and our authenticated
GET request would look like this:
GET /customers/333
HTTP / 1.1
Authorization : Basic YmJ1cmtlOmdlaGVpbQ==
/customers/333 HTTP
The client needs to send this Authorization header with each and every request it makes to
the server.
The problem with this approach is that if this request is intercepted by a hostile entity on the
network, the hacker can easily obtain the username and password and use it to invoke its own
requests. Using an encrypted HTTP connection, HTTPS, solves this problem. With an en-
crypted connection, a rogue programmer on the network will be unable to decode the trans-
mission and get at the Authorization header. Still, security-paranoid network administrat-
ors are very squeamish about sending passwords over the network, even if they are encrypted
within SSL packets.
Digest Authentication
Although not used much anymore, Digest Authentication was invented so that clients would
not have to send clear-text passwords over HTTP. It involves exchanging a set of secure
MD5 hashes of the username, password, operation, URI, and optionally the hash of the mes-
sage body itself. The protocol starts off with the client invoking an insecure request on the
GET /customers/333
/customers/333 HTTP
HTTP / 1.1
Since the request does not contain any authentication information, the server replies with an
HTTP response of:
HTTP / 1.1 401 Unauthorized
WWW-Authenticate : Digest realm="CustomerDB Realm",
Like before, a 401 error code is returned along with a WWW-Authenticate header. The nonce
and opaqu attributes are special server-generated keys that will be used to build the subse-
quent authenticated request.
Like Basic Authentication, the client uses the Authorization header, but with digest-specif-
ic attributes. Here's a request example:
GET /customers/333
HTTP / 1.1
Authorization : Digest username="bburke",
/customers/333 HTTP
Search WWH ::

Custom Search