How to Secure Login APIs: Defending Against Brute Force, MITM, and More

Introduction

When developers implement a login feature, they often focus only on functional correctness and overlook security considerations. A poorly protected login endpoint can be exploited through brute‑force attempts, credential stuffing, or man‑in‑the‑middle (MITM) attacks, leading to credential leakage or service denial.

Brute‑Force Attack

Any public‑facing service is a potential target for attackers who enumerate usernames and try many passwords until a match is found. A simple script can automate this process:

# Password dictionary
password_dict = []
# Login endpoint URL
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)

Note: The pseudocode does not handle concurrency; in production you should add proper locking.

CAPTCHA Mitigation

One common defense is to require a CAPTCHA after a certain number of failed attempts. For example, after three incorrect passwords the user must solve an image CAPTCHA before further attempts:

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)

In real implementations consider rate‑limiting and lockout mechanisms to avoid denial‑of‑service.

Login Lockout & IP Limiting

To raise the attack cost, you can lock an account after many failures and also block abusive IP addresses:

# Account lockout
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:
        # Exceeded 10 attempts, lock for 5 minutes
        set_redis(lock_username, true, 300)

IP‑based throttling works similarly:

ip = request['IP']
fail_count = get_from_redis(fail_ip)
if fail_count > 10:
    return error('拒绝登录')
# other login logic
success = do_login(username, password)
if not success:
    set_redis(fail_ip, true, 300)

Be aware of collateral damage: shared NAT IPs, VPN rotation, and false positives can affect legitimate users.

Man‑in‑the‑Middle (MITM) Attacks

An attacker who intercepts traffic between client and server can capture usernames and passwords in clear text. The simplest and most effective mitigation is to enforce HTTPS, which adds TLS encryption, data integrity, and server authentication.

Content encryption

Data integrity verification

Server identity authentication

Detailed TLS internals are omitted for brevity; refer to official specifications for deeper study.

Additional Encryption Practices

Encrypt usernames on the client using asymmetric encryption; decrypt on the server.

Hash passwords (e.g., MD5, though stronger algorithms like bcrypt/argon2 are recommended) before transmission.

Other Defensive Measures

Maintain comprehensive operation logs (IP, device, timestamps) for every login and sensitive action.

Trigger anomaly alerts (e.g., SMS) when unusual login patterns are detected.

Enforce strong password policies and reject weak passwords during registration or change.

Prevent username enumeration by limiting feedback on existence checks and adding rate limits.

Conclusion

No single technique guarantees absolute security; the goal is to raise the attacker’s cost. Choose a combination of password‑retry limits, CAPTCHAs, SMS verification, HTTPS, logging, and monitoring that fits your application’s risk profile.