NIST 的密碼原則參考 (2025.08.26)

NIST 對密碼原則的建議改版了

NIST Special Publication 800-63B 3.1.1.2 Password Verifiers

The following requirements apply to passwords:
1. Verifiers and CSPs SHALL require passwords that are used as a single-factor authentication mechanism to be a minimum of 15 characters in length. Verifiers and CSPs MAY allow passwords that are only used as part of multi-factor authentication processes to be shorter but SHALL require them to be a minimum of eight characters in length.

2. Verifiers and CSPs SHOULD permit a maximum password length of at least 64 characters.

3. Verifiers and CSPs SHOULD accept all printing ASCII [RFC20] characters and the space character in passwords.

4. Verifiers and CSPs SHOULD accept Unicode [ISO/ISC 10646] characters in passwords. Each Unicode code point SHALL be counted as a single character when evaluating password length.

5. Verifiers and CSPs SHALL NOT impose other composition rules (e.g., requiring mixtures of different character types) for passwords.

6. Verifiers and CSPs SHALL NOT require subscribers to change passwords periodically. However, verifiers SHALL force a change if there is evidence that the authenticator has been compromised.

7. Verifiers and CSPs SHALL NOT permit the subscriber to store a hint that is accessible to an unauthenticated claimant.

8. Verifiers and CSPs SHALL NOT prompt subscribers to use knowledge-based authentication (KBA) (e.g., “What was the name of your first pet?”) or security questions when choosing passwords.

9. Verifiers SHALL request the password to be provided in full (not a subset of it) and SHALL verify the entire submitted password (e.g., not truncate it).

以下為 Gemini 機翻, 翻譯得還不錯

1. 單一因素驗證： 驗證方（Verifiers）與雲端服務提供者（CSPs）**應（SHALL）**要求作為單一因素身分驗證機制的密碼，長度至少須為 15 個字元。 多因素驗證： 若密碼僅作為多因素驗證流程的一部分，驗證方與 CSPs **可（MAY）允許較短的長度，但應（SHALL）**要求長度至少須為 8 個字元。

這很基本, 沒有什麼問題.

2. 最大長度： 驗證方與 CSPs **宜（SHOULD）**允許最大密碼長度至少達 64 個字元。

3. 字元類型： 驗證方與 CSPs **宜（SHOULD）**接受所有可列印的 ASCII [RFC20] 字元以及空白字元。

4. Unicode 支援： 驗證方與 CSPs **宜（SHOULD）**接受密碼中使用 Unicode [ISO/ISC 10646] 字元。在計算密碼長度時，每個 Unicode 碼點（Code Point）**應（SHALL）**被視為單一字元。

以上幾條可能影響不小, 舊的認證程式和資料庫欄位都要做相當的修改.

5. 組成規則： 驗證方與 CSPs **不得（SHALL NOT）**對密碼強制執行其他組成規則（例如：要求必須包含不同類型的字元組合）。

6. 定期更換： 驗證方與 CSPs **不得（SHALL NOT）要求使用者定期更換密碼。然而，若有證據顯示驗證器已遭到破解，驗證方應（SHALL）**強制執行密碼變更。

這兩條有一些台灣老公司的懶惰 MIS 很愛用, 但是現在 NIST 是強烈的要求不得這樣做, 我想主要也是因為這種老舊的密碼原則太麻煩了, 反而會增加社交工程的風險.
(話說我現在的公司就是這樣, 有夠討厭的)

7. 密碼提示： 驗證方與 CSPs **不得（SHALL NOT）**允許使用者儲存未經身分驗證的請求者即可存取的密碼提示（例如：關於密碼如何建立的提醒）。

這點很重要.

8. 知識型驗證： 驗證方與 CSPs 在設定密碼時，**不得（SHALL NOT）**提示使用者使用知識型驗證（KBA，例如：「你第一隻寵物的名字是什麼？」）或安全提問。

這也是以前很流行的東西, 不過也是有很高的社交工程風險.

9. 完整驗證： 驗證方**應（SHALL）要求提供完整的密碼（而非其中一部分），且應（SHALL）**驗證所提交的完整密碼（例如：不得將其截斷）。

這個應該和上面 2~4 條有關係, 如果 MIS 偷攋不想改認證程式和資料庫, 有可能會用這種偷吃步的方法, 造成風險提高.




上面的問題在台灣很多大公司都還看得到, 不過我想大部分公司的懶惰 MIS 應該是不會甩 NIST 的吧.
畢竟在台灣擔任 MIS 的門檻很低, 濫竽充數的太多了, 我甚至還遇過上櫃公司(8xx1)的 MIS 連自己公司的 domain name 都不知道怎麼來的, 然後 domain name 過期公司官網連不到, 打電話給我求救.