Những sai lầm chết người khi tự làm Authentication

Trong phát triển phần mềm, Authentication (Xác thực danh tính) là một trong những tính năng đánh lừa lập trình viên nhiều nhất. Nó rất dễ để làm cho chạy được (chỉ mất vài chục dòng code là user có thể đăng ký và đăng nhập), nhưng lại cực kỳ khó để làm cho an toàn tuyệt đối.

Rất nhiều vụ rò rỉ dữ liệu chấn động thế giới không xuất phát từ các kỹ thuật tấn công phức tạp của hacker, mà bắt nguồn từ những sai lầm ngớ ngẩn ngay trong khâu thiết kế hệ thống xác thực.

1. Giải thích theo kiểu ELI5: Cửa thép kiên cố và tấm thảm chùi chân#

Hãy tưởng tượng bạn đang xây dựng một ngôi nhà:

• Bạn chi rất nhiều tiền lắp một cánh cửa thép chống trộm dày 20cm ở cửa chính (Bạn bắt người dùng nhập mật khẩu phức tạp 16 ký tự).
• Nhưng bạn lại giấu chiếc chìa khóa dự phòng dưới tấm thảm chùi chân (Lưu token trong localStorage mà trang web dính lỗi XSS).
• Bạn để cửa sổ tầng trệt không khóa (Quên giới hạn số lần thử mật khẩu - Rate Limiting).
• Và khi có người lạ bấm chuông hỏi: “Bác Ba có ở nhà không?”, bạn thật thà trả lời: “Bác Ba có ở đây, nhưng bác đang ngủ” (Lỗ hổng User Enumeration tiết lộ tài khoản có tồn tại).

Dù cửa chính của bạn có dày đến đâu, kẻ trộm vẫn có thể đột nhập vào nhà một cách dễ dàng.

flowchart TD
    subgraph Vulnerable["Hệ thống dính lỗi (Dễ bị tấn công)"]
        A1["User gõ sai mật khẩu"] --> B1["Thông báo: 'Email đúng nhưng mật khẩu sai' -> Lộ User"]
        A2["Brute Force liên tục"] --> B2["Không có Rate Limit -> Bẻ khóa thành công"]
        A3["Reset Password"] --> B3["Token không hết hạn + Không hủy session cũ"]
    end

    subgraph Secure["Hệ thống chuẩn an toàn"]
        C1["User gõ sai"] --> D1["Thông báo chung: 'Thông tin không hợp lệ'"]
        C2["Thử sai 5 lần"] --> D2["Chặn IP 15 phút + CAPTCHA"]
        C3["Reset Password"] --> D3["Token bí mật TTL 15p + Thu hồi mọi session cũ"]
    end

2. Điểm mặt 7 sai lầm chết người khi làm Authentication#

Sai lầm 1: Băm mật khẩu bằng hàm nhanh (MD5, SHA-1, SHA-256 thuần)#

Nhiều lập trình viên nghĩ rằng chỉ cần không lưu mật khẩu dạng văn bản thô (Plaintext) mà băm sang SHA-256 là đã an toàn. Đây là một sai lầm chết người!

• Bản chất: SHA-256 hay MD5 là các hàm băm tốc độ cao, được thiết kế để tính toán hàng tỷ phép tính mỗi giây.
• Rủi ro: Khi database bị lộ, hacker sử dụng card đồ họa (GPU) hiện đại có thể thử hàng chục tỷ mật khẩu mỗi giây để bẻ khóa (Brute-force / Rainbow Table).

[!TIP] Giải pháp đúng: Luôn sử dụng các thuật toán băm mật khẩu chậm và tốn tài nguyên bộ nhớ (Memory-hard):

1. Argon2id (Khuyến nghị số 1 hiện nay từ OWASP).
2. bcrypt (với cost factor >= 12).
3. scrypt hoặc PBKDF2.

import argon2 from 'argon2';

// Băm mật khẩu với Argon2id chuẩn an toàn
export async function hashPassword(password: string): Promise<string> {
  return await argon2.hash(password, {
    type: argon2.argon2id,
    memoryCost: 65536, // 64 MB RAM
    timeCost: 3,       // 3 iterations
    parallelism: 4
  });
}

// So sánh mật khẩu an toàn
export async function verifyPassword(hash: string, plain: string): Promise<boolean> {
  return await argon2.verify(hash, plain);
}

Sai lầm 2: Lộ diện danh tính người dùng (User Enumeration)#

Khi người dùng đăng nhập hoặc yêu cầu quên mật khẩu, hệ thống trả về:

• ❌ “Email này chưa từng được đăng ký trong hệ thống.”
• ❌ “Email tồn tại nhưng mật khẩu không chính xác.”

Kẻ tấn công chỉ cần viết một đoạn script nhỏ gửi danh sách 100.000 email vào form đăng nhập. Hệ thống của bạn sẽ tự động phân loại giúp hacker biết chính xác email nào là khách hàng của bạn để phục vụ mục đích lừa đảo (Phishing) hoặc tấn công nhắm mục tiêu.

[!NOTE] Giải pháp đúng: Luôn trả về thông báo trung lập:

