Foreword

The authentication mechanism is the central mechanism for application defense against malicious attacks. It is on the forefront of defense against unauthorized access. If users can break through those defenses, they usually can control all the functions of the application and freely access the data stored within. Without a secure and stable authentication mechanism, other core security mechanisms (such as session management and access control) cannot be effectively implemented.

Authentication technology

The following are some common authentication mechanisms

1. Username and password login
2. Multi-factor authentication, such as composite passwords and physical tokens
3. Client SSL certificates or smart cards
4. HTTP basic and digest authentication
5. Integrating Windows authentication using NTLM or Kerberos
6. Biometric features, such as fingerprints and facial recognition
7. Verification service
8. Third-party login, OAuth is often used
9. SSO login

Design defects of verification mechanism

Compared with any other security mechanism commonly used in web applications, there are more design weaknesses in the verification function. Even in the very simple standardized model of verifying users based on usernames and passwords, the design defects are easy to lead to illegal access to the application.

The verification mechanism usually includes the following content

Login

Forgot password

Registration feature

Change password

Remember me

Password confidentiality is not strong (brute force)

Many web applications do not or rarely control the strength of user passwords. Applications often use the following forms of passwords:

• Very short or blank passwords
• Use common dictionary words as passwords
• Passwords and usernames are completely the same
• Still using default passwords
• Can be used to crack other user passwords.

Question: If the application only implements password strength rules through client controls, this is not a security issue, because ordinary users are still protected. Although cunning attackers can assign themselves fragile passwords, this usually will not pose a threat to the application.

Firstly, understand the security policy of user passwords

Currently common password policies:

1) Multi-factor authentication

2) Passwords must be 8 characters or more, including uppercase and lowercase letters, numbers, and special symbols

3) Regularly change passwords

4) Regularly match passwords to see if they have been leaked online

Therefore, the password dictionary must find passwords that meet the system password security policy for brute force attacks, and if the security policy is unknown, only common passwords can be used for brute force.

Brute force

The openness of the login function often tempts attackers to try to guess usernames and passwords, thereby obtaining unauthorized access to the application. If the application allows attackers to use different passwords to repeatedly attempt to log in until the correct password is found, it is very easy to be attacked, because even amateur attackers can manually input some common usernames and passwords in the browser

PS: The administrator password is actually more fragile than the password policy allows. They may have been set before the implementation of the password policy, or set through other applications or interfaces.

Currently, websites often use some means to limit brute force attacks, such as the following methods

1) CAPTCHA: Using CAPTCHA to determine whether a human is operating

2) Failure error locking (if implemented using client controls, it may be bypassed, and after failure locking, it is necessary to check whether the correct password and incorrect password are different)

Detailed failure information

A typical login form requires users to enter two sets of information (username and password), while some other applications may require more information (such as date of birth, place of remembrance, or PIN number). Of course, if the login attempt fails, it can be concluded that at least one set of information is incorrect. However, if the application notifies which group of information is invalid, it can significantly reduce the defensive effectiveness of the login mechanism.

Detailed error information or differences

Detailed failure information can be returned, allowing attackers to enumerate a batch of usernames that can be used for future password guessing, attacking user data or sessions, or social engineering.

Differences

Status codes, any redirects, information on the screen, and any differences hidden in the HTML page (this can be ignored for projects with separation of front-end and back-end),

The responses to valid and invalid username login attempts are completely the same, how to enumerate usernames?

Usernames can be enumerated through the time of the login request. Applications usually handle login requests differently based on whether they contain a valid username.

Certificate (credential) transmission is vulnerable

If the application uses an unencrypted HTTP connection to transmit login certificates, of course, a listener at an appropriate position on the network can intercept these certificates. Depending on the user's location, the listener may be:

❑ Within the user's local network;

❑ Within the IT department of the user;

❑ Within the ISP of the user;

❑ On the Internet backbone network;

❑ Within the ISP hosting the application;

❑ Within the IT department managing the application.

Even if HTTPS login is used, if the method of transmitting the certificate is not secure, the certificate may still be leaked to unauthorized parties

1) If certificates are transmitted through query string parameters rather than in the POST request body, many places may record these certificates, such as the user's browser history summary, web server logs, and any reverse proxies used by the host infrastructure.

2)302 Redirect. Although most web applications indeed use POST request bodies to submit HTML login forms, it is strange that applications often handle login requests by redirecting to a different URL, submitting the certificate in the form of query string parameters. We are not clear why application developers adopt this method, but it is much easier to execute a request using a 302 redirect to connect to a URL than to use another HTML form submitted through JavaScript to make a POST request.

3) Web applications sometimes store user certificates in cookies, usually for poorly designed login, password modification, and 'remember me' mechanisms. Attackers can obtain these certificates by attacking the user's cookies. If the cookies are relatively secure and reliable, they can be obtained by accessing the client's local file system. Even if the certificates are encrypted, attackers do not need the user's certificate to log in by retransmitting the cookie.

