S 4.392 Authentication for web applications

Initiation responsibility: Head of IT, IT Security Officer

Implementation responsibility: Developer, Administrator

If only a restricted group of users must be able to use a web application or parts thereof, the user must authenticate for the application. Different authentication methods can be used that are described in the safeguards S 4.176 Selection of an authentication method for web offerings and S 5.160 Authentication on web servers.

When implementing authentication mechanisms for web applications, the following items must be taken into consideration.

Requirements for the authentication component

The authentication logic should only be implemented at one location and not several times in the program code. If errors occur during authentication, the requested action should be interrupted and the query should be rejected.

The authentication component should support the procedure of forcing secure passwords according to a password policy. Requirements for secure passwords are described in safeguard S 2.11 Provisions governing the use of passwords.

Furthermore, it is recommendable to show the estimated strength of the entered password (e.g. weak, moderate, secure). This supports the user in selecting secure passwords.

In order to avoid errors in developing the authentication component, it is recommendable to implement the authentication component based on established default components (libraries or frameworks) (e.g. Enterprise Security API of OWASP).

If the web application has high protection requirements, two-factor authentication should be implemented.

For a user to be able to recognise any misuse of his user account, the web application may display the date and the time of the most recent unsuccessful and successful login procedures as a warning after the user logged in.

Remember-me feature

In order to increase the user-friendliness, the authentication data of web applications is partially stored permanently on the client of the users (e.g. in a cookie within the web browser). This option is frequently called remember-me feature If authentication data was stored to the client within the framework of the remember-me function, the data is transmitted automatically when using the web application later on. This way, the user does not have to re-enter his/her access data.

If an attacker gains access to the web browser or if a malicious code is executed on the client, this stored authentication data may be read. For this reason, this feature should not be used. If using the remember-me feature is absolutely necessary, the user should have to expressly confirm activation (opt-in). Furthermore, the user should be made aware of the risks the feature entails.

Along with the authentication data in cookies, current browsers can often store form fields (e.g. user name/password or address data) for later re-use. If a web form which the entered data was previously stored for is re-called, the browser automatically enters the data into the fields. Therefore, the "autocomplete=off" option should be configured for all form fields containing confidential data. Thereby, the browsers are instructed to not to store the data of the corresponding form fields.

Additional authentication for critical features

Once a user authentication was successful, the web application normally assigns an unambiguous session (with the help of a SessionID) to the user. The web application can use this SessionID to assign the incoming requests to the logged in users. This way, a SessionID can be deemed a kind of temporary login date with the help of which access to the sessions of logged in users is possible (see also S 4.394 Session management for web applications).

Since many attacks against the SessionID are known (see T 5.169 Inadequate session management of web applications), valid sessions being taken over cannot be ruled out completely. Therefore, re-authentication of the user (e.g. by entering the old password when the password is changed) should be required for security-critical activities (e.g. changing the password or deleting the entire database).

Limits for failed login attempts

If a user attempts to log into the web application several times at short intervals, these attempted authentications should be deemed attacks. If the number of failed attempts exceeds a defined value (e.g. five failed attempts), the user account should be blocked for a defined interval (e.g. 10 seconds). Furthermore, the intervals for blocking the user account may increase progressively with the number of failed attempts. This is to prevent the users from guessing the passwords of other users in an unauthorised manner.

When selecting the limit and the time intervals, it should be taken into consideration that this mechanism may be misused for denial-of-service attacks. An attacker may deliberately provoke the blocking of a large number of user accounts and exclude these users from using the web application this way.

Automated resetting of the authentication data

Since web applications are often used by a large group of users, the applications often offer features for automated resetting of the authentication information (password reset). This is intended to minimise the administrative efforts as far as possible if a user forgets his/her password, for example. If authentication data can be reset by unauthorised persons, the authentication mechanism can be bypassed this way. Therefore, it must be ensured that all features of a web application regarding the change of authentication data are secured at least as the primary authentication of the web application.

For example, if user authentication within the framework of the password reset process is ensured with the help of a secret question with the corresponding answer, the features should be formulated by the user. It should be pointed out that the question should not include any data that is publicly available or easy to guess. In order to increase the level of protection, several questions and answers may be specified during registration (e.g. five questions, at least three of which must be answered correctly for successful authentication).

Additionally, another security feature can be used by sending a link to an email address previously specified by the user or by sending another security token (e.g. a PIN) via SMS to a stored phone number after the questions have been answered correctly. The user may then only log in after clicking the link and/or entering the PIN.

Since it is normally difficult to return the authentication method to the same level of security of the primary authentication when resetting login information, automated resetting by the web application should be relinquished, where possible. In the event of limited groups of users for a web application (e.g. for a web application on the intranet), the password may be reset manually instead with the help of a hotline with secure authentication features and corresponding approval process, for example. The manual resetting feature should be implemented particularly in the event of high protection requirements.

Review questions:

© Federal Office for Information Security. All rights reserved.