• Khi đăng nhập sai: “Email hoặc mật khẩu không chính xác.”
• Khi quên mật khẩu: “Nếu email của bạn tồn tại trong hệ thống, chúng tôi đã gửi liên kết đặt lại mật khẩu.”

Sai lầm 3: Bỏ quên Rate Limiting và Chống Tấn công Thời gian (Timing Attacks)#

Nếu không giới hạn tần suất request (Rate Limiting):

• Hacker có thể chạy script thử hàng triệu mật khẩu phổ biến (Credential Stuffing).
• Gây nghẽn mạng và treo server đăng nhập (DoS).

Ngoài ra, việc so sánh chuỗi mật mã bằng toán tử === thông thường có thể bị khai thác bởi Timing Attack (thời gian phản hồi nhanh hay chậm tiết lộ số ký tự khớp):

import crypto from 'crypto';

// ❌ SAI: Dễ bị lộ độ dài và ký tự qua Timing Attack
// if (userProvidedToken === secretToken) ...

// ✅ ĐÚNG: So sánh hằng thời gian (Constant-time comparison)
export function safeEqual(a: string, b: string): boolean {
  const bufA = Buffer.from(a);
  const bufB = Buffer.from(b);
  
  if (bufA.length !== bufB.length) return false;
  return crypto.timingSafeEqual(bufA, bufB);
}

Sai lầm 4: Quy trình Đặt lại Mật khẩu (Password Reset) lỏng lẻo#

Quy trình quên mật khẩu thường là “gót chân Achilles” của toàn bộ hệ thống:

1. Token quá ngắn hoặc dễ đoán: Dùng mã OTP 4 số hoặc hàm Math.random() thay vì crypto.randomBytes(32).
2. Không có thời hạn hết hạn (TTL): Link reset gửi qua email có hạn dùng vĩnh viễn.
3. Không thu hồi session cũ: Sau khi đổi mật khẩu thành công, kẻ tấn công (nếu đang giữ session cũ) vẫn đăng nhập bình thường!

[!WARNING] Khi người dùng đổi mật khẩu hoặc reset mật khẩu thành công, bạn BẮT BUỘC phải hủy toàn bộ Session ID / Refresh Token đang hoạt động trên tất cả các thiết bị khác!

Sai lầm 5: Nhầm lẫn giữa Authentication (Xác thực) và Authorization (Phân quyền)#

• Authentication (401 Unauthorized): Bạn là ai? (Ví dụ: Bạn là User A).
• Authorization (403 Forbidden): Bạn có quyền làm việc này không?

Nhiều lập trình viên sau khi viết xong middleware kiểm tra token thì yên tâm cho rằng hệ thống đã an toàn. Hậu quả là sinh ra lỗ hổng IDOR (Insecure Direct Object References):

// ❌ LỖ HỔNG IDOR: Bất kỳ ai đã đăng nhập đều xem được hóa đơn của người khác!
app.get('/api/invoices/:id', authenticateUser, async (req, res) => {
  const invoice = await db.invoices.findById(req.params.id);
  // Quên kiểm tra: if (invoice.userId !== req.user.id) return res.status(403);
  return res.json(invoice);
});

Sai lầm 6: Lưu trữ Token thiếu an toàn trên Client#

• Lưu JWT vào localStorage: Chỉ cần ứng dụng dính 1 lỗi Cross-Site Scripting (XSS) từ thư viện bên thứ ba, toàn bộ token của khách hàng sẽ bị đánh cắp trong tích tắc.
• Lưu vào Cookie nhưng thiếu cờ bảo mật: Quên cấu hình HttpOnly, Secure, và SameSite=Lax/Strict.

Sai lầm 7: Tự phát minh ra thuật toán mã hóa riêng (“Rolling Your Own Crypto”)#

Nhiều lập trình viên thích tự viết hàm xáo trộn chuỗi hoặc tự chế giao thức xác thực vì nghĩ rằng “Không ai biết thuật toán này thì hacker sao bẻ được”.

Trong mật mã học, đây gọi là nguyên lý Security through Obscurity (Bảo mật bằng sự bí ẩn) — một nguyên lý đã được chứng minh là luôn thất bại. Các tiêu chuẩn bảo mật như OAuth2, OpenID Connect, WebAuthn/Passkeys đã trải qua hàng nghìn chuyên gia bảo mật toàn cầu kiểm thử qua nhiều thập kỷ.

3. Checklist kiểm tra bảo mật Authentication trước khi Deploy#

4. Tổng kết#

Một hệ thống Authentication mạnh mẽ không nằm ở việc bắt người dùng nhập mật khẩu dài 30 ký tự kỳ quặc, mà nằm ở sự chặt chẽ trong từng mắt xích kiến trúc của lập trình viên.

Hãy tuân thủ các tiêu chuẩn đã được kiểm chứng, đừng tự chế mật mã, và luôn kiểm tra kỹ lưỡng các kịch bản ngoại lệ trước khi đưa sản phẩm ra môi trường thực tế.

Tài liệu tham khảo#

• OWASP Authentication Cheat Sheet ↗
• OWASP Password Storage Cheat Sheet ↗
• OWASP Forgot Password Cheat Sheet ↗
• RFC 9106: Argon2 Memory-Hard Function for Password Hashing ↗