NIST SP（Special Publication）800 シリーズは、NIST、アメリカ国立標準技術研究所（National Institute of Standards and Technology）が発行する情報セキュリティに関するガイドラインや技術研究報告書群です。

アメリカ連邦政府の情報システムにおけるセキュリティ強化を目的としたものですが、現在ではアメリカだけでなく、世界中の公的機関、民間組織からも情報セキュリティに関するベストプラクティスとして参照される、非常に有用なリソースとなっています。

この SP800 には、認証、パスワードポリシー、多要素認証などのユーザー認証に関するガイドラインがまとめられた SP800-63 がありますが、今年8月にその最新版となる第4版の最終ドラフトが更新され、公開されました。そして、その中（800-63B）で「ユーザーにパスワードの定期的な変更を求めること」が明確に否定（「SHALL NOT / してはならない」と明記）されました（パスワード定期変更に関する記述自体は第3版からありましたが、明確に禁止とはされていませんでした）。

SP800-63B 自体はボリュームのある文書ですので、今回はその一部、パスワードの要件に関する部分のみを抜粋して簡単に日本語で紹介します。

まず、この手のガイドラインを紹介する際、ガイドライン内で使用されている用語について触れておく必要があります。下記の部分をみてみましょう。太字も原文のままです。

1.1. Notations

This guideline uses the following typographical conventions in text:

  • Specific terms in CAPITALS represent normative requirements. When these same terms are not in CAPITALS, the term does not represent a normative requirement.
    • The terms "SHALL" and "SHALL NOT" indicate requirements to be strictly followed in order to conform to the publication and from which no deviation is permitted.
    • The terms "SHOULD" and "SHOULD NOT" indicate that among several possibilities, one is recommended as particularly suitable without mentioning or excluding others, that a certain course of action is preferred but not necessarily required, or that (in the negative form) a certain possibility or course of action is discouraged but not prohibited.
    • The terms "MAY" and "NEED NOT" indicate a course of action that is permissible within the limits of the publication.
    • The terms "CAN" and "CANNOT" indicate a material, physical, or causal possibility and capability or -- in the negative -- the absence of that possibility or capability.

日本語に翻訳すると下記のようになります。

1.1. 表記法

このガイドラインでは、以下の書式ルールが使用されています：

  • 特定の用語が大文字で書かれている場合、それは規範的要件を表しています。同じ用語が大文字でない場合は、規範的要件を表していません。
    • 「SHALL」および「SHALL NOT」という用語は、この文書に準拠するために厳格に従わなければならず、一切の逸脱が許されない要件を示します。
    • 「SHOULD」および「SHOULD NOT」という用語は、いくつかの選択肢の中から特に適していると推奨されるものを示していますが、他の選択肢を排除するわけではなく、ある行動が好ましいとされるが必須ではないことを示します。否定形の場合は、特定の可能性や行動が推奨されないが禁止されていないことを示します。
    • 「MAY」および「NEED NOT」という用語は、この文書の範囲内で許容される行動を示します。
    • 「CAN」および「CANNOT」という用語は、物理的、実質的、または因果関係における可能性や能力があることを示し、否定形の場合は、その可能性や能力の欠如を示します。

つまり、大文字で、

  • 「SHALL」や「SHALL NOT」となっていれば、「必須」「しなければならない」、あるいは「禁止」「してはならない」という意味。
  • 「SHOULD」や「SHOULD NOT」となっていれば、「推奨」「するべき（だが必須ではない）」、あるいは「するべきではない（だが禁止ではない）」という意味。
  • 「MAY」や「NEED NOT」となっていれば、「してもよい」、あるいは「しなくてもよい」という意味。
  • 「CAN」や「CANNOT」となっていれば、「技術的には可能」、あるいは「技術的に不可能」のような意味。

とそれぞれ解釈できます。

それを踏まえて、パスワードに関する要件について書かれた章（3.1.1. Passwords -> 3.1.1.2 Password Verifiers）をみてみましょう。まずは前半部分。

3.1.1.2. Password Verifiers

The following requirements apply to passwords:

  1. Verifiers and CSPs SHALL require passwords to be a minimum of eight characters in length and SHOULD require passwords to be a minimum of 15 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 users to change passwords periodically. However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.
  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 verify the entire submitted password (i.e., not truncate it).

