Basic and Digest Authentication Types

Authentication is the process in which the system identifies logged in users from unauthorized users. The effectiveness of this process is determined by the authentication protocols and mechanisms being used. In this article we will start reviewing authentication types that are used to verify the identities of users and decide whether they are really secure or not.

Basic HTTP

The first version of SIP used Basic HTTP authentication. This system is fairly easy to access using man-in-the-middle attacks. This type of authentication has been depreciating for some time now.

In HTTP authentication, an attacker can simply capture a packet containing the password and base64 encoded, which is then used to decode and perform attacks.

Not secure, indeed.

Digest Authentication

Digest Authentication, used both by SIP and HTTP, introduces the ability to only save an encrypted version of the password on the server. This prevents the client from sending the password in an easily decodable format, and it allows the server to save a hash of the password (which cannot be easily decoded).

Let’s examine in detail the messages exchanged between the client and server:

Server requires authentication:

WWW-Authenticate: Digest realm="testrealm@host.com",

                       qop="auth,auth-int",

                       nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",

                       opaque="5ccc069c403ebaf9f0171e9517f40e41"

Client adds authentication information:

Authorization: Digest username="Mufasa",

                    realm="testrealm@host.com",

                    nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",

                    uri="/dir/index.html",

                    qop=auth,

                    nc=00000001,

                    cnonce="0a4f113b",

                    response="6629fae49393a05397450978507c4ef1",

                    opaque="5ccc069c403ebaf9f0171e9517f40e41"

The “response” value is calculated in the following three steps (if values are combined, they are delimited by colons):

1. The MD5 hash of the combined username, authentication realm, and password is calculated. The result is referred to as HA1.
2. The MD5 hash of the combined method and digest URI is calculated (for example, of “GET” and “/dir/index.html”). The result is referred to as HA2.
3. The MD5 hash of the combined HA1 result, server nonce (nonce), request counter (nc), client nonce (cnonce), quality of protection code (qop), and HA2 result is calculated. The result is the “response” value provided by the client.

HA1 = MD5( "Mufasa:testrealm@host.com:Circle Of Life" )

      = 939e7578ed9e3c518a452acee763bce9

  HA2 = MD5( "GET:/dir/index.html" )

      = 39aff3a2bab6126f332b942af96d3366

  Response = MD5( "939e7578ed9e3c518a452acee763bce9:\

                   dcd98b7102dd2f0e8b11d0f600bfb0c093:\

                   00000001:0a4f113b:auth:\

                   39aff3a2bab6126f332b942af96d3366" )

           = 6629fae49393a05397450978507c4ef1

The advantages of using this method are the following:

• The password is not used directly in the digest, but rather HA1 = MD5 (username:realm:password). This allows some implementations (such as JBoss (https://en.wikipedia.org/wiki/JBoss) to store HA1 rather than the plaintext password.
• Client nonce was introduced in RFC 2617 (https://tools.ietf.org/html/rfc2617), which allows the client to prevent chosen-plaintext attacks, such as rainbow tables (https://en.wikipedia.org/wiki/Rainbow_table), that could otherwise threaten digest authentication schemes.
• Server nonce is allowed to contain timestamps, meaning the server may inspect nonce attributes submitted by clients to prevent replay attacks.
• Server is also allowed to maintain a list of recently issued or used server nonce values to prevent reuse.

The disadvantages to this configuration include:

• Many of the security options in RFC 2617 are optional. If quality-of-protection (QOP) is not specified by the server, the client will operate in a security-reduced legacy RFC 2069 mode (https://tools.ietf.org/html/rfc2069)
• Digest access authentication is vulnerable to a man-in-the-middle (MitM) attack (https://en.wikipedia.org/wiki/Man-in-the-middle_attack). For example, a MitM attacker could tell clients to use basic access authentication or legacy RFC2069 digest access authentication mode. To extend this further, digest access authentication provides no mechanism for clients to verify the server’s identity
• Some servers require passwords to be stored using reversible encryption. However, it is possible to instead store the digested value of the username, realm, and password
• It prevents the use of a strong password hash (such as bcrypt) when storing passwords (since either the password or the digested username, realm, and password must be recoverable).

In conclusion, Digest is an improvement, but it still has significant drawbacks. The main one being that it suffers from man-in-the-middle attacks.

To make Digest secure, the connection between client and server must be encrypted and the server encryption key preloaded, or a certificate authority must be used to allow the client to verify the server’s public key.