HTTP Basic Authentication

This method of authentication is based on the HTTP specification.

According to HTTP, the authentication is done as follows : If a user didn't enter a password or entered a wrong one, the server sends the 401 Unauthorized header. If the browser receives this information as a response to an HTTP request, it should display a dialog box suggesting that the user enter a login and a password. After the user enters the login and password, the browser should repeat the HTTP request, sending the login and password to the server.

The server should check the login and the password once more, and either give the user access to the service or again respond with the 401 Unauthorized header. The header will mean that the login, the password, or both are invalid.

The browser should send the login and password to all documents located in the same Web folder or all subfolders until the user terminates the session.

Here is a sample dialog between the client and the server when performing HTTP Basic authentication:

 C> GET /admin/ HTTP/1.1 C> Host: www.site.ru C> User-Agent: Mozilla/5.0 (Windows NT 5.0; en-US; rv:1.7.1 Gecko/20040707 C> Accept: */* C> Accept-Language: en-us C> Accept-Encoding: gzip, deflate C> Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 C> Keep-Alive: 3000 C> Connection: keep-alive C> <empty line> S> HTTP/1.1 401 Authorization Required S> Date: Fri, 05 Nov 2004 13:21:23 GMT S> Server: Apache S> WWW-Authenticate: Basic realm="admin zone" S> Keep-Alive: timeout=15, max=50 S> Connection: keep-alive S> Transfer-Encoding: chunked S> Content-Type: text/html; charset=iso-8859-1 S> <empty line> S> Sorry, authorization is required. C> GET /admin/ HTTP/1.1 C> Host: www.site.ru C> User-Agent: Mozilla/5.0 (Windows NT 5.0; en-US; rv:1.7.1) Gecko/20040707 C> Accept: */* C> Accept-Language: en-us C> Accept-Encoding: gzip, deflate C> Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 C> Keep-Alive: 3000 C> Connection: keep-alive C> Authorization: Basic dXNlcjplc2VycGFs C> <empty line> S> HTTP/1.1 401 Authorization Required S> Date: Fri, 05 Nov 2004 13:21:23 GMT S> Server: Apache S> WWW-Authenticate: Basic realm="admin zone" S> Keep-Alive: timeout=15, max=50 S> Connection: keep-alive S> Transfer-Encoding: chunked S> Content-Type: text/html; charset=iso-8859-1 S> <empty line> S> Sorry, authorization is required. C> GET /admin/ HTTP/1.1 C> Host: www.site.ru C> User-Agent: Mozilla/5.0 (Windows NT 5.0; en-US; rv:1.7.1) Gecko/20040707 C> Accept: */* C> Accept-Language: en-us C> Accept-Encoding: gzip, deflate C> Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 C> Keep-Alive: 3000 C> Connection: keep-alive C> Authorization: Basic dXNlcjplc2VycGFz C> <empty line> S> HTTP/1.1 200 OK S> Date: Fri, 05 Nov 2004 13:31:54 GMT S> Server: Apache S> Keep-Alive: timeout=15, max=50 S> Connection: keep-alive S> Transfer-Encoding: chunked S> Content-Type: text/html S> <empty line> S> Thank you, authorization is successful. C> GET /admin/2/admin.php HTTP/1.1 C> Host: www.site.ru C> User-Agent: Mozilla/5.0 (Windows NT 5.0; en-US; rv:1.7.1) Gecko/20040707 C> Accept: */* C> Accept-Language: en-us C> Accept-Encoding: gzip, deflate C> Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 C> Keep-Alive: 3000 C> Connection: keep-alive C> Authorization: Basic dXNlcjplc2VycGFz C> <empty line> S> HTTP/1.1 200 OK S> Date: Fri, 05 Nov 2004 13:31:54 GMT S> Server: Apache S> Keep-Alive: timeout=15, max=50 S> Connection: keep-alive S> Transfer-Encoding: chunked S> Content-Type: text/html S> <empty line> S> Here authorization is also OK. C> GET /news/id.php HTTP/1.1 C> Host: www.site.ru C> User-Agent: Mozilla/5.0 (Windows NT 5.0; en-US; rv:1.7.1) Gecko/20040707 C> Accept: */* C> Accept-Language: en-us C> Accept-Encoding: gzip, deflate C> Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 C> Keep-Alive: 3000 C> Connection: keep-alive C> <empty line> S> HTTP/1.1 200 OK S> Date: Fri, 05 Nov 2004 13:31:54 GMT S> Server: Apache S> Keep-Alive: timeout=15, max=50 S> Connection: keep-alive S> Transfer-Encoding: chunked S> Content-Type: text/html S> <empty line> S> <data> C> GET /index.html HTTP/1.1 C> Host: www.site.ru C> User-Agent: Mozilla/5.0 (Windows NT 5.0; en-US; rv:1.7.1) Gecko/20040707 C> Accept: */* C> Accept-Language: en-us C> Accept-Encoding: gzip, deflate C> Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 C> Keep-Alive: 3000 C> Connection: keep-alive C> Authorization: Basic dXNlcjplc2VycGFz C> <empty line> S> HTTP/1.1 200 OK S> Date: Fri, 05 Nov 2004 13:31:54 GMT S> Server: Apache S> Keep-Alive: timeout=15, max=50 S> Connection: keep-alive S> Transfer-Encoding: chunked S> Content-Type: text/html S> <empty line> S> <the contents of the main page> S> Thank you, here authorization is also OK. 

Here is what happens during the dialog: At the beginning, the client visits the http://www.site.ru/admin/ page. To access this page, a login and a password are required; therefore, the server responds with the 401 header, meaning that authentication is required. Having received this header, the browser displays a dialog box suggesting that the user enter a login and a password. In this example, the user enters user and userpal , respectively. The password is invalid: The last letter is wrong.

The login and the password are concatenated with a colon as a delimiter , encoded with the base64 algorithm, and sent in the Authorization header with the authorization type. In other words, the following header is sent:

 Authorization: basic base64(<user>:<pass>) 

Although it seems difficult to understand the login and password, base64 is a revertible encoding algorithm, and the string can be easy decoded with appropriate tools. For example, some programming languages include the base64_decode() function.

To respond to the invalid password, the server sends another 401 header, meaning that authentication is required. Having received this header, the browser again asks the user to enter the login and password. This time the user enters the correct data: user and userpas . The server's response is 200 , meaning the document has been found, and the browser displays the contents of the document.

Then the user moves to a subfolder of the admin folder, and the browser automatically passes this document the login and the password. It would pass them to a document in the same folder if the user requested it.

Then the user requests a document from another folder. When accessing another folder or a subfolder of the current folder, the browser doesn't send the login and the password.

I have described how the system works on the client side. Now, you're about to read how this type of authentication works on the server side.

On the server, authentication can be arranged in either of two ways: You can send necessary headers using scripts and use the same or other scripts to check the received data, or you can use HTTP server methods .

Consider an example of performing HTTP Basic authentication in PHP scripts.

http://localhost/4/1.php

 <? function myauth($login, $pass) {   if($iser=='admin' && $pass=='adminpass') return 5;   if($iser=='user' && $pass=='user1pass') return 1;   return 0; } $login=$_SERVER['PHP_AUTH_USER']; $pass =$_SERVER['PHP_AUTH_PW']; if(($access=myauth($login, $pass)) == 0) {  header("WWW-Authenticate: Basic realm=\"Admin Zone\"");  header("HTTP/1.0 401 Unauthorized");  echo "You don't have access rights to the private part of the server!";  exit; } echo "Your access level is $access"; ?> 

In this example, the myauth() function is responsible for authentication and authorization. Authorization is a matter of giving an authorized user an ID denoting an access level. A zero access level means authentication wasn't successful, and the server sends the 401 header to the browser.

The myauth() function can compare the received data with data in a table and perform other operations required for authentication. For example, logins and the hashes of passwords can be stored in a database, and the myauth() function can send a query to the database to authenticate the user and give him or her an access level.

As a variation of this approach, you can give the user a guest access level with minor rights if authentication wasn't successful. However, a legitimate user should be able to log into the system. For this purpose, one of scripts should contain an output of the 401 header for an authenticated user and the authentication procedure. After one of the scripts fulfils authentication successfully, the browser will send the login and the password to each script in the same folder or its subfolders. Based on this information, the system will give the user a guest or authorized access to documents.

This approach has both advantages and disadvantages. The advantages are the following:

• If the user doesn't check the Remember the password checkbox, no information on the password will be stored on the client's hard disk. However, this is just a theoretical statement because much depends on the particular browser used.

• This system allows you to store password hashes rather than the passwords themselves on the server.

• By default, logins and passwords aren't saved in the server's log files and on proxy servers.

The system also has a few disadvantages partially related to its advantages:

• The login and the password are sent unencrypted. Theoretically, they can be stolen on an enemy proxy server or with a program such as sniffer in the user's network segment. These problems can be solved by encrypting the traffic and sending it using HTTPS.

• If a user checks the Remember the password checkbox, the password will be stored on the hard disk in an unencrypted form.

In addition, in some cases another danger appears. If you use this method to protect one document (or a few documents in one folder), and this folder or its subfolders contain documents (or scripts) available to an attacker, the browser will send the login and the password to these scripts in the same session when the attacker accesses the protected document.

For example, suppose the http://www.site.ru/admin.php file is protected with HTTP Basic authentication. In addition, there are a few folders, such as http://www.site.ru/kolja/ and http://www.site.ru/vasja/ , and authorized users can access them.

Suppose that the site administrator visits the http://www.site.ru/admin.php page, obtains administrator privileges, and does his or her job. Also suppose that the site administrator visits the page of one of the users (e.g., http://www.site.ru/kolja/test.php ) in the same browser session. As a result of this visit, the administrator's login and password that allow him or her to access  admin.php will be transparently sent to the  TEST.PHP script entirely available to the kolja user.

This is how the administrator's password can leak through a hole in the system to a malicious user without the administrator's knowledge.

When this vulnerability takes place, a malicious user needs to create a script that would be entirely under his or her control and would store all logins and passwords it receives during HTTP Basic authentication. After that, the malicious user should stealthily place a link to the administrator and just wait. If possible, this user should arrange that the administrator obtains the link only after he or she logs into the system.

For example, if the user can send the administrator messages that the administrator will read using the Web interface, the user should send a message suggesting that the administrator follow that link.

HTTP Basic authentication can be implemented using HTTP methods on the server.

For example, it is easy to implement HTTP Basic authentication using the built-in tools of the Apache HTTP server. To do this, locate the  .htaccess file in a protected folder. The file should look like this:

 .htaccess

 order allow,deny allow from all require valid-user AuthName "admin zone" AuthType Basic AuthUserFile /path/to/.htpasswd 

The /path/to/.htpasswd file contains logins and password hashes. To create a file with passwords, enter the following command:

 htpasswd -c /path/to/.htpasswd username 

Then enter a password twice. The /path/to/.htpasswd file will be created automatically. To add a new user to an existing file or change the password of a user in the file, enter the following command:

 htpasswd /path/to/.htpasswd username 

Then enter the new password twice.

If the user's account doesn't exist, it will be added to the file. Otherwise, the user's password will be changed.

The /path/to/.htpasswd file doesn't contain unencrypted passwords. Rather, it stores their hashes. This file can look like follows:

/path/to/.htpasswd

 admin:24nN.4cqs18hE user1:zP0ggTOuNcxwc user2:HfVn3BhVdnuiA 

This file contains the passwords of three users. The name of the /path/to/.htpasswd file doesn't have to begin with a period; you can name the file as you like.

This system will have the following advantages:

• The system is simple in implementation.

• The implementation can be transparent for protected documents and services.

• The system doesn't pass passwords to strange scripts because an entire folder is protected with a password, not individual files.

• The server stores password hashes rather than passwords.

It also has the following disadvantages:

• Passwords are sent unencrypted every time a user accesses protected documents or services.

• Sometimes, a user's password can be found on his or her computer's hard disk.

• Password hashes are stored in a file on the server, and a local user with access to this file can try to find passwords from these hashes.

You could make the file with passwords available for reading only to the Web server, that is, to the user who started this Web server. At first glance, this would seem to protect against the password leakage.

However, because this file is available for reading to the Web server, it will be available for reading to any script started by this Web server and possessing the server's access rights. In other words, if a local user doesn't have access to the file with password hashes but has a right to write into a folder available using HTTP, that user can create a malicious script that is able to read and return to him or her the contents of the file with passwords accessed using HTTP.

In addition, it is a common error that files with the hashes of passwords to a protected part of the system are put into a folder accessible using HTTP. In this case, a malicious user can read the file directly by requesting its URL, for example, http://www.site.ru/.htpasswd . When this file is located in a directory accessible from the Web, you should make sure it isn't accessible using HTTP.

As a variant of this solution, you can put the file in the same protected directory. As a result, an unauthorized user won't be able to access this file. However, an authorized user is likely to access this file using HTTP. Therefore, a malicious authorized user can read this file and try to find other users' passwords.

In a correctly designed system, no information on the users' passwords should be available to other users, including legitimate ones.

The contents of files with logins and password hashes are always available to the user who started the HTTP server. However, it can also be available to a remote user if the server has a vulnerability allowing him or her to read any files.

In PHP, there is such a vulnerability. Local PHP source code injection makes it possible to inject this file as a PHP code and output its contents.

Built-in features of the Apache Web server that implement HTTP Basic authentication allow more than just one or another user to access the system. Not only can each user from the htpasswd list log into the system, but so can users listed in the . htaccess file. In addition, users can be divided into groups and can gain access rights depending on the group , to which they belong.

This is how access to various resources, services, and documents can be granted to different users. In addition, this partially solves the task of authorization.

Remember that this approach will work only if global settings on the HTTP Apache server allow you to use . htaccess files.