Basic principles for identity authentication Design

Basic principles for identity authentication DesignPassword length and complexity policies

Password Authentication is currently the most popular authentication method. The most important factor in security is the length of the password. A high-intensity password increases the difficulty of manual speculation or brute-force password cracking. Some features of high-strength passwords are defined below.

(1) password length

For important applications, the minimum password length is 6; for key applications, the minimum password length is 8; for those most critical applications, multi-factor authentication systems should be considered.

(2) Password Complexity

Sometimes it is not enough to have only the length constraints. For example, a password like 12345678 or 11111111 is indeed 8 characters long, but it is very easy to be guessed and dictionary attacked. Therefore, the password complexity needs to be increased at this time. The following lists some strategies that provide complexity.

-At least one uppercase letter (~ Z ).

-At least one lowercase letter (~ Z ).

-At least one number (0 ~ 9 ).

-At least one special character (! @ # $ % ^ & Etc ).

-Defines the minimum password length (for example, 8 characters ).

-Defines the maximum password length (for example, 16 characters ).

-Continuous characters (such as 123, ABC, and DEF) are not allowed ).

-Continuous identical characters (such as 1111) are not allowed ).

Once these policies are defined, users can be forced to enter high-intensity passwords during user registration to improve the security of passwords.

Implement a secure password recovery policy

The last section describes the length and complexity of the password. Sometimes, the password is too complex to forget. What should I do? Therefore, an application provides password restoration. Since most applications provide the restore method for the unique field of email, the most common way is to allow the user to enter the email address. after entering the email address, generally, there are two solutions.

(1) send the original password to the user's mailbox.

My personal opinion is that, if this is done, this application can learn your password in plaintext, which is contrary to the single policy that only stores hash/encryption values in the system, if the database of this program is conquered on any day, all the plain text will be easily known, so this method is not worth advocating.

(2) reset a temporary password. Use this password to log on and change the password.

This is a relatively good method. Generally, to increase security, we can also give this temporary password a validity period, for example, the user must use this password to log on within 24 hours.

The above password recovery policy is based on the fact that your email address should be safe enough (no one knows your email password ). However, if the application has a csrf vulnerability, that is, the email may be changed to an attacker's email address, but the victim is unknown, the password will be sent to the attacker's mailbox if the password is restored, so what should we do?

The answer is that you need to authenticate the key fields when updating them. For example, the user's password and email. If the user needs to update the password, a dialog box is displayed asking the user to enter the original password, which effectively prevents csrf attacks.

Important operations should be transmitted over https

Important operations, such as logon and password modification, must be transmitted over HTTPS. Take Tomcat as an example to describe how to configure so that the specified URL must go through HTTPS.

First, generate a certificate. For convenience, we use the keytool provided by Java to generate a self-authentication certificate. The command is as follows: % java_home % \ bin \ keytool-genkey-alias
Tomcat-keyalg RSA. Then, answer some questions. Pay attention to setting the password of the certificate library and the password of the key. Here we set it to changeit, and a certificate library will be generated, as shown in 10-22.

Figure 10-22 generate a certificate library using Java

Then, copy the generated. keystore to the {tomcat_home} \ conf directory and configure Server. XML as follows:

<Connector protocol = "org. Apache. Coyote. http11.http11nioprotocol"

Port = & quot; 8443 & quot; sslenabled = & quot; true & quot"

Maxthreads = "150" Scheme = "HTTPS" secure = "true"

Clientauth = "false" sslprotocol = "TLS"

Keystorefile = "$ {user. Home}/. keystore" keystorepass = "changeit"/>

-Finally, we configure the WEB-INF \ WEB. xml under the app as follows:

<Security-constraint>

<Web-resource-collection>

<Web-resource-Name> must HTTPS </Web-resource-Name>

<URL-pattern>/login. jsp </url-pattern> marker

</Web-resource-collection>

<User-data-constraint>

<Transport-guarantee> confidential </transport-guarantee>

</User-data-constraint>

</Security-constraint>

Which URLs need to be configured by using HTTPS.

Authentication error message and account lock

The following are some incorrect authentication error messages:

-Login Failed. User Kevin's password is incorrect.

-Logon Failed. the user name is invalid.

-Logon Failed. The user has been disabled.

-Logon Failed. the user is not activated.

The correct expression should be the only one:

-Logon Failed. the user name or password is incorrect.

Incorrect authentication error information may cause dictionary attacks or brute-force cracking. Therefore, we should give a common error message as much as possible.

In addition, to prevent brute-force attacks, we can set the following rules:

-The first Logon Failed. The next logon interval is at least 5 s.

-The second Logon Failed. The next logon interval is at least 15 s.

-The third logon fails. The next logon interval is at least 45 s.

-The fourth Logon Failed. The graphic Verification Code CAPTCHA is integrated to allow the user to enter strings in the image.

If there is enough obvious evidence that it is a brute-force attack (for example, 100 attempts per minute), the IP address or session ID should be blocked in the next period (for example, 15 minutes, in this case, we should give a clear error message to explain why the logon fails.

 

This article is excerpted from Web Application Security Threats and prevention-based on OWASP top 10 and esapi

Wang Wenjun
Edited by Li jianmeng

Published by Electronic Industry Publishing House