Data exchange over HTTP is never a secure activity; the integration of data is bound to get a beating somewhere during the process. HTTP provides an unsecured path, which, most of the times is not reliable for transmitting sensitive information. Online transactions or any other procedures that deal with user credentials are more susceptible at being accessed through third parties.
Still, in the event of a data transaction, a simple authentication process is adopted, which is Basic Access Authentication. Under this authentication process, the data is neither hashed nor encrypted but is encoded in Base64. Base64 is a kind of data exchange format, which does not promise the complete integrity of data that is being transferred. Under Base64 each 6 bits of data is being represented by a Base64 digit. The first obstacle is when a request is sent from the client side to access a web page, the user will be given an “HTTP 401 Not Authorized” response. This happens when the browser has failed to cache the user credentials which are previously provided. Again the username and password are coupled and encoded under Base64 before being used in an Authentication header.
WWW-Authenticate: Basic realm=”abc.com”
The server on receiving this authentication header applies a simple process of reverse engineering for decoding the information. The vulnerability of data here is greater, as the information is neither hashed nor encrypted. To counter this impediment, a new authentication process is used, which is the Digest Access Authentication.
How Does Digest Access Authentication Work?
Suppose a client is trying to access the resource which requires an authentication, then the server sends an HTTP WWW-Authenticate header as a response. Note: If the user is new, then the credentials will not be available with the server on prior. For each of the request sent by a client, the response should be unique. The response from server side is generated through following these steps.
Initially, as soon as the server gets a request it produces a value known as a nonce. The nonce should be unique for each of the requests and is to be based on either Base64 or hexadecimal. Through this nonce, the client will send back a hash to the server.
<?php
$nonce = md5(uniqid());
Here, the server deters from reusing the nonce values to avoid replay attacks.
In the following step, the server sends a string of data called opaque, which should be sent back by client unchanged.
<?php
$opaque = md5(uniqid());
The final value is realm, under this, users are provided with a string to make them aware of the username and password which are to be sent.
<?php
$realm = ‘Authorized users of abc.com’;
When the client side receives this, it has to respond through a hash by concatenation username, realm, and password. Note: Hashing is a process which follows a principle of many to one mapping, in simple words; a variable block of input is compressed to a fixed-size number. Under this process, the result will be hashed with MD5 before being sent through an authorization header. Here, MD5 is one of the password encryption algorithms.
This response will include username, realm, nonce, uri, opaque, and computed response which is unchanged.
Authorization: Digest username=”%s”, realm=”%s”, nonce=”%s”, opaque=”%s”, uri=”%s”, response=”%s”‘
Once the server receives this response, it performs a comparison between the computed hash and the received response hash, and if it is validated, then the client will be allowed to access the required resource.