Imagine a world where anyone could have access to your emails, social media accounts and medical records — all your sensitive data being accessed without your consent!

Basic authentication is one of the many ways of protecting your data on the web. It ensures sensitive data is only available to people who should have access to it.

What is authentication?

Authentication is about proving you are who you say you are. For example, we authenticate ourselves at clubs showing the bouncer our passports or driving license as proof of identity. We use our PINs as proof of identity on our phones.

What is the HTTP authentication framework?

HTTP has a native challenge/response mechanism which centres around the server issuing a challenge to the client’s request for data. The client must then offer up the requested credentials to the server, before it can access data.

Imagine you are trying to enter a bar. You meet the bouncer and request access by asking, “Hey, can I come in?”.

The bouncer denies you access. He responds by issuing you a challenge, “Prove you are over 18. Show me your ID”. You respond by providing your ID. The bouncer proceeds to inspects your ID. After a second or two, he lets you in.

HTTP framework works the same way. Here is a simplified diagram showing how that works.

A simplified model of basic auth…

So what’s going on here?

• First a **GETrequest is made by the client with no authentication** to retrieve /corporate/images/company_logo.jpg.

• The server rejects the request with a 401 (Unauthorised) status code, informing the client that the correct credentials are required. This response also contains a **WWW-Authenticate** header informing the client on how to go about doing the authentication.

• The client attempts the request again with an Authorization header that specifies the username and password alongside other authentication parameters.

• If the credentials are correct, the server returns a response with a 200 status code and the client can access the documents.

Determining which users have access to which documents

With basic authentication, the server challenges the client by requesting a username and a password, returning a 401 in the process , specifying the WWW-Authenticate header in the response.

Here is an example of a WWW-Authenticate header:

WWW-Authenticate:Basic realm=’Corporate Accounts’

Web servers group documents into realms. The different realms have a different set of users. Realms tend to be descriptive enough to easily allow a user to understand which credentials they need. This is useful if a user has a bunch of credentials and need extra information to figure out which one is required to access the data.

Encoding the user’s username and password with basic authentication.

When the user provides a username and password, the browser takes this information and joins them together with a colon. For example, if my username was harry, and my password wasvoldermort!. The browser creates harry:voldermort!. This new string is then jumbled up using base-64 encoding. Base-64 encoding allows us to convert text into a string of alphabet characters. harry:voldermort! becomes aGFycnk6dm9sZGVybW9ydCE.

This is beneficial if your credentials, like above, contain characters that are not allowed in HTTP headers. There’s also a little added layer of security too, as administering servers and networks cannot view usernames and passwords.

Can you authenticate with a proxy server?

The answer is yes. Proxy servers are servers that act as intermediaries between the client and the web server. Traffic from the client flows through the proxy before hitting the web server.

Proxy servers make it easier to provide access across organisations as access policies can be easily administered on the proxy server. Proxy authentication uses the same challenge/response framework as a web server authentication, however there are some differences. For example, the unauthorised status code from a proxy server is 407 (Proxy authentication required) and not` 401 like a web server. TheWWW-Authenticateheader changes toProxy-Authenticatefor a proxy server.Authorizationchanges toProxy-AuthorizationandAuthentication-InfobecomesProxy-Authentication-Info`

Basic Authentication and security

There are several problems with Basic Authentication; you probably noticed some of them while reading this article.

Basic authentication encodes the username and password using Base-64 encoding. This is incredibly easy to decode. Have a go here!

If a third party intercepted the HTTP request being made and gained access to the username and password they could very easily have your data! To bypass this, you could use a more secure protocol, like digest authentication, or send HTTP transactions over SSL encrypted channels.

This becomes a huge concern when you realise that people tend to share or reuse passwords. You using a small unprotected internet site with basic authentication might lead to a malicious party having a username and password that could grant them access to your bank or Ashley Madison account.

Interestingly, malicious parties might not even need to decode the encoded credentials to cause trouble! There is nothing stopping them from reusing the encoded data and having access to the original servers multiple times and tampering with sensitive data.

If you want to protect sensitive data, you probably won’t rely on Basic Authentication on its own. It is worth considering alternative authentication mechanisms out there.

I hope this article provided an introduction to Basic Authentication.

Hopefully it’s a good read!

The next article will focus on Cookies.