日本語に翻訳すると下記のようになります（一部、冗長なので省略していたり、わかりやすく言い回しを変えている箇所があります）。なお、「検証者」というのは、要するにパスワード認証システムやそれを運用する人のことです。

3.1.1.2. パスワード検証者

以下の要件はパスワードに適用されます：

  1. パスワードの長さは、最低8文字以上とすることを必須とし、可能であれば最低15文字以上とすることを推奨します。
  2. パスワードの最大長は、少なくとも64文字まで許容することが推奨されます。
  3. パスワードに使用可能な文字として、全ての印字可能なASCII文字、およびスペース文字を受け入れることが推奨されます。
  4. パスワードに使用可能な文字として、Unicodeを受け入れることが推奨されます。各コードポイントは、パスワードの長さを評価する際に1文字として数えなければなりません。
  5. パスワードに対してその他の構成ルール（例えば、大文字と小文字、数字や記号の組み合わせを要求するなど）を課してはいけません。
  6. ユーザーにパスワードを定期的に変更することを要求してはいけません。ただし、パスワードの漏洩など、認証情報が侵害されたという証拠がある場合には、検証者はユーザーに対してパスワードの変更を強制しなければなりません。
  7. 認証されていない（ログインがまだ完了していない状態の）ユーザーがパスワードヒントにアクセス（保存）できる状態にしてはいけません。
  8. ユーザーがパスワードを選択する際に、ナレッジベース認証（KBA）（例：「あなたの最初のペットの名前は？」）や、セキュリティの質問を使用するように促してはいけません。
  9. 検証者は、送信されたパスワード全体を必ず検証しなければならず、パスワードを切り詰めてはいけません。

上記セクションには以前の第3版から含まれている内容も多いため、変更された点としては、下記の点が重要ポイントとして挙げられるでしょう。

  • パスワードの長さについて、第3版では「最低8文字以上とすることを必須とする」としながらも「検証者がランダムに選択したものであれば、最低6文字以上を必須、かつ全て数字でもよい」という記述になっていましたが、今回、「最低8文字以上とすることを必須とする」と変更し、かつ「可能であれば最低15文字以上とすることを推奨する」という文言が追加されました。
  • パスワードの定期的な変更について、第3版では「ユーザーにパスワードを定期的に変更するよう要求すべきではない」となっていた記述が、「ユーザーにパスワードを定期的に変更することを要求してはならない」という文章に変更され、パスワードの定期的な変更が明確に否定されました。

現在でも、パスワードとして指定可能な文字数が14文字以下に制限されていたり、定期的なパスワード変更を求めてくるシステムは散見されます。今一度、このような要件がセキュリティの向上には寄与しないという点を理解した上で、システムの要件定義、設計を行う必要があります。

その他にも、このガイドラインには下記のような要件が挙げられており、これらはパスワード認証システムを開発する際に重要なポイントとなりますので参考にするとよいでしょう。

Verifiers SHALL allow the use of password managers. Verifiers SHOULD permit claimants to use the "paste" functionality when entering a password to facilitate their use. Password managers have been shown to increase the likelihood that users will choose stronger passwords, particularly if the password managers include password generators.

訳：
検証者はパスワードマネージャーの使用を許可しなければなりません。また、検証者はパスワード入力の際に「貼り付け」機能を利用できるようにすることが推奨されます。

To assist the claimant in successfully entering a password, the verifier SHOULD offer an option to display the secret -- rather than a series of dots or asterisks -- while it is entered and until it is submitted to the verifier. This allows the claimant to confirm their entry if they are in a location where their screen is unlikely to be observed. The verifier MAY also permit the claimant's device to display individual entered characters for a short time after each character is typed to verify the correct entry. This is common on mobile devices.

訳：
ユーザーがパスワードを正しく入力できるように、検証者はパスワード入力時、および送信されるまで、パスワードをアスタリスク（*）などではなく、入力された文字列として表示するオプションを提供することが推奨されます。これにより、ユーザーは画面をのぞき見られる可能性が低い状況では、入力内容を確認することができます。

また、検証者はモバイルデバイスなどで一般的なように、入力した各文字を短時間だけ表示することで正しく入力できているかを確認することを許可することもできます。

弊社では以前、「パスワード入力欄のコピペ禁止はアクセシビリティを損なう」というナレッジブログ記事や、同じく「強固で安全なパスワードの設定方法」という記事で、パスワード認証システムの要件定義や設計に関する件に触れています。合わせてご参照いただければ幸いです。