Preventing Authentication Attacks

# CHAPTER 16

Preventing Authentication Attacks #

1. Introduction #

2. Learning Objectives #

• Define Brute Force and Credential Stuffing attacks.

• Implement API Rate Limiting to protect login endpoints.

• Explain the mechanics of a Cross-Site Request Forgery (CSRF) attack.

• Understand the mechanics of a Cross-Site Scripting (XSS) attack.

• Implement account lockout policies safely.

3. Beginner-Friendly Explanation #

• Brute Force Attack: A thief sits in front of the safe and tries 0001, 0002, 0003... until the safe eventually opens.

• The Defense (Rate Limiting): You install a trapdoor. If someone guesses the combination wrong 5 times, the trapdoor opens, and they fall into a pit. They have to wait 15 minutes before they can try again.

Now imagine a master key.

• CSRF Attack: A thief tricks the guard into turning the key while the guard is distracted.

• XSS Attack: A thief sneaks into the safe factory and paints the combination on the inside of the door, so anyone who opens it accidentally reveals it.

4. Brute Force vs Credential Stuffing #

Credential Stuffing: A massive database of emails and passwords is stolen from Company A. Hackers know users reuse passwords. So, they write a script that takes the 10 million stolen credentials from Company A and automatically tries them on Company B's login page. They aren't "guessing" passwords; they are stuffing known, stolen passwords into your forms.

5. Defending the Login Route: Rate Limiting #

Example in Node.js (Express Rate Limit):

const rateLimit = require('express-rate-limit');

// Create a strict limiter for the login route
const loginLimiter = rateLimit({
    windowMs: 15 * 60 * 1000, // 15 minutes
    max: 5, // Limit each IP address to 5 login requests per window
    message: "Too many login attempts from this IP, please try again after 15 minutes"
});

// Apply it ONLY to the login route
app.post('/api/login', loginLimiter, (req, res) => {
    // Standard login logic here...
});

*If a hacker's script tries 10,000 passwords, the server processes the first 5, and then instantly rejects the remaining 9,995 with an HTTP 429 Too Many Requests error, saving your database from crashing.*

6. Defending against CSRF #

The Defense: If you use Session Cookies or HttpOnly JWT Cookies, you must use CSRF Tokens.

1. 1. When your server generates the HTML form, it generates a random string (the CSRF Token).

1. 2. It places this token in a hidden <input> field in the HTML, AND saves it in the user's Session.

1. 3. When the form is submitted, the server compares the hidden input to the Session.

1. 4. Because the hacker's malicious website cannot read your HTML (due to browser security policies), they cannot include the hidden token in their forged request. The server rejects the transfer.

*(Note: If you use LocalStorage and Bearer Tokens, you are immune to CSRF because the browser does not attach Bearer tokens automatically).*

7. Defending against XSS #

The Defense:

1. 1. Never trust user input: Always sanitize data before saving it to the database (strip out <script> tags).

1. 2. Auto-escaping Templates: Frameworks like React, Angular, Laravel Blade, and Python Jinja2 automatically escape HTML entities. They turn <script> into <script>, rendering it harmless text.

1. 3. HttpOnly Cookies: If you store your session or JWT in a cookie marked HttpOnly, JavaScript physically cannot access it. Even if an XSS script executes, it cannot steal the token.

8. Backend Workflow: Account Lockouts #

9. Best Practices #

• Use Web Application Firewalls (WAF): Tools like Cloudflare sit in front of your server and use AI to detect and block malicious bot traffic before it even touches your Node.js or PHP application.

10. Common Mistakes #

• Locking Accounts Permanently: Never lock an account permanently after failed login attempts. If you do, a troll can write a script to intentionally fail logins for every user on your platform, permanently locking every legitimate user out of their own accounts (A Denial of Service attack). Lockouts should be temporary (e.g., 15 minutes) or require an email verification link to unlock.

11. Exercises #

1. 1. Explain the fundamental difference between a Brute Force attack and a Credential Stuffing attack. Why is rate-limiting effective against both?

12. Coding Challenges #

• Challenge: Conceptualize the database schema required to implement Account Lockouts. What three columns would you need to add to the users table to track the failures and enforce a 15-minute temporary ban?

13. MCQs with Answers #

14. Interview Questions #

• Q: Describe a Cross-Site Scripting (XSS) attack. If a frontend application utilizes HTML5 LocalStorage to store a JWT Access Token, how could an XSS vulnerability lead to complete account compromise?

• Q: Explain the necessity of implementing both IP-based Rate Limiting and Account-based Lockouts on a login route. How do these two defenses complement each other against a distributed botnet attack?

15. FAQs #

16. Summary #

17. Next Chapter Recommendation #