0

Http Basic Authentication – Introduction & Implementation

Hello friends, in our previous articles we’ve discussed about Http Authentication. Now we know importance of authentication\Authorization. So this is the time now to discuss about various schema available for authentication and how these are implemented. Let’s discuss about basic authentication.

HTTP provides a general framework for access control and authentication. The most common HTTP authentication is based on “Basic” schema. This page shows an introduction to HTTP Basic authentication.

How Authentication Starts

  • First HTTP client makes a request to the web server.
  • Request method doesn’t has to be GET it can be any method.
  • If web server sees that the requested resource need authentication to access then it sends backs 401 unauthorized status code along with WWW-Authenticate header.
  • Then client displays a dialog box to take username and password as input.
  • Once the credentials has been enter the client sends it using the Authorization header.
  • If the credentials are correct then server responds with 200 status code and Authentication-Info header.
  • If client sends wrong credentials in the Authorization request then server again responds with 401 status code. The client is allowed to try again and again.

Basic Authentication

Basic Authentication

We discussed that when web server sees that the requested resource need authentication to access then it sends backs 401 unauthorized status code along with WWW-Authenticate header.

Below is the response sent by server if user is unauthenticated.

WWW-Authenticate: realm=”Images”

What is Realm? Let’s discuss this.

Realm:

Servers use realm to group different parts of the server (assigns same realm, username and password other resources on the same and deeper level). Browser saves credentials for all realm’s. Whenever browser receives a WWW-Authenticate response with a realm already saved, it will automatically send the credentials without the knowledge of user. Browser also sends Authorization request directly to the URLs deeper than a level whose realm and credentials are known. This creates a session among the URls with same realm and also URIs deeper to a saved realm.

It is compulsory that this header will contain a realm directive. Realm is displayed in the dialog box.

Authorization:

Client send the request again by putting credentials in the dialog box which is displayed. Browser uses Authorization header to send this information to server. Username and password are joined together with a colon in between and then encoded using base-64 encoding method.

So if the username is “deepak” and the password is “pwd123456” than a string “deepak:pwd123456” is generated and then encoded using base64. Then this encoded result is sent to the server.

Below is the example of Authorization header.

Authorization: Basic S08tyui78ophJKL

Proxy-Authentication

Some organizations use proxy servers to authenticate users before allowing them to access the web server resources. The same mechanism is used by proxies to authenticate users but header and status codes are changed. Below are the changes:

  • Response status 407: 407 response status code is sent instead of 401. This code is meant for proxy authentication.
  • Proxy-Authenticate: Proxy-Authenticate is used instead of WWW-Authenticate.
  • Proxy-Authorization: Proxy-Authorization is used instead of Authorization when credentials are sent to server.
  • Proxy-Authentication-Info: Proxy-Authentication-Info is used instead of Authentication-Info.

The Authentication-Info Header Field

Sometime server return with addition information using Authentication-Info header.

HTTP authentication schemes can use the Authentication-Info response header field to return additional information applicable to the authentication currently in use.

The field value is a list of parameters (name/value pairs),

The Authentication-Info header field can be used in any HTTP response, independently of request method and status code. 

Security of Basic Authentication

As the user ID and password are passed over the network as clear text (it is base64 encoded, but base64 is a reversible encoding), the basic authentication scheme is not secure. HTTPS / TLS should be used in conjunction with basic authentication. Without these additional security enhancements, basic authentication should not be used to protect sensitive or valuable information.

0

Http Authentication – Introduction

Hello friends, we are in discussion about Http and various important aspects related to the same. While discussing this, we cannot ignore vary important aspect of discussion i.e. Http Authentication & Access control.

We live in world of internet where each and every information is available on the network and can be accessed by anyone. With that said, there is some confidential\proprietary information which is available and should be accessed only by authorized people. To access authorized information, we need to prove our identity and we should have access to those resources which we want.

In internet world this is accomplished via Http Authentication\Authorization.

Http also has its own authentication framework to authenticate user and provide authorized information.

HTTP provides a general framework for access control and authentication. The most common HTTP authentication is based on “Basic” schema. This page shows an introduction to HTTP framework for authentication and shows what all type of schemas are there.

HTTP Authentication Framework

RFC 7235 defines the HTTP authentication framework which can be used by a server to challenge a client request and then a client provides authentication information.

The challenge and response flow works like this:

  • Client requests a resource from server.
  • The server responds to a client with a 401(Unauthorized) response status and provides information on how to authorize with a WWW-Authenticate response header containing at least one challenge.
  • A client that wants to authenticate itself with a server, will provide its username and password.
  • Server will match credentials and then will provide resource if authentication succeeded.

Below is the flow:

Http Authentication

Proxy Authentication

