# Bao lâu nên đổi mật khẩu một lần: chỉ khi có lý do

> Câu trả lời gần như không ai đưa ra: đừng bao giờ đổi theo lịch. Hãy đổi khi có chuyện xảy ra. Đây là danh sách những gì được tính là «có chuyện», và làm gì trong quãng thời gian còn lại, tức là gần như suốt năm.

2026-09-02 · David Carrero · password.es
Original: https://password.es/vi/blog/bao-lau-nen-doi-mat-khau-mot-lan/

---

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ì](/vi/blog/mat-khau-la-gi/); ở đâ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 `X` bị 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](/vi/kiem-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](/vi/) 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.*