Shulou(Shulou.com)06/01 Report--

The basic principles of identity authentication password length and complexity policy password authentication as the most popular authentication method, the most important factor in security is the length of the password. A strong password makes it more difficult to guess manually or break it violently. Some of the features of high-strength passwords are defined below. (1) password length for important applications, password length is at least 6; for critical applications, password length is at least 8; for those most critical applications, multi-factor authentication system should be considered. (2) sometimes the length constraint is not enough for the complexity of passwords. For example, passwords such as 12345678 and 11111111 are indeed 8 bits long, but they are easily guessed and dictionaries, so it is necessary to increase the complexity of passwords. Here are some strategies that provide complexity. -at least one uppercase letter (AbeliZ). -at least one lowercase letter (axiz). -at least one number (09). -at least one special character (! @ # $% ^ & etc.). -defines a minimum password length (such as 8 characters). -defines the maximum password length (for example, 16 characters). -cannot appear consecutive characters (such as 123, abc, def). -cannot have the same characters in succession (such as 1111). Once we have defined these policies, we can force users to enter high-strength passwords when they register, thus improving the security of passwords. Implementing a secure password recovery strategy the length and complexity of passwords are described in the previous section. Sometimes passwords that are too complex are forgotten by themselves. What should I do? So generally speaking, an application will provide password recovery. In view of the fact that most applications provide e-mail, which has a unique field, the most common way is to let the user enter the e-mail address. After entering the e-mail box, there are generally the following two solutions. (1) send the original password to the user mailbox. My personal opinion is that if you do this, it means that the application can know your password in plaintext, which runs counter to the single policy that the system only stores hash/ encryption values. If the database of this program is conquered one day, all plaintext will be easily known, so this approach is still not worth advocating. (2) reset a temporary password with which the user logs in and then changes the password. This is a relatively good method, usually in order to increase security, we can also give this temporary password a period of validity, such as users must use this password to log in within 24 hours. The above password recovery strategy is based on the fact that your email should be secure enough (no one knows your password). But what if the application has a CSRF vulnerability, that is, the email may be modified to a person's mailbox without the victim's knowledge, and if the password is recovered, the password will be sent to the person's mailbox? The answer is that recertification is required when updating important fields. For example, the user's password, email, etc., if the user needs to update, a pop-up dialog box allows the user to enter the original password, which can effectively prevent CSRF***. Important operations should be transferred through HTTPS. Important operations, such as logging in, changing passwords, etc., must be transmitted through HTTPS. Let's take Tomcat as an example to explain how to configure so that the specified URL must go HTTPS. The first is to generate a certificate. For illustration purposes, we use keytool provided by Java to generate a self-authentication certificate with the following command:% JAVA_HOME%\ bin\ keytool-genkey-alias tomcat-keyalg RSA. Then answer some questions, here pay attention to setting the password of the certificate store and the password of key, we set it to changeit here, so that a certificate store will be generated, as shown in figure 10-22. Figure 10-22 generate a certificate store with Java, and then copy the generated .KeyStore to the {TOMCAT_HOME}\ conf directory, configure server.xml as follows:-finally, we configure WEB-INF\ web.xml under the APP application as follows: must https / login.jsp ➊ CONFIDENTIAL ➊ to set which URL needs to go to HTTPS. Authentication error message and account lockout the following are some incorrect authentication error messages:-login failed, user Kevin's password is wrong. -failed to login, invalid user name. -login failed and the user has been disabled. -login failed and the user was not activated. The correct expression should be the only one:-failed login, wrong username or password. Incorrect authentication error messages can lead to dictionary cracking or brute force cracking, so we should give a very common error message as much as possible. In addition, in order to prevent violence, we can set the following rules:-the first login fails, the next login is at least 5 seconds apart. -the second login failed, and the next login is at least 15 seconds apart. -the third login failed, and the next login is at least 45 seconds apart. -failed to log in for the fourth time. Integrate the graphic verification code CAPTCHA and let the user enter the string in the picture. If there is sufficient evidence of brute force cracking (such as 100 attempts per minute), the IP address or Session ID should be blocked for the next period of time (e.g. 15 minutes), in which case we should give a clear error message explaining why the login failed. This article is excerpted from "Web Application Security threat and Prevention-- based on OWASP Top 10 and ESAPI"

Published by Wang Wenjun Li Jianmeng Electronic Industry Publishing House

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.