Password Modification Function

It is strange that many web applications do not allow users to change their passwords. However, for two reasons, a well-designed verification mechanism requires this function.

1) Regularly forcing password changes can reduce the possibility of a password becoming a target of password guessing attacks, and at the same time reduce the possibility of attackers using compromised passwords without detection, thereby reducing the probability of password attacks.

2) Users who suspect that their password has been compromised need to change their password immediately to reduce the probability of unauthorized use.

Although the password change feature is an essential component of an efficient verification mechanism, it is often vulnerable in design. Vulnerabilities that are deliberately avoided in the main login function often reappear in the password change feature. Many web application password change features can be accessed without verification and provide certain information to attackers or allow attackers to perform certain operations.

❑ Provide detailed error messages indicating whether the requested username is valid.

❑ Allow attackers to guess the 'Existing Password' field unlimitedly.

❑ After verifying the existing password, only check whether the values of the 'New Password' and 'Confirm New Password' fields are the same, allowing attackers to successfully determine the existing password without invasion.

Forgot Password feature

The 'Forgot Password' feature is also a frequently encountered feature, and this mechanism often introduces problems that have already been avoided in the main login function, such as username enumeration.

In addition to this defect, the design flaws of the 'Forgot Password' feature often make it the weakest link in the overall verification logic of the application.

Methods of using the 'Forgot Password' feature

1) Challenge response

2) SMS verification code

3) Email password reset link

Defect

The content of the challenge response is too simple

Unlimited challenge response

Password hints

The links sent by email can be guessed

The email address can be specified when sending a reset link

Remember Me feature

For the convenience of users and to avoid them having to re-enter their username and password each time they use the application on a specific computer, applications typically execute the 'Remember Me' feature. These features are not secure by design, making users susceptible to attacks from local and other computer users.

The principle of the 'Remember Me' feature is generally to set a session identifier in the cookie to indicate that the user has logged in before. Or record the account information of the logged-in user in the cookie.

User impersonation feature

Some applications allow privileged users to impersonate other users to access data and perform operations under the authority of that user. For example, some banking applications allow help desk operators to verbally verify a telephone user and then switch the bank's application session to the user's authority to provide assistance.

Possible defects

1) Anyone who guesses the user's forged function path can impersonate other users

2) In cookies, the userid is used to determine the user's permissions

Certificate confirmation is imperfect

A meticulously designed verification mechanism enforces various requirements for passwords, such as minimum password length and the use of both uppercase and lowercase characters. Consequently, some poorly designed verification mechanisms not only fail to enforce these best practices but also ignore the users' desire to comply with these requirements.

Possible issues

1) Truncate the password, only confirming the first n characters

2) Some applications do not perform case checking on passwords.

3) Some applications delete uncommon characters before checking the password.

Non-unique usernames

Some self-registration supporting applications allow users to specify their own usernames and do not require users to use unique usernames. Although such applications are extremely rare, we have still seen several of this type of application.

Defect

1) During the registration stage or during the process of changing the password, two users sharing the same username may accidentally choose the same password. If this happens, the application may either reject the password chosen by the second user or allow two accounts to use the same certificate. If the former is the case, the application will leak another user's certificate to one user; if the latter, one user logging in will access the account of the other user.

2) Even if it is impossible to implement this attack elsewhere due to limitations on the number of login failure attempts, attackers can still successfully carry out brute force attacks. Attackers can use different passwords, repeatedly register with a special username, while monitoring the different responses for accounts that already exist using that username and password. The attacker does not need to attempt any login with the target user to obtain the user's password.

Predictable usernames

Some applications automatically generate account usernames according to a predictable sequence (such as cust5331, cust5332). If the application operates in this way, an attacker who understands the sequence of usernames can quickly obtain all valid usernames, using them as a basis for subsequent attacks. Unlike the enumeration method that relies on continuously submitting requests driven by vocabulary, this method of determining usernames does not require any intrusion and rarely causes interference to the application.

Predictable initial passwords

Some applications create users in batches or all at once, and automatically specify initial passwords, then distribute the passwords to all users in some way. This method of generating passwords allows attackers to predict the passwords of other application users. Corporate applications based on internal networks often have this vulnerability. For example, the application creates an account for each employee and sends a printed password notification to them.

Insecure certificate distribution

Many applications do not allocate certificates for new accounts during the normal interaction process between users and the application (such as through mailing or email). Sometimes, this distribution method is mainly for security considerations, such as ensuring that the mailing or email address provided by the user is their own.

Example of a problem:

The activation URL sent for the account can be guessed.

The email sent for the account does not have a time limit set and does not require users to change the initial password, which may lead to others obtaining the account information.