Shulou(Shulou.com)05/31 Report--

This article mainly explains the "write web login interface to consider what security issues", the article explained the content is simple and clear, easy to learn and understand, the following please follow the editor's ideas slowly in-depth, together to study and learn "write web login interface to consider what security issues" bar!

Safety risk

Brute force cracking!

As long as the website is exposed to the public network, there is a good chance that it will be targeted and try to blow up this simple and effective way:

After obtaining the user name of the website in various ways, write a program to traverse all possible passwords until the correct password is found.

The pseudo code is as follows:

# password dictionary password_dict = [] # login interface login_url =''def attack (username): for password in password_dict: data = {' username': username, 'password': password} content = requests.post (login_url, data) .content.decode (' utf-8') if 'login success' in content: print (' got it! Password is:% s'% password) author: Dada Dada Code Link: https://juejin.cn/post/6859214952704999438 Source: Nuggets copyright belongs to the author. Commercial reprint please contact the author for authorization, non-commercial reprint please indicate the source.

So how can we prevent this kind of situation?

Verification code

Smart students will think that I can add CAPTCHA check when its password error reaches a certain number of times! For example, when the user's password error reaches 3 times, the user needs to enter the image verification code to continue the login operation:

The pseudo code is as follows:

Fail_count = get_from_redis (fail_username) if fail_count > = 3: if captcha is None: return error ('required CAPTCHA') check_captcha (captcha) success = do_login (username, password) if not success: set_redis (fail_username, fail_count + 1)

Pseudo-code does not consider concurrency, the actual development can consider locking.

This does filter out some illegal attacks, but in terms of current OCR technology, ordinary image captcha is really difficult to effectively prevent robots (we've suffered a lot from this). Of course, we can also spend money on verification schemes such as sliding verification provided by three-party companies, but it is not 100% secure and can still be cracked (painful lessons).

Login restriction

At that time, another student said, then I can directly restrict the login operation of abnormal users. When the password error reaches a certain number of times, I will directly reject the login of the user and resume it after a period of time. For example, if we set an account to log in for 10 times, we will reject all login operations for that account within 5 minutes.

The pseudo code is as follows:

Fail_count = get_from_redis (fail_username) locked = get_from_redis (lock_username) if locked: return error ('login denied') if fail_count > = 3: if captcha is None: return error ('require CAPTCHA') check_captcha (captcha) success = do_login (username, password) if not success: set_redis (fail_username, fail_count + 1) if fail_count + 1 > = 10: # failed more than 10 times Set lock flag set_redis (lock_username, true, 300s)

Umm, this can really solve the problem of users' passwords being blown up. However, this brings another risk: although the attacker can not get the user information of the site, but it can prevent all users of our site from logging in!

An attacker only needs to loop through all the user names indefinitely (even if not, randomly) to log in, and these users will always be locked out, preventing normal users from logging in to the site!

IP restriction

Well, since it doesn't work directly for the user name, we can deal with it for IP, and everything will be fine if we just seal off the attacker's IP. We can set the number of errors in an IP call login API to prevent the IP from logging in.

The pseudo code is as follows:

Ip = request ['IP'] fail_count = get_from_redis (fail_ip) if fail_count > 10: return error (' login denied') # other logic # do something () success = do_login (username, password) if not success: set_redis (fail_ip, true, 300s)

This can also solve the problem to a certain extent. In fact, many current-limiting operations are aimed at IP. For example, the current-limiting module of niginx can limit the number of visits to an IP per unit time.

But there is still a problem here:

For example, at present, many schools and companies use the same export IP. If you press the IP restriction directly, you may mistakenly kill other normal users. Now that there are so many, attackers can switch to attack after the IP is blocked.

Mobile phone verification

Isn't there a better way to prevent it? of course there is. We can see that in recent years, almost all applications will allow users to bind mobile phones, one is the national real-name policy requirements, the second is that mobile phones are basically the same as ID cards, which can basically represent a person's identity. Therefore, many security operations are based on mobile phone authentication, and login is also possible.

When the number of times the user enters the password is more than 3 times, the user is required to enter the verification code (it is best to use sliding authentication). When the number of times the user enters the password is more than 10 times, the phone pops up for verification, which requires the user to log in with the double authentication of the mobile phone verification code and password

Mobile CAPTCHA anti-brushing is another problem, we will not expand here, we will have time to talk about what we have done in CAPTCHA anti-brushing.

The pseudo code is as follows:

Fail_count = get_from_redis (fail_username) if fail_count > 3: if captcha is None: return error ('need CAPTCHA') check_captcha (captcha) if fail_count > 10: # > 10 times Log in to if dynamic_code is None with the verification code and password: return error ('please enter the mobile verification code') if not validate_dynamic_code (username, dynamic_code): delete_dynamic_code (username) return error ('mobile verification code error') success = do_login (username, password, dynamic_code) if not success: set_redis (fail_username, fail_count + 1)

When we combine the above methods and add the verification mode of mobile CAPTCHA, we can basically prevent a considerable number of malicious attackers. But no system is absolutely secure, we can only increase the attack cost of the attacker as much as possible. You can choose the appropriate strategy according to the actual situation of your website.

Man in the middle attack?

What is a man-in-the-middle attack

* Man-in-the-middle attack (man-in-the-middle attack, abbreviated to MITM) *. To put it simply, in the process of communication between An and B, attackers obtain or modify the communication content of An and B by sniffing and intercepting.

Take chestnut for example: Xiaobai gives Xiao Huang express delivery, on the way to pass through express point A, Xiao Hei hides at express point A, or simply opens a delivery point B to pretend to be express point A. Then secretly opened Xiaobai's express delivery to Xiao Huang to see what was in it. You can even leave Xiaobai's express delivery and pack a dime-like box and send it to Xiao Huang.

During the login process, if the attacker sniffs the login request sent from the client to the server, he can easily get the user name and password.

HTTPS

The easiest and most effective way to prevent man-in-the-middle attacks is to change the HTTPS and modify all HTTP requests on the site to force the use of HTTPS.

* Why can HTTPS prevent man-in-the-middle attacks? *

HTTPS actually adds SSL/TLS protocol between HTTP and TCP protocols to ensure the secure transmission of data. Compared with HTTP,HTTPS, it has the following main characteristics:

Content encryption

Data integrity

Authentication

The specific HTTPS principle is no longer extended here, and you can Google it on your own.

Encrypted transmission

In addition to HTTPS, we can manually encrypt the transmission of sensitive data:

The user name can be encrypted asymmetrically on the client side and decrypted on the server side

Passwords can be transmitted after MD5 on the client side to prevent clear text from being exposed

Thank you for your reading, the above is the content of "what security issues should be considered in writing web login interface". After the study of this article, I believe you have a deeper understanding of what security issues should be considered in writing web login interface, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

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.