- NIST dự kiến sẽ "cấm" các "yêu cầu tạo mật khẩu với nhiều kiểu ký tự khác nhau" và "yêu cầu thay đổi mật khẩu định kỳ". Đây được xem là các điểm yếu về an ninh mạng
Yêu cầu về mật khẩu
- Trình xác thực và CSP phải yêu cầu mật khẩu có độ dài tối thiểu là 8 ký tự, và nên yêu cầu tối thiểu 15 ký tự trở lên SHALL
- Trình xác thực và CSP nên cho phép độ dài mật khẩu tối đa ít nhất là 64 ký tự trở lên SHOULD
- Trình xác thực và CSP nên cho phép tất cả ký tự ASCII có thể in được và ký tự khoảng trắng trong mật khẩu SHOULD
- Trình xác thực và CSP nên cho phép ký tự Unicode trong mật khẩu. Khi đánh giá độ dài mật khẩu, mỗi mã điểm Unicode phải được tính là một ký tự đơn SHOULD
- Trình xác thực và CSP không được áp đặt các quy tắc thành phần khác đối với mật khẩu (ví dụ: yêu cầu trộn nhiều loại ký tự khác nhau) SHALL NOT
- Trình xác thực và CSP không được yêu cầu người dùng thay đổi mật khẩu theo định kỳ SHALL NOT. Tuy nhiên, nếu có bằng chứng cho thấy bộ xác thực đã bị xâm phạm thì trình xác thực phải buộc thay đổi SHALL
- Trình xác thực và CSP không được cho phép thuê bao lưu gợi ý mà người tự nhận chưa được xác thực có thể truy cập SHALL NOT
- Trình xác thực và CSP không được nhắc thuê bao sử dụng xác thực dựa trên tri thức (KBA) hoặc câu hỏi bảo mật khi chọn mật khẩu SHALL NOT
- Trình xác thực phải xác minh toàn bộ mật khẩu được gửi lên (tức là không được cắt bớt) SHALL
Các đề cập khác
- Vấn đề của các quy tắc cũ: trước đây từng có vấn đề ký tự Unicode không được lưu trữ đúng trên một số nền tảng. Nhưng hiện nay Unicode cung cấp nhiều entropy hơn
- Yêu cầu mới: hướng dẫn NIST mới sẽ bao gồm yêu cầu cho phép Unicode tùy ý. Đây là điều bắt buộc đối với phần mềm tuyên bố hỗ trợ quốc tế hóa (i18n)
- Quy tắc thành phần mật khẩu: NIST chuyển từ "không khuyến nghị" sang "không cho phép" đối với các quy tắc thành phần mật khẩu. Đây là một bước quan trọng để tăng cường bảo mật
- Xung đột với tiêu chuẩn ngành: một số tiêu chuẩn ngành (ví dụ: PCI, ISO 27001:2022) vẫn còn các yêu cầu mâu thuẫn với NIST. Điều này khiến doanh nghiệp khó tuân theo các quy tắc NIST mới
- Sử dụng trình quản lý mật khẩu: trình quản lý mật khẩu hữu ích không chỉ trên website mà còn trên nhiều hệ thống khác. Cũng có thể nhập mật khẩu chủ thông qua token phần cứng hoặc xác thực sinh trắc học
- Giới hạn độ dài mật khẩu: giới hạn độ dài mật khẩu nhằm ngăn cạn kiệt tài nguyên của hệ thống xác thực. Tuy nhiên, giới hạn quá ngắn có thể tạo ra ràng buộc nghiêm trọng đối với bảo mật
Tổng hợp của GN⁺
- Các quy tắc mật khẩu mới của NIST tăng cường bảo mật bằng cách loại bỏ những yêu cầu bảo mật cũ không cần thiết và có hại.
- Việc cho phép mật khẩu Unicode sẽ là hỗ trợ lớn cho người dùng quốc tế.
- Do xung đột với một số tiêu chuẩn ngành, doanh nghiệp có thể gặp khó khăn khi áp dụng các quy tắc mới.
- Trình quản lý mật khẩu hữu ích trên nhiều hệ thống, và có thể tăng cường bảo mật thông qua token phần cứng.
- Giới hạn độ dài mật khẩu nhằm ngăn cạn kiệt tài nguyên, nhưng giới hạn quá ngắn có thể gây ra vấn đề bảo mật.
14 bình luận
Những nơi giới hạn độ dài tối đa quá ngắn thì hơi dở thật.
Thực ra mật khẩu là
bua_trua_bachban_0212341234_suat_dac_biet_1_nguoi_quet_the
dù chỉ là tổ hợp của những "từ có sẵn", nhưng khi nối nhiều cái lại với nhau thì độ khó tăng vọt.
Công ty tôi cũng đã thay đổi quy định từ đầu năm nay, chuyển sang yêu cầu chỉ cần liệt kê 4 từ tiếng Anh bất kỳ trở lên.
Vì thế mỗi sáng tôi bắt đầu ngày mới bằng cách gõ một câu danh ngôn.
Ngay cả Coupang, nơi có văn hóa phát triển được cho là còn đỡ hơn, cũng lặng lẽ giới hạn độ dài mật khẩu ở 16 ký tự mà không có bất kỳ phản hồi trực quan nào. Cũng không có email thông báo đổi mật khẩu, nên tự dưng không đăng nhập được và tôi đã tưởng là tài khoản bị hack.
Có lẽ ngay trong lĩnh vực phát triển cũng có nhiều mảng khác nhau. Bảo mật hay khả năng truy cập dường như là những mảng tiêu biểu không được đề cập đến. Chỉ cần dành dù chỉ một phần nhỏ trong nỗ lực đổ vào dark pattern ...
Giờ kiểm tra lại thì thấy giới hạn trên đã được điều chỉnh thành 20 ký tự. Nhưng trên trang web đăng ký thành viên, họ vẫn giới hạn độ dài mật khẩu mà không có bất kỳ hướng dẫn hay phản hồi trực quan nào về mật khẩu, trong khi trang web đăng nhập thì hoàn toàn không có giới hạn. Trong khi đó, trên trang đổi mật khẩu của ứng dụng Android, các quy tắc mật khẩu lại được ghi rõ chính xác. Có vẻ như đội Android và đội frontend web không phối hợp ăn ý với nhau.
Tôi nghĩ đây là hiện tượng điển hình của sự phân mảnh theo silo.
Chẳng có gì được tuân thủ cho ra hồn cả...
Nếu có anh/chị nào phụ trách UI đang đọc cái này thì xin hãy bỏ luôn cả kiểu UI bắt buộc người dùng nhập mật khẩu bằng bàn phím ảo hiển thị trên màn hình.
Ban đầu nó xuất hiện có lẽ để ngăn mật khẩu bị lộ bởi keylogger, nhưng ngày nay nguy cơ mật khẩu bị lộ do bị camera khắp nơi ghi lại còn lớn hơn nhiều.
Đây là một kiểu UI khiến người ta bối rối mỗi lần gặp, nên thật khó hiểu khi nó vẫn còn được duy trì.
Có lẽ người ta đã quên mất rằng nó được tạo ra vì keylogger, và tôi nghi nó chỉ còn tồn tại vì ai cũng làm vậy nên cứ thế làm theo thôi.
Vì đây là hướng dẫn bảo mật của chính phủ. Chắc sẽ không có công ty nào thật sự muốn phải thêm bàn phím ảo đâu.
Trong nhiều chứng nhận tiêu chuẩn khác nhau cũng có khá nhiều nơi coi bàn phím ảo là yêu cầu bắt buộc. Những yêu cầu đó chi tiết hơn tưởng tượng nhiều, nên nếu không dùng sản phẩm hiện có (SDK) của các nhà cung cấp đã triển khai sẵn, quá trình thẩm định có thể kéo dài hơn hoặc thậm chí bị từ chối. Thật ra nhiều lúc cảm giác như đây gần như là một cartel của các công ty bảo mật vậy.
Không chỉ các cơ quan công quyền mà cả những công ty công nghệ như Naver và Coupang cũng làm vậy, nên càng khiến người ta bức bối hơn.
Có lẽ ở đó họ cũng chỉ miễn cưỡng làm theo vì chính phủ ra lệnh phải làm vậy thôi, đúng không?
Những trang có độ dài mật khẩu tối đa ngắn khoảng 12 ký tự hoặc không cho phép ký tự đặc biệt khiến tôi ngại sử dụng. Điều đó có vẻ là một trong những dấu hiệu cho thấy họ không chú trọng đến bảo mật.
Ý kiến trên Hacker News
NIST đã đưa ra hướng dẫn nới lỏng các quy tắc cấu thành mật khẩu từ năm 2017
NIST không trực tiếp đặt ra chính sách, nhưng nhiều chính sách khác tham chiếu NIST 800-63
Khi đăng ký website, các quy tắc kiểu "mật khẩu tốt phải dùng a, b, c" thật sự rất khó chịu
NIST cũng cấm cả 'câu hỏi bảo mật' (ví dụ: "Họ thời con gái của mẹ là gì?")
NIST đã đưa ra hướng dẫn mật khẩu sai trong nhiều thập kỷ, và chỉ đến bây giờ mới chuyển sang giải pháp hợp lý hơn
Có vẻ yêu cầu "phải xác minh toàn bộ mật khẩu được gửi lên" xuất hiện do vấn đề của bcrypt
NIST đề xuất độ dài mật khẩu tối đa là 64 ký tự (trong khi nhiều website giới hạn ở 20 ký tự, khiến không thể dùng passphrase)
Câu chuyện của một người dùng:
Có tranh luận về việc yêu cầu ký tự cụ thể làm tăng hay giảm entropy
Đang chờ NIST thay thế mật khẩu dạng văn bản thuần bằng PAKE, và W3C xây dựng cơ chế cho việc đó
Liên kết gốc: NIST SP 800-63b