Hãy bắt đầu từ kết luận, vì câu trả lời rất ngắn và gần như không ai nói trọn: khi có lý do. Không phải chín mươi ngày một lần.
Thói quen đổi mật khẩu theo lịch ăn sâu đến mức nghe như chuyện vệ sinh, như đánh răng. Nhưng đó là một khuyến nghị có hạn dùng, và hạn ấy đã hết: NIST của Mỹ viết nó năm 2003, rút lại năm 2017, và tác giả tài liệu đó đã công khai xin lỗi ngay trong năm ấy. Câu chuyện đó chúng tôi kể trọn vẹn trong mật khẩu là gì; ở đây điều đáng quan tâm là phần còn lại, phần gần như không ai giải thích: hôm nay bạn phải làm gì với mật khẩu của mình.
Cuốn lịch không biết bạn có bị lấy mất gì hay không
Vấn đề của việc xoay vòng theo ngày là ngày tháng chẳng mang thông tin nào cả.
Nếu ai đó lấy được mật khẩu của bạn vào một thứ Ba tháng Hai, việc đổi nó vào ngày 1 tháng Tư vì đến hạn là tặng cho họ hơn một tháng rưỡi truy cập. Còn nếu không ai đụng tới, đổi cũng chẳng bảo vệ bạn khỏi điều gì: bạn đã thay một mật khẩu tốt bằng một mật khẩu nhiều khả năng tệ hơn, vì mật khẩu viết ra vì nghĩa vụ thì viết ra một cách hờ hững.
Toàn bộ cơ chế thất bại nằm ở đó. Xoay vòng bắt buộc không tạo ra mật khẩu mới,
nó tạo ra biến thể. Xuan2026! thành Ha2026! rồi Thu2026!, và kẻ tấn công
biết điều đó, vì chuỗi ấy dễ đoán y như cuốn lịch treo tường sinh ra nó. Hệ thống
thì hài lòng — mật khẩu «đã đổi» — còn an toàn thật sự thì giảm, chứ không tăng.
Vì thế NIST, trong SP 800-63B, nói cả hai vế cùng lúc: không đổi tùy tiện theo thời gian, và bắt buộc đổi ngay khi có dấu hiệu bị xâm phạm. Không phải đổi là vô nghĩa. Mà là yếu tố kích hoạt phải là một sự việc, không phải một ngày tháng.
Những lý do thật sự đáng kể
Đây là danh sách. Nếu bất kỳ điều nào sau đây xảy ra, mật khẩu phải đổi hôm nay, không phải tháng sau:
- Nó xuất hiện trong một vụ rò rỉ. Của chính dịch vụ đó, hoặc của bất kỳ nơi nào khác bạn dùng cùng một mật khẩu.
- Bạn dùng lại nó. Nếu
Xbị rò rỉ và bạn còn đặt nó ở bốn trang khác, thì có năm mật khẩu phải đổi, không phải một. - Bạn gõ nó vào một trang hóa ra không phải trang đó. Một email gấp gáp, một đường liên kết, một biểu mẫu trông giống hệt. Không quan trọng là hai giây sau bạn nhận ra: bạn đã gửi đi rồi.
- Bạn chia sẻ nó. Với bạn đời, với đồng nghiệp, trong nhóm trò chuyện công việc, trên một mảnh giấy. Một mật khẩu đã đi qua kênh mà bạn không kiểm soát được ai đọc thì không còn là của bạn nữa.
- Bạn thấy hoạt động lạ. Một lần đăng nhập từ nơi bạn chưa từng đặt chân, các email đặt lại mật khẩu bạn không yêu cầu, một tin nhắn đã gửi mà bạn không viết.
- Thiết bị từng bị xâm nhập. Một máy tính dính mã độc, một điện thoại bị mất, một máy xách tay đã qua tay tiệm sửa chữa lạ.
- Dịch vụ cảnh báo bạn. Khi một công ty gửi email đó, hãy xử lý ngay trong ngày. Đó đúng là trường hợp mà SP 800-63B nhắm tới.
- Một mối chung sống kết thúc. Người yêu cũ, nhà thuê chung, đối tác làm ăn. Những tài khoản trước đây của hai người, giờ chỉ còn một.
Hãy để ý điểm chung: tất cả đều là sự việc. Không cái nào là «đã qua chín mươi ngày».
Với điều đầu tiên thì có công cụ. Nếu bạn muốn biết một mật khẩu cụ thể có nằm trong các danh sách đang lưu hành hay không, và tiện thể nó chịu được bao lâu, hãy đưa nó qua trình kiểm tra: nó được phân tích ngay trong trình duyệt của bạn và không đi đâu cả.
Khi đã có lý do, thứ tự rất quan trọng
Đổi mật khẩu là bước hiển nhiên, và nhiều khi không phải bước đầu tiên. Đây là thứ tự giúp bạn khỏi phải làm lại hai lần:
Trước hết là thiết bị. Nếu bạn nghi có thứ gì đó đang cài sẵn để đọc những gì bạn gõ, đổi mật khẩu ngay trên chính chiếc máy đó chẳng khác nào trao cho kẻ ấy mật khẩu mới. Hãy dọn sạch máy, hoặc dùng một thiết bị khác trước.
Sau đó là email. Tài khoản email không phải một tài khoản như mọi tài khoản khác: nó là nơi nhận đường liên kết «quên mật khẩu» của tất cả những cái còn lại. Ai nắm email thì nắm phần còn lại qua cửa chính. Nếu chỉ có một mật khẩu để bắt đầu, đó chính là nó.
Tiếp theo, đóng các phiên đang mở. Đổi mật khẩu không phải lúc nào cũng đuổi được kẻ đã ở bên trong. Hãy tìm trong phần cài đặt tài khoản tùy chọn đăng xuất khỏi mọi thiết bị và dùng nó: nếu không, kẻ xâm nhập vẫn kết nối bằng một phiên chẳng còn cần mật khẩu của bạn nữa.
Và cuối cùng, kiểm tra xem họ đã cài lại những gì. Đây là bước nhiều người bỏ qua nhất. Kẻ vào được một tài khoản không chỉ ngồi nhìn: họ đổi email khôi phục, thêm một số điện thoại, bật yếu tố thứ hai của riêng họ, kết nối một ứng dụng, đặt một quy tắc chuyển tiếp trong hộp thư. Nếu bạn đổi mật khẩu mà không kiểm tra những thứ đó, ngày mai họ lại vào bằng một cánh cửa vẫn mở toang. Hãy rà lại phương thức khôi phục, thiết bị được ủy quyền, ứng dụng đã kết nối và quy tắc chuyển tiếp.
Còn một điều nữa, hiển nhiên đến mức bị vi phạm nhiều nhất: khi đổi, cái mới phải thật sự mới. Không phải cái cũ với một con số khác. Hãy tạo nó ở trình tạo và cất ở nơi không phụ thuộc vào trí nhớ của bạn.
Bạn làm gì trong ba trăm sáu mươi ngày còn lại
Nếu yếu tố kích hoạt là sự việc, mà sự việc thì hiếm, câu hỏi trở thành cái khác: vậy chẳng có gì để làm sao? Ngược lại. Điều mà xoay vòng cố giải quyết một cách tệ hại thì bốn việc sau giải quyết tốt, và cả bốn đều chỉ làm một lần.
Cho chúng thật dài. SP 800-63B đặt độ dài lên trước sự rối rắm: một mật khẩu dài đáng giá hơn một mật khẩu ngắn nhồi đầy ký hiệu. Phần lớn công sức nằm ở đó.
Cho mỗi nơi một mật khẩu khác nhau. Chính điều này biến vụ rò rỉ của người khác thành một sự cố nhỏ thay vì một đám cháy. Nếu mỗi tài khoản có mật khẩu riêng, một cái bị lộ không đụng đến những cái còn lại; nếu bạn dùng chung, một dịch vụ mà bạn còn chẳng nhớ đã từng dùng sẽ quyết định độ an toàn của ngân hàng bạn.
Cho chúng được đối chiếu với danh sách rò rỉ. Đó chính xác là sự thay thế mà NIST đã làm: thay vì đòi bạn một ký hiệu, hãy kiểm tra xem mật khẩu của bạn có đang lưu hành hay chưa. Phép kiểm tra ấy thì có hết hạn thật — một mật khẩu hôm nay không có trong danh sách vẫn có thể có vào năm sau — và vì thế những trình quản lý tốt tự lặp lại việc đó và báo cho bạn.
Bật yếu tố thứ hai ở mọi nơi có thể. Có yếu tố thứ hai, một mật khẩu bị đánh cắp thôi làm chiếc chìa khóa và chỉ còn là nửa chiếc.
Cả bốn cùng nhau làm được điều mà xoay vòng chưa bao giờ làm: chúng đổi mật khẩu đúng lúc có lý do, vì bạn biết được rằng có lý do. Một trình quản lý canh chừng các danh sách là một hệ thống cảnh báo; cuốn lịch không cảnh báo điều gì, nó chỉ trôi qua.
Còn nếu công ty bắt bạn đổi chín mươi ngày một lần
Chuyện đó vẫn xảy ra, và xảy ra nhiều, vì có những chính sách viết cách đây mười lăm năm mà chẳng ai mở lại. Hai điều.
Thứ nhất, thực tế: nếu buộc phải đổi, hãy đổi thật. Tạo một mật khẩu mới hoàn toàn và cất vào trình quản lý. Biến thể theo mùa là thứ duy nhất còn tệ hơn việc không đổi, vì nó tạo cảm giác đã làm được điều gì đó.
Thứ hai, dành cho ai có thể lay chuyển chính sách: bạn không phải tự nghĩ ra lý lẽ. Nó nằm trong SP 800-63B, là hướng dẫn chính thức của NIST, và nói rõ rằng không nên yêu cầu đổi mật khẩu định kỳ, và phải bắt buộc đổi khi có dấu hiệu bị xâm phạm. Ai hôm nay còn giữ quy tắc chín mươi ngày là đang theo một tài liệu mà chính cơ quan ban hành nó đã thay thế từ nhiều năm trước.
Câu trả lời ngắn, một lần nữa
Bao lâu nên đổi mật khẩu một lần? Khi có chuyện xảy ra.
Và vì «khi có chuyện xảy ra» chỉ có tác dụng nếu bạn biết là nó đã xảy ra, câu trả lời dài là: hãy làm cho mọi mật khẩu đều dài, khác nhau và được canh chừng, để đến ngày cần đổi một cái, bạn sẽ biết, chỉ có một cái, và mất của bạn hai phút.
Phần còn lại chỉ là đánh dấu một ô trong cuốn lịch để thấy mình an toàn.
Nguồn: NIST SP 800-63, «Electronic Authentication Guideline» (2003), nơi xuất hiện các quy tắc thành phần và việc đổi định kỳ · NIST SP 800-63B, «Digital Identity Guidelines: Authentication and Lifecycle Management» (2017): độ dài trước sự phức tạp, không đổi định kỳ tùy tiện, bắt buộc đổi khi có dấu hiệu bị xâm phạm và đối chiếu với danh sách mật khẩu đã lộ · phát biểu của Bill Burr, tác giả hướng dẫn năm 2003, với Wall Street Journal vào tháng 8 năm 2017.
Ảnh của Hatice Baran · Pexels