The same challenge and response mechanism can be used for proxy authentication. Suppose, there is an intermediate proxy that requires authentication. As both resource authentication and proxy authentication can coexist, a different set of headers and status codes are needed.

In the case of proxies, the challenging status code is 407 (Proxy Authentication Required), the Proxy-Authenticate response header contains at least one challenge applicable to the proxy, and the Proxy-Authorization request header is used for providing the credentials to the proxy server.

Access forbidden

If a (proxy) server receives valid credentials that are not adequate to gain access for a given resource, the server should respond with the 403 Forbidden status code. 

Authentication of cross-origin images

A potential security hole that has recently been fixed by browsers is authentication of cross-site images.

Previously an image from different origin was able to show authentication dialog box to user and user has to put credentials. This way one can steal your data as credential information could be in Base64 encoded and can be cracked easily.

As part of security fix, all image resources loaded from different origins to the current document are no longer able to trigger HTTP authentication dialog, preventing user credentials being stolen if attackers were able to embed an arbitrary image into a third-party page. 

WWW-Authenticate and Proxy-Authenticate headers

The WWW-Authenticate and Proxy-Authenticate response headers define the authentication method that should be used to gain access to a resource. They need to specify which authentication scheme is used, so that the client that wishes to authorize knows how to provide the credentials. The syntax for these headers is the following:

WWW-Authenticate: <type> realm=<realm>

Proxy-Authenticate: <type> realm=<realm>

Here, <type> is the authentication scheme (“Basic” is the most common scheme and introduced below). The realm is used to describe the protected area or to indicate the scope of protection. This could be a message like “Access to the staging site” or similar, so that the user knows to which space they are trying to get access to.

Authorization and Proxy-Authorization headers

The Authorization and Proxy-Authorization request headers contain the credentials to authenticate a user agent with a (proxy) server. Here, the type is needed again followed by the credentials, which can be encoded or encrypted depending on which authentication scheme is used.

Authorization: <type> <credentials>

Proxy-Authorization: <type> <credentials>

Authentication schemes

The general HTTP authentication framework is used by several authentication schemes. Schemes can differ in security strength and in their availability in client or server software.

The most common authentication scheme is the “Basic” authentication scheme which is introduced in more details below. IANA maintains a list of authentication schemes, but there are other schemes offered by host services, such as Amazon AWS.

Common authentication schemes include:

Authentication Scheme

Description

Anonymous

An anonymous request does not contain any authentication information. This is equivalent to granting everyone access to the resource.

Basic

Basic authentication sends a Base64-encoded string that contains a user name and password for the client. Base64 is not a form of encryption and should be considered the same as sending the user name and password in clear text. If a resource needs to be protected, strongly consider using an authentication scheme other than basic authentication.

Digest

Digest authentication is a challenge-response scheme that is intended to replace Basic authentication. The server sends a string of random data called a nonce to the client as a challenge. The client responds with a hash that includes the user name, password, and nonce, among additional information. The complexity this exchange introduces and the data hashing make it more difficult to steal and reuse the user’s credentials with this authentication scheme.

Digest authentication requires the use of Windows domain accounts. The digest realm is the Windows domain name. Therefore, you cannot use a server running on an operating system that does not support Windows domains, such as Windows XP Home Edition, with Digest authentication. Conversely, when the client runs on an operating system that does not support Windows domains, a domain account must be explicitly specified during the authentication.

NTLM

NT LAN Manager (NTLM) authentication is a challenge-response scheme that is a securer variation of Digest authentication. NTLM uses Windows credentials to transform the challenge data instead of the unencoded user name and password. NTLM authentication requires multiple exchanges between the client and server. The server and any intervening proxies must support persistent connections to successfully complete the authentication.

Kerberos

This authentication service was developed at Massachusetts Institute of Technology (MIT). It involves the symmetric key encryption practice and a KDC (Key distribution center). It verifies the identities of communication parties on an unprotected network. This is achieved without depending on authentication mechanism by the host OS, without necessitating physical security of the host and without building trust on host address.

Negotiate

Negotiate authentication automatically selects between the Kerberos protocol and NTLM authentication, depending on availability. The Kerberos protocol is used if it is available; otherwise, NTLM is tried. Kerberos authentication significantly improves upon NTLM. Kerberos authentication is both faster than NTLM and allows the use of mutual authentication and delegation of credentials to remote machines.

Windows Live ID

The underlying Windows HTTP service includes authentication using federated protocols. However, the standard HTTP transports in WCF do not support the use of federated authentication schemes, such as Microsoft Windows Live ID. Support for this feature is currently available through the use of message security.

 

This is only an introduction about Http Authentication framework and schemas. In upcoming articles we’ll discuss each of these schemas in detail.