Authentication Guidelines - Developer's Perspective

Most developers should be familiar with authentication. Routine weak password issues and authentication-related vulnerabilities arise frequently. Today, I am mainly looking at how to ensure secure development for authentication from the perspective of research and development, or how to select appropriate authentication scenarios to ensure the security of application system authentication.

Authentication is the process of verifying whether an individual, entity, or website is consistent with the identity claimed. Common scenarios involve verification through submission of username or ID and password. After authentication, interaction management is conducted through sessions. Session management is the process by which the server maintains the state of entities with which it interacts. This is essential for the server to remember how to respond to subsequent requests in the transaction process. Sessions are maintained through session identifiers on the server, which can be passed back and forth between the client and server during the transmission and reception of requests. Sessions should be unique for each user and difficult to predict.

AuthenticationGuidelines - Developer's Perspective

User ID

Ensure that usernames/user IDs are case-insensitive. Users 'smith' and 'Smith' should be considered the same user. Usernames should also be unique. For applications with high security requirements, usernames should be assigned and kept confidential by the system, rather than being publicly customizable data set by the users.

Authentication Solutions and Sensitive Accounts

• It is not allowed to log in to any front-end user interface using sensitive accounts (i.e., internal accounts such as those used for backend/middleware/database).

Implement password strength control

Weak password issues arise frequently. It is necessary to enforce password policies at the application layer to reduce the risk of users setting weak passwords. Specific characteristics are as follows:

Password Length

• The application should enforce the minimum password length. It should be no less than 8 characters.
• The application should enforce the maximum password length. It should not exceed 64 characters, as passwords longer than 64 characters may be susceptible to long password denial-of-service attacks.

Do not silently truncate passwords

Allow the use of all characters, including Unicode and spaces

• There should not be password composition rules that limit the allowed character types.

Implement a secure password recovery mechanism

Applications usually have a mechanism that provides users with a way to access their account when they forget their password.

Securely store passwords

The application uses the correct encryption technology to store passwords, which is complex and will be explained in a special topic later.

Use secure functions to compare password hashes

Use the secure password comparison functions provided by the language or framework to compare the password entered by the user with the stored password hash, for example, the `password_verify()` function in PHP. Make sure that the comparison function:

• Has the maximum input length to prevent denial of service attacks caused by very long inputs.
• Explicitly set the types of two variables to prevent type confusion attacks such as magic quotes in PHP.
• Returns in constant time to prevent timing attacks.

Only through TLS-level encryptionTransmission method transmits password

Sensitive features require re-authentication

To prevent CSRF attacks and session hijacking, re-enter the current account credentials for secondary verification before updating sensitive account information (such as user password, user email) or performing sensitive transactions. It is common to verify the old password when changing passwords. Without this measure, attackers may be able to execute sensitive transactions through CSRF or XSS attacks without knowing the user's current credentials. In addition, attackers may take over the user's session by temporarily accessing the user's browser physically or by stealing their session ID.

Two-factor authentication

The application should use two-factor authentication for sensitive operations. For example, a second verification is required when logging in from a new or untrusted device.

Authentication and error messages

In the case of authentication functionality, if the error message implementation is incorrect, it can be used for user ID and password enumeration. The application should respond to the following situations using general error messages (including HTTP and HTML):

• User ID or password is incorrect.
• Account does not exist.
• Account is locked or disabled.

The account registration feature should also be considered. For existing users, the same general error message method can be applied to prevent attackers from performing user enumeration operations on the application.

However, the business logic itself may introduce factors related to processing time. In fact, depending on the implementation, processing time may vary significantly in different situations (success and failure), such as time-based attacks by attackers (for example, a few seconds difference).

Example of login functionality using pseudocode:

The first implementation uses the 'quick exit' method

```plaintext

IF USER_EXISTS(username) THEN

password_hash=HASH(password)

IS_VALID=LOOKUP_