Tại sao mật khẩu mạnh có thể mất hàng nghìn tỉ năm để hacker giải mã, nhưng hệ thống vẫn cần Rate Limiting?

Mật khẩu mạnh mất hàng nghìn tỉ năm để crack là trong trường hợp nào?

Những con số khổng lồ như “mất hàng nghìn tỉ năm để brute-force” chỉ đúng trong bối cảnh tấn công offline, tức hacker đã có được hash mật khẩu và đem đi crack trên thiết bị của họ:

• Mật khẩu dài, dùng nhiều dạng ký tự → entropy tăng mạnh.
• Bcrypt, Argon2 làm chậm việc băm → mỗi lần brute-force tốn hàng chục đến hàng trăm mili giây.
• GPU mạnh có thể thử hàng tỉ hash/giây với MD5/SHA1, nhưng lại rất chậm với các slow-hash như bcrypt/argon2.

Ví dụ: mật khẩu 12 ký tự, charset 95 ký tự → số tổ hợp lên đến hàng trăm triệu tỉ. Một GPU dù mạnh đến đâu cũng phải mất hàng nghìn năm, thậm chí lâu hơn.

Nhưng đó là câu chuyện crack offline, không phải tấn công trực tiếp vào hệ thống thật.

Tấn công online: hacker không cần brute-force toàn bộ

Khi tấn công trực tiếp vào hệ thống đăng nhập (online attack), hacker không brute-force tất cả tổ hợp. Họ dùng các chiến thuật hiệu quả hơn nhiều:

• Credential stuffing: thử các email + mật khẩu rò rỉ từ vụ leak khác.
• Password spraying: thử 1 mật khẩu phổ biến cho cực nhiều tài khoản.
• Dictionary attack: dùng danh sách hàng trăm nghìn – hàng triệu mật khẩu phổ biến.
• Dự đoán hành vi: thử các mẫu như tên + năm, từ có nghĩa, số quen thuộc.

Chỉ cần spam đủ nhanh, hacker hoàn toàn có thể dò trúng mật khẩu yếu, dù số lượng thử nhỏ hơn vô hạn so với brute-force offline.

Không có rate limit → hacker có thể gửi hàng nghìn request/giây

Nếu endpoint đăng nhập không có giới hạn, hacker có thể:

• Gửi 5.000 – 20.000 request/giây từ một máy.
• Dùng botnet để gửi hàng triệu request/phút.
• Sử dụng proxy xoay vòng IP để né mọi hệ thống theo dõi đơn giản.

Như vậy, dù mật khẩu cực mạnh, hệ thống vẫn có nguy cơ bị:

• Brute-force trực tuyến
• Credential stuffing
• Password spraying
• Làm nghẽn dịch vụ hoặc làm server quá tải

Chi phí của password_verify: lý do quan trọng khiến phải giới hạn request

Mỗi lần gọi:

password_verify($input, $storedHash)

bcrypt hoặc Argon2 phải thực hiện quá trình tính toán chậm (slow hash). Điều đó đồng nghĩa:

• Mỗi lần password_verify có thể tiêu tốn 50–200ms CPU.
• Nếu hacker gửi 1000 request/giây → CPU không thể xử lý nổi.
• Server chết vì quá tải trước khi hacker cần thử nhiều mật khẩu.
• Đây được gọi là exhaustion attack – tấn công làm cạn tài nguyên.

Nghĩa là: bảo vệ bằng mật khẩu mạnh không ngăn được tấn công vào chính điểm đăng nhập. Rate limiting là cách buộc hệ thống giảm số lần password_verify được kích hoạt mỗi giây.

Rate limiting giải quyết vấn đề như thế nào?

Khi rate limit được áp dụng:

• Mỗi IP chỉ được thử X lần mỗi phút.
• Sau Y lần sai → khóa tạm thời 5–15 phút.
• Dùng Captcha sau vài lần sai.
• Thêm delay tăng dần sau từng sai liên tiếp.

Kết quả mang lại:

• Hacker không thể gửi hàng nghìn request/giây.
• Tấn công password spraying bị vô hiệu hóa.
• Server không bị spam đến mức sập.
• Việc brute-force online trở nên không khả thi.

Fail2Ban và cơ chế khóa IP đa tầng

Rate limiting là lớp đầu tiên trong ứng dụng. Ở tầng server, các công cụ như Fail2Ban tiếp tục bảo vệ hệ thống:

• Giám sát log của web server, SSH, FTP.
• Phát hiện nhiều lần login sai liên tiếp.
• Tự động chặn IP bằng firewall trong vài phút đến vài giờ.

Điều này tạo ra hệ thống phòng thủ nhiều lớp, khiến hacker cực kỳ khó thử liên tục—even phân tán qua nhiều IP.

Mật khẩu mạnh vẫn là nền tảng

Dù rate limiting quan trọng, mật khẩu mạnh vẫn không thể thiếu. Khi database bị lộ:

• Bcrypt/Argon2 làm tốc độ crack offline giảm hàng triệu lần.
• Mật khẩu dài và ngẫu nhiên buộc hacker phải mất hàng nghìn tỉ năm để brute-force.

Nhưng mật khẩu mạnh chỉ bảo vệ bạn khỏi offline cracking. Trong khi rate limiting bảo vệ bạn khỏi online attacks.

Kết luận

Mật khẩu mạnh giúp brute-force offline trở nên bất khả thi, nhưng hệ thống đăng nhập vẫn cần rate limiting vì:

• Hacker tấn công online không brute-force toàn bộ mật khẩu, mà dựa vào danh sách mật khẩu phổ biến.
• password_verify tốn tài nguyên → server dễ bị exhaustion attack.
• Không có rate limit → hacker có thể thử hàng nghìn lần mỗi giây.
• Fail2Ban và firewall là những lớp bảo vệ bổ sung không thể thiếu.

Hệ thống an toàn cần kết hợp mật khẩu mạnh, slow hashing và giới hạn số lần thử. Đây là mô hình bảo mật đa lớp, giúp bảo vệ cả khi database bị lộ lẫn khi endpoint bị tấn công trực tiếp.