2.3 Basic authentication
2.3 Basic authentication
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 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 file index.html that 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 .htaccess in 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, the WWW-Authenticate header 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 return Date , 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 and test in this example), the browser resends the HTTP request message that now carries an additional Authorization header (if the server were an HTTP proxy server, the browser would resend an HTTP request message with a Proxy-Authorization header). In our example, the Authorization header may look as follows :
Authorization: Basic cm9sZjp0ZXN0
Figure 2.1: The Internet Explorer 5.5 ˜Enter Network Password prompt using the HTTP basic authentication scheme. ( 2002 Microsoft Corporation.)
Figure 2.2: The Opera 6.0 ˜Password required prompt using the HTTP basic authentication scheme. ( 2002 Opera Software.)
The value cm9sZjp0ZXN0 refers 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:
-
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 is 726F6C663A74657374 (each pair of hexademical values represents one ASCII character). Alternatively, the string of hexademical values may also be written as a bit string:
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
-
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 -
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 substring 011100 refers 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 letter m in 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
1C
26
3D
2C
19
23
c
m
9
s
Z
j
101001
110100
011001
010111
001101
110100
41
52
25
23
13
52
29
34
19
17
D
34
p
O
Z
X
N
O
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
+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
/
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 cm9sZjp0ZXN0 and this string may serve as authentication information in the HTTP basic authentication scheme. Another example is given in [7]. The interested reader is invited to follow the abovementioned 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 the first time). In order to make that transparent to the user, browsers usually cache the usernames and passwords and retransmit them automatically 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 clear [7] (or in Base-64-encoded form) for every single request. As such, they are exposed to eavesdropping and replay attacks.
[6] The Base-64 encoding scheme is explained, for example, in Chapter 2 of [8].
[7] This is similar to many other TCP/IP application protocols that lack strong user authentication, such as Telnet and FTP.
EAN: 2147483647
Pages: 142