S 4.176 Selection of an authentication method for web offerings

Initiation responsibility: IT Security Officer, Head of IT

Implementation responsibility: Administrator

For e-Commerce and e-Government applications, personal web offerings or for realising access restrictions to specific areas of a web offering generally, mechanisms to identify and authenticate different users are required.

Depending on the specific requirements regarding the protection of information against unauthorised access and the authentication quality, an appropriate method must be selected. The selection of the authentication method and the reasons on which this selection was based should be documented.

HTTP authentication methods

The HTTP/1.1 log offers two different methods for user authentication.

The first method is basic access authentication. Here, the client sends the user name and the password Base64-coded in the Authorization Header of the HTTP requests to the server. Base64 is a method to encode binary data in 7-bit ASCII, used to transmit special characters via the HTTP interface. Thus, it is not possible to read the password at first glance, but it can be determined by a potential "eavesdropper" without any problems, as it is not encrypted. Thus, this authentication type can at best be used for very low confidentiality requirements.

The second method for HTTP authentication is digest authentication. For this type of authentication, the user's password must be available on the server. The server assigns a random string, referred to as challenge, to the client. Based on this challenge and the user's password, the client complying with a standardised procedure computes a digest which is then sent to the server for authentication. As the server is provided both with the generated access string and the user's password, it is also able to compute the digest and to perform the authentication. Since the password is not sent via the network in the event of digest authentication, this method is appropriate for slightly higher protection requirements.

When using the authentication methods referred to above, the security of the password data on the server is a problem: When using digest authentication, the users' authentication data must be available as plain text on the web server. When using basic authentication, a hash value of the password is stored in most cases. Protecting the password files on the server against unauthorised access is thus of particular importance.

In addition to HTTP authentication, there is another way to implement access control using the HTTP: the authentication cannot be performed using the web server itself, but using a server-side application. In this case, the user name and password are entered using normal HTML forms and checked by the application. This method is often realised for offerings on the Internet. However, it should always be taken into account that passwords or PINs which are transmitted as plain text via the Internet can be easily read by third parties. In addition, all data, even if they are delivered as response to authenticated requests, are, of course, transmitted in unencrypted form.

Some web offerings identify the users by means of special cookies which are stored in the browser. As cookies are also transmitted as plain text when using HTTP, this method is not suitable either for the authentication when accessing information worthy of protection. Since there are other security problems in connection with cookies, this method should not be used in general.

Use of SSL

If there are higher requirements regarding the security of the authentication and the confidentiality of the transmitted data within the framework of e-Government or e-Commerce offerings, then the transmission should be protected using SSL (see also S 5.66 Use of SSL).

When using SSL, there are two different operating modes: When applying the first version, only the server has a certificate. This helps the users to recognise that they are really connected to the "correct" server and allows the secure transmission of authentication information and application data after an encrypted connection has been established.

In addition to the name of the certificate authority, a server certificate also includes the name of the server for which it is valid. It can be issued by a root certificate authority (Root-CA) or generated in the organisation itself, for example using the tools included in the OpenSSL package.

Certificates that were not issued by a root certificate authority known by the user are, in most cases, not simply accepted by the browser, and the user must confirm explicitly that the respective certificate is to be accepted.

When applying the second version, the user, too, has a certificate that must be available on the client computer. The browser then sends this certificate to the server for authentication. However, the prerequisite for this is that the certificate authorities whose certificates are used are trustworthy. The fact that this authentication method is not used more often in practice is due to the effort required for the implementation of such a solution. The server-side configuration is relatively easy: In addition to the configuration of the web server for SSL, a SSL server certificate must be purchased and implemented. The effort required for each individual user, however, is relatively high: Every user must have a SSL-client certificate that is installed in the user's browser in each case. This results in a certain restriction in terms of convenience, as one of the major advantages of the normal web server use is precisely that access can be gained from virtually any computer. If client certificates are used for authentication, this flexibility is restricted to a significant extent, because the client certificate is often not available universally. On the other hand, this might be precisely desired in specific situations, for example when using an Intranet web server.

A user authentication method frequently used for web offerings is the combination consisting of form-based authentication and SSL-encrypted data transmission. When the chosen SSL-encryption is adequately strong, this method offers, with a considerable amount of effort (user administration in the web application and implementation of SSL-secured access to the web server) a security level which is appropriate also for higher security requirements.

In S 5.160 Authentication on web servers, the different user authentication options for web servers are presented and summarised in the following table:

Method Security level Implementation effort Server requirements Comments
Standard authentication Low Low User administration Authentication information and data are transmitted in unencrypted form!
Form-based authentication without secure transmission Low Low to Medium Implementation in the respective application Authentication information and data are transmitted in unencrypted form!
Digest authentication Medium Low User administration Data is transmitted in unencrypted form.
Form-based authentication via SSL High Medium to High SSL support in the server, implementation in the respective application Authentication information and data are transmitted in encrypted form!
Certificate-based authentication via SSL High to Very High High to Very High Installation of server certificates. Certificate management, public key infrastructure. Is primarily used for secure transactions via the Internet.

Table: User authentication for web servers

In addition, the Microsoft Internet Information Server offers another method using the Windows user login. However, this method only functions properly using the Microsoft Internet Explorer as client.

When establishing a SSL connection, the encryption mode to be used is negotiated between client and server. The algorithms available also include those which can no longer be considered secure. In particular, there is also the zero-encryption mode available, in which no encryption is carried out. For the SSL configuration of the web server, it must be ensured that the server does not accept any of the weak algorithms and the zero-encryption mode in particular. Otherwise, it could also occur that an apparently secure connection is established (https is used), whose encryption, however, is in fact too weak or which is not encrypted at all. Such a situation could be created deliberately by an attacker to eavesdrop authentication information and other data. Thus, using the zero-encryption mode and weak algorithms should be disabled in the SSL configuration of the web server.

Review questions:

© Federal Office for Information Security. All rights reserved.