Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

How to ensure login security in WEB development

2025-04-02 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Development >

Share

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

This article mainly introduces how to ensure login security in WEB development, with a certain reference value, interested friends can refer to, I hope you can learn a lot after reading this article, the following let the editor take you to know about it.

Security 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. Try to explode 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 you find the correct password.

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)

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 ('need 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 ('refuse login') if fail\ _ count > = 3: if captcha is None: return error ('require a verification code') 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 the 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 refused') # 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, many schools and companies now 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 VPN, attackers can switch VPN to attack after 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 user enters the password more than 3 times, the user is required to enter the CAPTCHA (it is best to use sliding authentication)

When the user enters the password more than 10 times, the pop-up phone verifies, and the user needs to log in using the mobile phone verification code and password double authentication.

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 ('verification code required') check\ _ captcha (captcha) if fail\ _ count > 10: # more than 10 times Log in to if dynamic\ _ code is None: return error ('Please enter the phone verification code') if not validate\ _ dynamic\ _ code (username, dynamic\ _ code): delete\ _ dynamic\ _ code 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, An and B in the communication process, the attacker through sniffing, interception and other means to obtain or modify the communication content of An and B.

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 reading this article carefully. I hope the article "how to ensure login security in WEB development" shared by the editor will be helpful to everyone. At the same time, I also hope you will support us and pay attention to the industry information channel. More related knowledge is waiting for you to learn!

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.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Development

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report