Độ dài mật khẩu và bảo mật - Chọn độ dài phù hợp
Độ dài mật khẩu là yếu tố quan trọng nhất trong bảo mật mật khẩu. Mỗi ký tự bổ sung nhân số lượng tổ hợp có thể lên khoảng 95 lần, khiến các cuộc tấn công brute-force khó hơn theo cấp số nhân. Hướng dẫn này đi sâu hơn những lời khuyên bề mặt, bao gồm tính toán entropy, chi phí hàm băm, benchmark bẻ khóa bằng GPU, so sánh passphrase với chuỗi ngẫu nhiên, và chiến lược xác thực đa yếu tố - tất cả dựa trên hướng dẫn NIST SP 800-63B.
Entropy và độ mạnh mật khẩu
Entropy, đo bằng bit, định lượng mức độ khó đoán của mật khẩu. Công thức rất đơn giản:
Entropy (bits) = log2(charset sizelength) = length × log2(charset size)
Với bộ ký tự ASCII in được đầy đủ gồm 95 ký tự, mỗi ký tự đóng góp khoảng 6,57 bit entropy. Mật khẩu 8 ký tự cho khoảng 52,6 bit, 12 ký tự khoảng 78,8 bit, và 16 ký tự khoảng 105,1 bit. Trong cộng đồng bảo mật, 80+ bit được coi là "an toàn hiện tại" và 128+ bit là "an toàn dài hạn". Với bộ 95 ký tự, bạn cần ít nhất 13 ký tự cho an toàn ngắn hạn và 20+ ký tự cho an toàn dài hạn.
Một nhận định quan trọng: tăng độ dài hiệu quả hơn tăng sự đa dạng ký tự. Mật khẩu 16 ký tự chỉ dùng chữ thường (26 ký tự) có khoảng 75,2 bit entropy - gần bằng mật khẩu 12 ký tự sử dụng toàn bộ 95 ký tự (78,8 bit). Kéo dài mật khẩu chữ thường đó lên 20 ký tự và entropy đạt khoảng 94 bit, vượt qua mật khẩu 14 ký tự dùng đầy đủ bộ ký tự (khoảng 92 bit). Đây là cơ sở toán học cho lý do tại sao độ dài quan trọng hơn độ phức tạp.
Hướng dẫn NIST SP 800-63B
NIST SP 800-63B, được sửa đổi năm 2017 với bản dự thảo phiên bản thứ tư công bố năm 2024, là tiêu chuẩn quốc tế cho chính sách mật khẩu. Tài liệu này rõ ràng không khuyến khích việc bắt buộc thay đổi định kỳ và yêu cầu ký tự phức tạp, đặt độ dài là yếu tố bảo mật chính.
- Tối thiểu: 8 ký tự (mức sàn cho nhà cung cấp dịch vụ)
- Khuyến nghị: 15+ ký tự (bản dự thảo phiên bản thứ tư đề xuất nâng mức tối thiểu lên 15)
- Tối đa: Dịch vụ nên cho phép ít nhất 64 ký tự
- Không khuyến khích bắt buộc độ phức tạp (yêu cầu chữ hoa + ký hiệu) - người dùng sử dụng các mẫu dễ đoán như thêm "!" để đáp ứng yêu cầu, chỉ thêm rất ít entropy thực tế
- Không khuyến khích bắt buộc thay đổi mật khẩu định kỳ - việc thay đổi bắt buộc dẫn đến sửa đổi tăng dần (thay đổi chữ số cuối) thay vì mật khẩu thực sự mới
- Bắt buộc kiểm tra danh sách mật khẩu bị rò rỉ - nhà cung cấp dịch vụ phải kiểm tra mật khẩu mới với cơ sở dữ liệu rò rỉ đã biết và từ chối nếu trùng khớp
Sự ưu tiên của NIST cho độ dài hơn độ phức tạp được hỗ trợ bởi cả toán học entropy và nghiên cứu khả năng sử dụng. Các nghiên cứu cho thấy các quy tắc phức tạp khiến người dùng ghi mật khẩu lên giấy nhớ hoặc tái sử dụng mật khẩu yếu theo mẫu - những hành vi làm suy yếu lợi ích bảo mật dự kiến. Để tìm hiểu sâu hơn về các phương pháp xác thực hiện đại, hãy tham khảo sách về an ninh mạng và quản lý mật khẩu.
Benchmark thời gian bẻ khóa Brute-Force bằng GPU
Bảng dưới đây cho thấy thời gian bẻ khóa ước tính sử dụng GPU hiện đại (loại NVIDIA RTX 4090, có khả năng thực hiện khoảng 164 tỷ lần thử băm MD5 mỗi giây) với bộ 95 ký tự ASCII in được đầy đủ.
| Độ dài | Tổ hợp | Entropy | Thời gian ước tính (MD5) | Thời gian ước tính (bcrypt) |
|---|---|---|---|---|
| 6 ký tự | ~735 tỷ | ~39,5 bit | ~4,5 giây | ~230.000 năm |
| 8 ký tự | ~6,6 triệu tỷ | ~52,6 bit | ~11 giờ | ~2 tỷ năm |
| 10 ký tự | ~6 × 1019 | ~65,7 bit | ~12.000 năm | Thực tế không thể |
| 12 ký tự | ~5,4 × 1023 | ~78,8 bit | ~100 triệu năm | Thực tế không thể |
| 16 ký tự | ~4,4 × 1031 | ~105,1 bit | ~8,5 × 1012 năm | Thực tế không thể |
Với hàm băm nhanh như MD5, mật khẩu 8 ký tự bị bẻ trong khoảng 11 giờ. Với bcrypt (hệ số chi phí 12), cùng mật khẩu 8 ký tự đó sẽ mất ước tính 2 tỷ năm. Việc chọn thuật toán băm ảnh hưởng đáng kể đến bảo mật mật khẩu thực tế - một thực tế thường bị bỏ qua. Tuy nhiên, vì người dùng không thể chọn thuật toán băm phía máy chủ, biện pháp phòng thủ tốt nhất từ phía người dùng vẫn là đặt mật khẩu đủ dài.
Chi phí hàm băm và độ dài mật khẩu
Bảo mật mật khẩu không chỉ phụ thuộc vào độ dài mà còn vào chi phí tính toán của hàm băm phía máy chủ. Dưới đây là so sánh các thuật toán chính:
| Thuật toán | Tốc độ GPU (RTX 4090) | Đặc điểm |
|---|---|---|
| MD5 | ~164 tỷ/giây | Quá nhanh cho lưu trữ mật khẩu. Vẫn tồn tại trong hệ thống cũ |
| SHA-256 | ~22 tỷ/giây | Chậm hơn MD5 nhưng vẫn không đủ cho băm mật khẩu |
| bcrypt (cost=12) | ~184/giây | Cố ý chậm. Hệ số chi phí có thể điều chỉnh. Giới hạn đầu vào 72 byte |
| Argon2id | Hàng chục đến hàng trăm/giây | Người chiến thắng cuộc thi Password Hashing Competition 2015. Thiết kế memory-hard chống lại song song hóa GPU |
| scrypt | Hàng trăm đến hàng nghìn/giây | Thiết kế memory-hard. Tiền thân của Argon2 |
bcrypt cắt đầu vào ở 72 byte, nghĩa là mật khẩu chỉ dùng ASCII bị giới hạn hiệu quả ở 72 ký tự, và văn bản tiếng Nhật UTF-8 khoảng 24 ký tự. Hạn chế này ảnh hưởng trực tiếp đến độ dài mật khẩu tối đa trên một số nền tảng. Argon2id không có hạn chế như vậy và có thể xử lý mật khẩu có độ dài tùy ý. Các dịch vụ mới nên ưu tiên Argon2id.
Ngay cả với hàm băm chậm như bcrypt hoặc Argon2id, mật khẩu ngắn vẫn dễ bị tấn công từ điển và tấn công dựa trên quy tắc. Chi phí băm là chiến thuật trì hoãn; biện pháp phòng thủ cơ bản là độ dài đủ lớn (entropy).
Tại sao độ dài quan trọng hơn độ phức tạp
Nhiều dịch vụ yêu cầu "ít nhất một chữ hoa, một số và một ký hiệu", nhưng NIST rõ ràng bác bỏ cách tiếp cận này. Các con số nói lên tất cả.
"P@ssw0rd!" có 9 ký tự sử dụng cả bốn loại ký tự, nhưng nó xuất hiện trong danh sách mật khẩu bị rò rỉ hàng đầu. Trong khi đó, "mountain river cloud forest" chỉ sử dụng chữ thường và dấu cách (27 loại ký tự) với 30 ký tự, cho khoảng 142,5 bit entropy - thực tế không thể bẻ khóa bằng brute force.
Quy tắc phức tạp phản tác dụng vì ba lý do. Thứ nhất, người dùng đáp ứng yêu cầu bằng các mẫu dễ đoán (viết hoa chữ đầu, thêm "1!"). Thứ hai, mật khẩu phức tạp khó nhớ nên người dùng giữ chúng ngắn. Thứ ba, mật khẩu không thể nhớ được cuối cùng bị lưu dạng văn bản thuần trên giấy nhớ hoặc tệp văn bản.
Passphrase so với chuỗi ngẫu nhiên
Có hai cách tiếp cận để tạo mật khẩu dài: passphrase và chuỗi ký tự ngẫu nhiên. Mỗi cách có những đánh đổi riêng.
| Khía cạnh | Passphrase | Chuỗi ngẫu nhiên |
|---|---|---|
| Ví dụ | correct horse battery staple | kX9#mP2$vL7@nQ4 |
| Độ dài | 28 ký tự | 15 ký tự |
| Entropy | ~77 bit (Diceware, 6 từ) | ~98,5 bit (95 ký tự × 15) |
| Khả năng ghi nhớ | Cao (nhớ theo câu chuyện) | Thấp (cần trình quản lý mật khẩu) |
| Dễ gõ | Cao (gõ bình thường) | Thấp (ký tự đặc biệt bất tiện) |
| Khả năng chống tấn công từ điển | Phụ thuộc vào số từ và kích thước danh sách | Cực kỳ cao |
Độ mạnh của passphrase phụ thuộc vào số lượng từ và kích thước danh sách từ. Sáu từ Diceware (từ danh sách 7.776 từ) cho khoảng 77,5 bit entropy. Chỉ sử dụng các từ thông dụng hàng ngày sẽ làm yếu passphrase trước tấn công từ điển, vì vậy việc kết hợp các từ không liên quan một cách ngẫu nhiên là thiết yếu. "My cat is cute" là một passphrase kém; "chair purple submarine cayenne galaxy" mạnh hơn nhiều.
Sử dụng passphrase cho mật khẩu chính (mở khóa trình quản lý mật khẩu) và chuỗi ngẫu nhiên do trình quản lý mật khẩu tạo cho các tài khoản dịch vụ riêng lẻ.
Giới hạn mật khẩu của các dịch vụ
Giới hạn độ dài mật khẩu khác nhau rất nhiều giữa các dịch vụ. Giới hạn tối đa thường xuất phát từ ràng buộc thuật toán băm hoặc hạn chế hệ thống cũ.
| Dịch vụ | Tối thiểu | Tối đa | Ghi chú |
|---|---|---|---|
| 8 | 100 | Khuyến khích mạnh mẽ xác minh 2 bước | |
| Apple ID | 8 | Không giới hạn | Yêu cầu chữ hoa + chữ thường + số |
| Microsoft | 8 | 256 | Đang thúc đẩy xác thực không mật khẩu |
| Amazon | 6 | 128 | Tối thiểu 6 thấp hơn mức sàn NIST |
| X (Twitter) | 8 | 128 | Xác thực SMS giới hạn cho gói trả phí |
| 6 | Không giới hạn | Tối thiểu 6 thấp hơn mức sàn NIST | |
| GitHub | 8 | Không giới hạn | Kiểm tra danh sách mật khẩu bị rò rỉ |
| Ngân hàng (thông thường) | 8 | 16–32 | Tối đa ngắn thường do ràng buộc mainframe cũ |
Đáng chú ý: Amazon và Instagram cho phép tối thiểu chỉ 6 ký tự, thấp hơn mức sàn khuyến nghị 8 của NIST. Giới hạn tối đa 16–32 ký tự của dịch vụ ngân hàng thường bắt nguồn từ giới hạn 72 byte của bcrypt hoặc hệ thống mainframe cũ - một mối lo ngại bảo mật thực sự. Luôn đặt mật khẩu dài nhất mà dịch vụ cho phép.
Sức mạnh kết hợp xác thực đa yếu tố
Dù mật khẩu dài đến đâu, nó trở nên vô dụng nếu bị đánh cắp qua phishing hoặc keylogger. Độ dài mật khẩu bảo vệ chống tấn công brute-force, trong khi xác thực đa yếu tố (MFA) bảo vệ chống đánh cắp thông tin đăng nhập - các vector tấn công khác nhau bổ sung cho nhau mạnh mẽ.
- TOTP (Mật khẩu dùng một lần dựa trên thời gian): Các ứng dụng như Google Authenticator hoặc Authy tạo mã 6 chữ số làm mới mỗi 30 giây. Mã bị đánh cắp hết hạn nhanh, nhưng proxy phishing thời gian thực có thể chuyển tiếp chúng trước khi hết hạn
- FIDO2 / WebAuthn (Passkeys): Khóa bảo mật vật lý hoặc sinh trắc học thiết bị cung cấp khả năng chống phishing mạnh nhất. NIST khuyến nghị cách tiếp cận này, và Apple, Google, Microsoft đang tích cực quảng bá "passkeys" như người kế nhiệm mật khẩu
- Xác thực SMS: Tiện lợi nhưng dễ bị tấn công SIM-swap và chặn giao thức SS7. NIST phân loại SMS là phương thức xác thực "bị hạn chế" và khuyến nghị chuyển sang TOTP hoặc FIDO2 khi có thể
Thiết lập lý tưởng là mật khẩu dài (hoặc passphrase) kết hợp với khóa bảo mật FIDO2. Điều này cung cấp khả năng chống mạnh mẽ đồng thời trước tấn công brute-force, tấn công từ điển, phishing và credential stuffing.
Phương pháp tốt nhất cho trình quản lý mật khẩu
Trình quản lý mật khẩu thực tế là công cụ bắt buộc cho vệ sinh mật khẩu hiện đại - và việc chọn đúng công cụ rất quan trọng. Bạn có thể tìm hướng dẫn về trình quản lý mật khẩu và bảo mật số để có lời khuyên thiết lập thực tế. Tuy nhiên, cấu hình sai có thể tạo ra rủi ro mới.
- Mật khẩu chính: Sử dụng passphrase Diceware gồm 6+ từ (77+ bit entropy). Không bao giờ lưu mật khẩu chính ở bất kỳ đâu - chỉ ghi nhớ trong đầu
- Độ dài mật khẩu được tạo: Đặt mật khẩu dịch vụ riêng lẻ ở 20+ ký tự ngẫu nhiên. Xét giới hạn 72 byte của bcrypt, 20–64 ký tự ASCII là phạm vi thực tế tối ưu
- Tự động xóa clipboard: Bật tính năng tự động xóa clipboard sau 10–30 giây để ngăn mật khẩu đã sao chép tồn tại lâu
- Trình quản lý tích hợp trình duyệt so với chuyên dụng: Trình quản lý mật khẩu tích hợp của Chrome và Safari cung cấp mã hóa tốt, nhưng công cụ chuyên dụng cung cấp hỗ trợ đa nền tảng, kiểm tra bảo mật và kho chia sẻ cho nhóm
Kiểm tra rò rỉ và thiết kế chính sách mật khẩu
Hướng dẫn thực tế cho cả người dùng cá nhân và nhà phát triển dịch vụ:
Cho người dùng cá nhân:
- Thường xuyên kiểm tra haveibeenpwned.com để xem email của bạn có xuất hiện trong các vụ rò rỉ đã biết không. API của trang web sử dụng mô hình k-anonymity chỉ gửi 5 ký tự đầu của hash mật khẩu - mật khẩu thực của bạn không bao giờ được truyền đi
- Sử dụng tính năng kiểm tra bảo mật của trình quản lý mật khẩu để phát hiện mật khẩu yếu, thông tin đăng nhập tái sử dụng và mật khẩu bị rò rỉ trong một lần quét
- Ưu tiên các tài khoản có giá trị cao (email, tài chính, mạng xã hội). Tài khoản email xứng đáng được bảo vệ mạnh nhất vì chúng đóng vai trò kênh đặt lại mật khẩu cho các dịch vụ khác
Cho nhà phát triển dịch vụ:
- Đặt độ dài mật khẩu tối thiểu 8+ ký tự (tuân thủ NIST), khuyến nghị 12+
- Cho phép tối đa ít nhất 64 ký tự. Giới hạn ngắn không cần thiết hạn chế bảo mật người dùng
- Bỏ qua yêu cầu loại ký tự. Thay vào đó, triển khai kiểm tra mật khẩu bị rò rỉ sử dụng API như Have I Been Pwned
- Chọn Argon2id làm thuật toán băm chính, với bcrypt (hệ số chi phí 12+) làm phương án dự phòng. Không bao giờ sử dụng MD5 hoặc SHA-256 thuần cho lưu trữ mật khẩu
- Triển khai đồng hồ đo độ mạnh mật khẩu với đánh giá dựa trên entropy (thư viện như zxcvbn) để cung cấp phản hồi thời gian thực
Các lỗi thường gặp và biện pháp đối phó
- Sử dụng từ điển nguyên bản: Các từ như "sunshine", "football" và "dragon" bị tấn công từ điển bẻ ngay lập tức. Kẻ tấn công sử dụng từ điển hàng triệu từ cộng với biến đổi l33t speak (a→@, e→3) và mẫu bàn phím (qwerty, 1qaz2wsx)
- Bao gồm thông tin cá nhân: Ngày sinh, tên thú cưng và địa chỉ một phần dễ dàng đoán được từ hồ sơ mạng xã hội và rò rỉ dữ liệu. Kẻ tấn công thường xuyên xây dựng từ điển tùy chỉnh từ thông tin công khai của mục tiêu (social engineering)
- Tái sử dụng mật khẩu giữa các dịch vụ: Một vụ rò rỉ làm lộ mọi tài khoản chia sẻ mật khẩu đó. Tấn công credential stuffing tự động kiểm tra danh sách mật khẩu bị rò rỉ trên các dịch vụ khác, với tỷ lệ thành công 0,1–2%. Một triệu thông tin đăng nhập bị rò rỉ có thể xâm phạm 1.000–20.000 tài khoản
- Thay đổi tối thiểu: "MyPassword1", "MyPassword2", "MyPassword3" - tấn công dựa trên quy tắc dễ dàng tạo ra các biến thể này từ một phiên bản bị rò rỉ. Công cụ cho việc này có sẵn rộng rãi
Kết luận
Bảo mật mật khẩu phụ thuộc vào entropy, và cách hiệu quả nhất để tăng entropy là thêm độ dài. NIST SP 800-63B khuyến nghị tối thiểu 8 ký tự với 15+ được ưu tiên, và kết hợp mật khẩu dài với hàm băm chậm như bcrypt hoặc Argon2id cung cấp bảo vệ thực tế hiệu quả. Người dùng cá nhân nên tạo mật khẩu ngẫu nhiên 20+ ký tự qua trình quản lý mật khẩu, sử dụng passphrase Diceware làm mật khẩu chính. Thêm xác thực đa yếu tố dựa trên FIDO2/passkey đạt được mức phòng thủ cao nhất hiện có. Kiểm tra độ dài mật khẩu của bạn với Bộ đếm ký tự.