Is your login interface really secure?

preface

When you learn to write a program, the first line of code is hello world B ut when you start learning WEB background technology, the first function of many people is to write logins (whisper: I don't know, I am anyway). B ut I and many students with short work experience interview or communication, found that many students although they have written on the resume: 负责项目的登录/注册功能模块的开发和设计工作 but are simply implemented functional logic, in terms of security did not consider too much. This article is mainly to talk to you, in the design of a login interface, not only functional implementation, in terms of security, we also need to consider where.

Security risks

Brute force!

As long as the site is exposed to the public network, then very likely to be targeted, try to blast this simple and effective way: through various ways to obtain the site's username, through the program to traverse all possible passwords until the correct password is found

The pseudocode is as follows:

# 密码字典
password\_dict = \[\]
# 登录接口
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 do we prevent this situation?

The verification code

Have a clever classmate thought, I can in it password error reached a certain number of times, increase the verification code verification! For example, we set up that when a user password error reaches 3 times, the user is required to enter a picture verification code to continue the login operation:

The pseudocode is as follows:

fail\_count = get\_from\_redis(fail\_username)
if fail\_count >= 3:
 if captcha is None:
  return error('需要验证码')
    check\_captcha(captcha)
success = do\_login(username, password)
if not success:
 set\_redis(fail\_username, fail\_count + 1)

Pseudocode does not consider concurring, and actual development can consider locking.

This does filter out some illegal attacks, but with current OCR technology, a normal image verification code is really hard to do to prevent robots effectively (we've lost a lot of money on it). Of course, we can also spend money on verification schemes like sliding verification provided by a tripartite company, but it's not 100% secure and can be cracked (painful lessons).

Sign-in restrictions

That's when another classmate said, then I can directly limit the non-normal user's login operation, when it password error reached a certain number of times, directly deny the user's login, after a period of time to recover. For example, if we set up an account to log in 10 times with 10 errors, we reject all login actions for that account within 5 minutes.

The pseudocode is as follows:

fail\_count = get\_from\_redis(fail\_username)
locked = get\_from\_redis(lock\_username)


if locked:
 return error('拒绝登录')
if fail\_count >= 3:
 if captcha is None:
  return error('需要验证码')
    check\_captcha(captcha) 
success = do\_login(username, password)
if not success:
 set\_redis(fail\_username, fail\_count + 1)
    if fail\_count + 1 >= 10:
     # 失败超过10次，设置锁定标记
     set\_redis(lock\_username, true, 300s)

umm, which does solve the problem of the user's password being blasted. H owever, there is another risk that an attacker will not be able to obtain user information for the site, but it will prevent all users of our site from logging on! An attacker would only need to loop through all user names (even if not random) to log in, and those users would always be locked out, preventing normal users from logging on to the site!

IP restrictions

Then since directly against the user name can not, we can deal with the IP, directly seal the attacker's IP is not a big deal. We can set that when the number of login interface errors called under an IP reaches a certain number, the IP is prohibited from logging in.

The pseudocode is as follows:

ip = request\['IP'\]
fail\_count = get\_from\_redis(fail\_ip)
if fail\_count > 10:
 return error('拒绝登录')
# 其它逻辑
# do something()
success = do\_login(username, password)
if not success:
 set\_redis(fail\_ip, true, 300s)

This can also solve the problem to some extent, in fact, there are many current-limiting operations for IP, such as niginx's current-limiting module can limit the number of ip visits per unit of time. But here's the problem:

• For example, many schools and companies now use the same export IP, if directly by IP restrictions, may kill other normal users
• With so many VPNs now, an attacker can switch VPNs to attack after the IP is blocked

Mobile verification

Isn't there a better way to guard against it? O f course. W e can see that in recent years, almost all applications will allow users to bind mobile phones, one is the country's real-name policy requirements, the second is basically the same as the identity card, basically can represent a person's identity. So many security operations are based on mobile phone verification to carry out, login can also be.

1. When the user enters a password more than 3 times, the user is required to enter a verification code (preferably with sliding verification)
2. When a user enters a password more than 10 times, pop-up phone verification requires the user to sign in using the phone verification code and password two-factor authentication

Mobile phone verification code anti-brush is another problem, here does not expand, later have time to talk about what we have done in the verification code anti-brush.

The pseudocode is as follows:

fail\_count = get\_from\_redis(fail\_username)


if fail\_count > 3:
 if captcha is None:
  return error('需要验证码')
    check\_captcha(captcha) 

    
if fail\_count > 10:
 # 大于10次，使用验证码和密码登录
 if dynamic\_code is None:
     return error('请输入手机验证码')
    if not validate\_dynamic\_code(username, dynamic\_code):
     delete\_dynamic\_code(username)
     return error('手机验证码错误')


 success = do\_login(username, password, dynamic\_code)

    
 if not success:
     set\_redis(fail\_username, fail\_count + 1)

We combined the above several ways, coupled with the mobile phone verification code verification mode, basically can prevent a considerable number of malicious attackers. B ut no system is absolutely secure, and we can only maximize the cost of an attacker's attack. You can choose the right 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, abbreviated to MITM, in simple terms, A and B In the course of communication, an attacker acquires or modifies the communications of A and B by sniffing, intercepting, and so on.

Take a chestnut: 小白 to 小黄 hair express, on the way to go through the courier point A, small 小黑 on the hiding in the courier point A, or simply open a courier point B to impersonate the courier point A. T hen secretly dismantled 小白 to Xiao 小黄 courier, to see what's inside. You can even leave 小白 courier, pack yourself a hair-like box and send it to 小黄

That way, if an attacker sniffs out a login request from the client to the service side, the user's username and password can be easily obtained.

HTTPS

One of the simplest and most effective actions to prevent man-in-the-middle attacks is to replace HTTPS and modify all HTTP requests in the web site to force the use of HTTPS.

Why can HTTPS protect against man-in-the-middle attacks? /b10>HTTPS is actually an SSL/TLS protocol that is added to the HTTP and TCP protocols to secure the transfer of data. Compared to HTTP, HTTPS has several main features:

• Content encryption
• Data integrity
• Authentication

The specific HTTPS principle is no longer extended here, so you can google it yourself

Encrypted transmission

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

• User names can be decrypted on the service side using asymmetric encryption on the client side
• Passwords can be transferred after MD5 on the client side to prevent the password clear text from being exposed

other

In addition to what we talked about above, there are many other things to consider, such as:

• Action log, every user login and sensitive operation needs to log (including IP, device, etc.)
• Abnormal operation or login reminder, with the above operation log, then we can do risk alert based on log, such as users in a very login login, modify password, login exception, you can text to remind users
• When you reject a weak password When you register or modify a password, you do not allow the user to set a weak password
• Prevent user names from being traversed Some sites are prompted for the existence of a user name after they have been entered when they are registered. This risks exposing all usernames of the site (just traversing the interface) and requires interaction or logic limitations
• ...

postscript

Now the country has introduced a variety of laws, the user's data more and more important. A s developers, we also need to do more to protect user data and user privacy. Later I will also talk to you about what we have done in data security, I hope to give you a little help.

Above is W3Cschool编程狮 about is your login interface really secure? Related to the introduction, I hope to help you.