As mentioned above, the HTTP basic authentication scheme implements password-based authentication to protect and to control access to the resources of a server. The server, in turn, may be a Web server or an HTTP proxy server. The HTTP basic authentication scheme works similarly for both types of servers. As of this writing, the scheme is supported by all major browser and server software packages. On the client side, the scheme is supported by, for example, Netscape Navigator, Microsoft’s Internet Explorer, and Opera. On the server side, the scheme is supported by almost all software packages, including, for example, Microsoft IIS and Apache.
If a browser requests a resource that is protected with the HTTP basic authentication scheme, the server challenges the browser to provide some valid authentication information (typically a username and a password). This is equally true for Web servers and HTTP proxy servers. The browser either remembers the authentication information from a previous HTTP I¨session, or prompts the user to type in that information. In either case, the browser forwards the information to the server in the clear (this fact represents the most serious weakness and vulnerability of the HTTP basic authentication scheme).
For example, let us assume that a user wants his or her browser to retrieve the fileindex.htmlthat is located in the protected directory/Demo/ HTTPBasicAuthentication/ at www.esecurity.ch. At first sight, the browser does not know that this file is protected with the HTTP basic authentication scheme. So it sends out a normal-looking HTTP request message. Remember from our previous discussions that such a message may start with the following request line:
GET http://www.esecurity.ch/Demo/HTTPBasicAuthentication/HTTP/ 1.0 All other HTTP request headers basically remain the same. After having received the HTTP request message, the Web server recognizes that the requested file is located in a directory that is protected with the HTTP basic authentication scheme. As further explained below, the server recognizes that the file is protected because it is located in a directory that contains a specific file (i.e., the file.htaccessin the case of an Apache Web server). Instead of directly returning the requested file, the server generates an HTTP response message that includes the following two characteristic lines:
HTTP/1.0 401 Unauthorized ...
WWW-Authenticate: Basic realm="HTTP Basic Authentication Demo"
The first line informs the browser that the server has not been able to serve the request because the browser did not provide valid credentials. In our example, the status code 401 (i.e., ‘‘Unauthorized’’) reveals the fact that the server is a Web server (note that it could also be an HTTP proxy server). In the second line, theWWW-Authenticateheader requests user credentials for the realm named ‘‘Basic Authentication Demo.’’
If the server were an HTTP proxy server, the HTTP response message would have the following two characteristic lines:
HTTP/1.0 407 Proxy Authentication Required ...
Proxy-Authenticate: Basic realm="HTTP Basic Authentication Demo" Everything else would remain the same. In either case, the server may also returnDate, Server, and possibly some other HTTP response headers. These headers are neither illustrated above nor discussed below (they are not very relevant from a security point of view).
The HTTP response message is received by the browser and the user is prompted to enter his or her password accordingly. For the server being a Web server, Figures 2.1 and 2.2 illustrate the prompts used by Microsoft’s Internet Explorer and Opera. If the user obeys and properly enters his or her username and password (i.e.,rolf andtestin this example), the browser resends the HTTP request message that now carries an additional
Figure 2.1 The Internet Explorer 5.5 ‘Enter Network Password’ prompt using the HTTP basic authentication scheme. (q2002 Microsoft Corporation.)
Authorization header (if the server were an HTTP proxy server, the browser would resend an HTTP request message with a Proxy-Authoriza- tion header). In our example, the Authorization header may look as follows:
Authorization: Basic cm9sZjp0ZXN0
The valuecm9sZjp0ZXN0refers to the user’s authentication information (i.e., the username and password separated with a colon) encoded using the Base-64 encoding scheme.6 This basically works as follows:
1. Each character of the complete authentication information (i.e., rolf:test) is converted to its ASCII value (according to Table 2.1). The resulting string of hexademical values is726F6C663A74657374 (each pair of hexademical values represents one ASCII character). Alternatively, the string of hexademical values may also be written as a bit string:
Figure 2.2 The Opera 6.0 ‘Password required’ prompt using the HTTP basic authentication scheme. (q2002 Opera Software.)
6. The Base-64 encoding scheme is explained, for example, in Chapter 2 of [8].
7 2 6 F 6 C 6 6 3 0111 0010 0110 1111 0110 1100 0110 0110 0011
A 7 4 6 5 7 3 7 4
1010 0111 0100 0110 0101 0111 0011 0111 0100
2. The bit string is rearranged and split into groups of six bits each.
011100 100110 111101 101100 011001 100011 101001 110100 011001 010111 001101 110100
3. Each group of six bits is represented by a new character in the Base- 64 encoding scheme (according to Table 2.2). For example, the first substring011100refers to the decimal value 28 or the hexadecimal value 1C. Referring to Table 2.2, this value is represented by the letter c in the Base-64 encoding scheme. Similarly, the second substring 100110 refers to the decimal value 38 or hexadecimal value 26, and this value is represented by the lettermin the Base-64 encoding scheme. The resulting string can be constructed as follows:
011100 100110 111101 101100 011001 100011
28 38 61 44 25 35
1C26 3D 2C19 23
c m 9 s Z j
Table 2.1 ASCII Characters with Hexadecimal Values
0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 +0 NUL DLE 0 @ P ‘ p +1 SOH DC1 ! 1 A Q a q +2 STX DC2 " 2 B R b r +3 ETX DC3 # 3 C S c s +4 EOT DC4 4 D T d t +5 ENQ NAK % 5 E U e u +6 ACK SYN & 6 F V f v +7 BEL ETB ’ 7 G W g w +8 BS CAN ( 8 H X h x +9 HT EM ) 9 I Y i y +A LF SUB * : J Z j z +B VT ESC + ; K [ k { +C FF FS , < L \ l | +D CR GS - = M ] m } +E SO RS . > N ^ n +F SI US / ? O _ o DEL 32 HTTP Security
101001 110100 011001 010111 001101 110100
41 52 25 23 13 52
29 34 19 17 D 34
p O Z X N O
The first line represents the groups of six bits. The second and third line represent the corresponding decimal and hexadecimal values, whereas the fourth line represents the corresponding charcaters in the Base-64 encoding scheme. Consequently, the resulting string is cm9sZjp0ZXN0and this string may serve as authentication informa- tion in the HTTP basic authentication scheme. Another example is given in [7]. The interested reader is invited to follow the above- mentioned steps to encode an arbitrary username and password pair, and to verify the correctness of his or her encoding result using a Web browser and a network monitoring tool.
In spite of the fact that the authentication information (i.e., the username and password separated with a colon) is Base-64-encoded, there is nothing that protects it against passive eavesdropping. In fact, anyone who intercepts the HTTP request message that is sent from the browser to the server can obtain the authentication information, decode the username and password (according to the Base-64 decoding scheme), and (mis)use this information illegitimately. To make things worse, HTTP is stateless and the browser reauthenticates itself each time it contacts the server (not just
Table 2.2 Characters Used in the Base-64 Encoding Scheme 0x00 0x10 0x20 0x30 +0 A Q g w +1 B R h x +2 C S i y +3 D T j z +4 E U k 0 +5 F V l 1 +6 G W m 2 +7 H X n 3 +8 I Y o 4 +9 J Z p 5 +A K a q 6 +B L b r 7 +C M c s 8 +D N d t 9 +E O e u + +F P f v / 2.3 Basic authentication 33
the first time). In order to make that transparent to the user, browsers usually cache the usernames and passwords and retransmit them auto- matically each time they contact the server. This is convenient but also causes many password transmissions that are transparent and ‘‘invisible’’ to the user (unfortunately, these retransmissions are not ‘‘invisible’’ for a passive attacker). More worrisome, it is generally not possible to log out an authenticated ‘‘HTTP session.’’ This would require the browser to forget about the relevant user credentials. This is currently not a supported feature in most browsers. Last but not least, the most recent versions of some browsers provide the feature to remember a password forever, so that a user never has to type in the password again. As illustrated in Figure 2.1, this ability can be activated in Microsoft’s Internet Explorer by employing the checkbox entitled ‘‘Save this password in your password list.’’ From a security point of view, this feature is highly debatable. It is, however, convenient for the user and simplifies the user experience considerably. That’s why people use it.
In summary, the HTTP basic authentication scheme is not secure. Although the passwords are stored on the server in encrypted form, they are passed from the browsers to the server in the clear7(or in Base-64-encoded form) for every single request. As such, they are exposed to eavesdropping and replay attacks.