パスワードの定期変更は行うべき？行わないべき？② ～NISTが示すパスワードの理想像～
前回、総務省や内閣サイバーセキュリティセンターのパスワードに対する見解と、NIST Special Publication 800-63B の見解の違いについて、記事をアップしました。
今回は、NIST Special Publication 800-63Bが示す、パスワードの理想的な設定について考えてみたいと思います。
NIST Special Publication 800-63B
5.1.1.1 Memorized Secret Authenticators（暗記認証者の記憶 ）
Memorized secrets SHALL be at least 8 characters in length if chosen by the subscriber. Memorized secrets chosen randomly by the CSP or verifier SHALL be at least 6 characters in length and MAY be entirely numeric. If the CSP or verifier disallows a chosen memorized secret based on its appearance on a blacklist of compromised values, the subscriber SHALL be required to choose a different memorized secret. No other complexity requirements for memorized secrets SHOULD be imposed. A rationale for this is presented in Appendix A Strength of Memorized Secrets.
＜Google翻訳＞
暗記された秘密は、サブスクライバーによって選択された場合、少なくとも8文字の長さでなければならない（SHALL）。CSPまたは検証者によってランダムに選択された記憶された秘密は、少なくとも6文字の長さでなければならず、完全に数字である必要があります。CSPまたは検証者が、選択された記憶された秘密を、侵害された値のブラックリスト上のその外観に基づいて許可しない場合、加入者は異なる記憶された秘密を選択する必要がある。記憶された秘密の他の複雑さ要件は課されてはならない（SHOULD）。これに関する理論的根拠は、付録A 「記憶された秘密の強さ」に示されている。
この項目は、パスワードを設定する人に関する規範となります。
要約すると、以下のポイントが重要になるかと思います。
①利用者がパスワードを設定する場合、最低8文字以上の長さが必要である。
②サービス提供者がランダムに発行するパスワードは、最低6文字以上長さで、数字のみで構成する必要がある。
③サービス提供者は、すでに破られたパスワードをブラックリスト化し、排除したほうがよい。
④これ以外の複雑さの要件は、特に必要としない。
（おそらく②はワンタイムパスワードのことを指しているのではないかと思います）
利用者側が注意すべき項目は、①のみですね。②と③はサービス提供者側に求められている要件です。
③は、すでに破られたパスワードをユーザが設定しないようにチェックする機能をつけたほうが良いとしています。ユーザがパスワードを設定する際、この機能でチェックがかかった場合は、別のパスワードを設定しなければなりません。
5.1.1.2 Memorized Secret Verifiers（暗証検証者の記憶 ）
Verifiers SHALL require subscriber-chosen memorized secrets to be at least 8 characters in length. Verifiers SHOULD permit subscriber-chosen memorized secrets at least 64 characters in length. All printing ASCII [RFC 20] characters as well as the space character SHOULD be acceptable in memorized secrets. Unicode [ISO/ISC 10646] characters SHOULD be accepted as well. To make allowances for likely mistyping, verifiers MAY replace multiple consecutive space characters with a single space character prior to verification, provided that the result is at least 8 characters in length. Truncation of the secret SHALL NOT be performed. For purposes of the above length requirements, each Unicode code point SHALL be counted as a single character.
If Unicode characters are accepted in memorized secrets, the verifier SHOULD apply the Normalization Process for Stabilized Strings using either the NFKC or NFKD normalization defined in Section 12.1 of Unicode Standard Annex 15 [UAX 15]. This process is applied before hashing the byte string representing the memorized secret. Subscribers choosing memorized secrets containing Unicode characters SHOULD be advised that some characters may be represented differently by some endpoints, which can affect their ability to authenticate successfully.
Memorized secrets that are randomly chosen by the CSP (e.g., at enrollment) or by the verifier (e.g., when a user requests a new PIN) SHALL be at least 6 characters in length and SHALL be generated using an approved random bit generator [SP 800-90Ar1].
Memorized secret verifiers SHALL NOT permit the subscriber to store a “hint” that is accessible to an unauthenticated claimant. Verifiers SHALL NOT prompt subscribers to use specific types of information (e.g., “What was the name of your first pet?”) when choosing memorized secrets.
When processing requests to establish and change memorized secrets, verifiers SHALL compare the prospective secrets against a list that contains values known to be commonly-used, expected, or compromised. For example, the list MAY include, but is not limited to:
- Passwords obtained from previous breach corpuses.
- Dictionary words.
- Repetitive or sequential characters (e.g. ‘aaaaaa’, ‘1234abcd’).
- Context-specific words, such as the name of the service, the username, and derivatives thereof.
If the chosen secret is found in the list, the CSP or verifier SHALL advise the subscriber that they need to select a different secret, SHALL provide the reason for rejection, and SHALL require the subscriber to choose a different value.
Verifiers SHOULD offer guidance to the subscriber, such as a password-strength meter [Meters], to assist the user in choosing a strong memorized secret. This is particularly important following the rejection of a memorized secret on the above list as it discourages trivial modification of listed (and likely very weak) memorized secrets [Blacklists].
Verifiers SHALL implement a rate-limiting mechanism that effectively limits the number of failed authentication attempts that can be made on the subscriber’s account as described in Section 5.2.2.
Verifiers SHOULD NOT impose other composition rules (e.g., requiring mixtures of different character types or prohibiting consecutively repeated characters) for memorized secrets. Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.
Verifiers SHOULD permit claimants to use “paste” functionality when entering a memorized secret. This facilitates the use of password managers, which are widely used and in many cases increase the likelihood that users will choose stronger memorized secrets.
In order to assist the claimant in successfully entering a memorized secret, the verifier SHOULD offer an option to display the secret — rather than a series of dots or asterisks — until it is entered. This allows the claimant to verify their entry if they are in a location where their screen is unlikely to be observed. The verifier MAY also permit the user’s device to display individual entered characters for a short time after each character is typed to verify correct entry. This is particularly applicable on mobile devices.
The verifier SHALL use approved encryption and an authenticated protected channel when requesting memorized secrets in order to provide resistance to eavesdropping and MitM attacks.
Verifiers SHALL store memorized secrets in a form that is resistant to offline attacks. Memorized secrets SHALL be salted and hashed using a suitable one-way key derivation function. Key derivation functions take a password, a salt, and a cost factor as inputs then generate a password hash. Their purpose is to make each password guessing trial by an attacker who has obtained a password hash file expensive and therefore the cost of a guessing attack high or prohibitive. Examples of suitable key derivation functions include Password-based Key Derivation Function 2 (PBKDF2) [SP 800-132] and Balloon [BALLOON]. A memory-hard function SHOULD be used because it increases the cost of an attack. The key derivation function SHALL use an approved one-way function such as Keyed Hash Message Authentication Code (HMAC) [FIPS 198-1], any approved hash function in SP 800-107, Secure Hash Algorithm 3 (SHA-3) [FIPS 202], CMAC [SP 800-38B] or Keccak Message Authentication Code (KMAC), Customizable SHAKE (cSHAKE), or ParallelHash [SP 800-185]. The chosen output length of the key derivation function SHOULD be the same as the length of the underlying one-way function output.
The salt SHALL be at least 32 bits in length and be chosen arbitrarily so as to minimize salt value collisions among stored hashes. Both the salt value and the resulting hash SHALL be stored for each subscriber using a memorized secret authenticator.
For PBKDF2, the cost factor is an iteration count: the more times the PBKDF2 function is iterated, the longer it takes to compute the password hash. Therefore, the iteration count SHOULD be as large as verification server performance will allow, typically at least 10,000 iterations.
In addition, verifiers SHOULD perform an additional iteration of a key derivation function using a salt value that is secret and known only to the verifier. This salt value, if used, SHALL be generated by an approved random bit generator [SP 800-90Ar1] and provide at least the minimum security strength specified in the latest revision of SP 800-131A (112 bits as of the date of this publication). The secret salt value SHALL be stored separately from the hashed memorized secrets (e.g., in a specialized device like a hardware security module). With this additional iteration, brute-force attacks on the hashed memorized secrets are impractical as long as the secret salt value remains secret.
＜Google翻訳＞
5.1.1.2暗証検証者の記憶
検証者は、加入者が選択した記憶された秘密が少なくとも8文字の長さであることを要求しなければならない（SHALL）。検証者は、加入者が選択した記憶された秘密を少なくとも64文字の長さで許可しなければならない（SHOULD）。すべての印刷ASCII [RFC 20]文字とスペース文字は記憶された秘密で受け入れられるべきです（SHOULD）。 Unicode [ISO / ISC 10646]文字も同様に受け入れられるべきです（SHOULD）。可能性のあるミスタイプを許容するために、検証者は、結果が少なくとも8文字の長さであれば、検証の前に複数の連続するスペース文字を1つのスペース文字に置き換えてもよい（MAY）。秘密の切り捨ては実行しないでください。上記の長さの要件のために、各Unicodeコードポイントは1文字として数えられなければならない（SHALL）。
Unicode文字が記憶された秘密に受け入れられる場合、検証者は、Unicode Standard Annex 15 [UAX 15]のセクション12.1で定義されているNFKCまたはNFKD正規化を使用して安定化文字列の正規化プロセスを適用すべきである（SHOULD ）。このプロセスは、記憶された秘密を表すバイト文字列をハッシュする前に適用されます。 Unicode文字を含む記憶された秘密を選択する加入者は、いくつかの文字がいくつかのエンドポイントによって異なって表現される可能性があることを知らされなければならない（SHOULD）。
ユーザが新しいPINを要求した場合など、CSPによって無作為に選択された（または登録時に）検証者によって記憶された秘密は、少なくとも6文字でなければならず、承認されたランダムビットジェネレータ[SP 800-90Ar1]。
記憶された秘密ベリファイアは、認証されていない主張者がアクセス可能な「ヒント」を加入者に保存させることはできません。検証者は、記憶された秘密を選択する際に、特定のタイプの情報（例えば、「最初のペットの名前は何ですか？」）を使用するようにユーザに促すべきではありません。
記憶された秘密を確立し、変更する要求を処理するとき、検証者は、潜在的に使用される、期待される、または危殆化されることが知られている値を含むリストと将来の秘密を比較しなければならない。たとえば、リストには次のものが含まれていますが、これに限定されません。
以前の侵害コーパスから取得したパスワード。
辞書の単語。
繰り返しまたは連続した文字（例： 'aaaaaa'、 '1234abcd'）。
サービスの名前、ユーザー名、およびその派生語などのコンテキスト固有の単語。
選択されたシークレットがリストに見つかった場合、CSPまたは検証者は、別の秘密を選択する必要があることを加入者に通知し、拒絶の理由を提示し、加入者に別の値を選択させる必要があります。
検証者は、ユーザが強力に記憶された秘密を選択するのを助けるために、パスワード強度計[Meters]などの加入者にガイダンスを提示すべきである（SHOULD）。これは、上記のリストに記憶されている秘密を拒否した後に、リストされた（そして非常に弱い）暗記された秘密[ブラックリスト]の簡単な変更を嫌がるので、特に重要です。
検証者は、セクション5.2.2で説明されているように、加入者のアカウントで行うことができる認証試行の失敗回数を効果的に制限するレート制限メカニズムを実装しなければならない（SHALL）。
検証者は、記憶された秘密のために他の構成ルール（例えば、異なる文字タイプの混合物を必要とするか、または連続して繰り返される文字を禁止すること）を課すべきではない（SHOULD NOT）。検証者は、記憶された秘密を任意に（例えば、定期的に）変更する必要はない（SHOULD NOT）。しかし、認証者の妥協の証拠があれば、検証者は変更を強制しなければならない（SHALL）。
ベリファイアはクレームされた秘密を入力する際に "ペースト"機能を使うべきである（SHOULD）。これは、広く使用されているパスワードマネージャの使用を容易にし、多くの場合、ユーザが記憶されたより強力な秘密を選択する可能性を高める。
申請者が記憶された秘密をうまく入力するのを助けるために、検証者は、それが入力されるまで、一連のドットまたはアスタリスクではなく秘密を表示するべきである（SHOULD）。これにより、申請者は、画面が見えにくい場所にいる場合に申請者の入力を確認することができます。検証者はまた、正しい文字列を検証するために各文字がタイプされた後、短い時間の間にユーザの装置が個々の入力文字を表示することを許可してもよい（MAY）。これは特にモバイルデバイスに適用されます。
検証者は、盗聴とMitM攻撃に抵抗するために、記憶された秘密を要求するときに、承認された暗号化と認証された保護されたチャネルを使用する（SHALL）。
検証者は、記憶された秘密をオフライン攻撃に耐性のある形で格納する（SHALL）。記憶された秘密は、適切な一方向キー導出機能を使用して塩漬けされハッシュされる。キー導出関数は、パスワード、塩、およびコスト係数を入力として受け取り、パスワードハッシュを生成します。 彼らの目的は、パスワードハッシュファイルを入手した攻撃者が各パスワードを試して推測させることです。そのため、推測攻撃のコストは高くなるか、または法外なものになります。適切なキー導出関数の例には、パスワードベースのキー導出関数2（PBKDF2）[SP 800-132 ]およびバルーン[ボールン]が含まれる。メモリハード関数は、攻撃のコストを増加させるために使用すべきである（SHOULD）。鍵の導出関数は、鍵付きハッシュメッセージ認証コード（HMAC）[FIPS 198-1]、SP 800-107、Secure Hash Algorithm 3（SHA-3）で承認された任意のハッシュ関数[FIPS 202]、CMAC [SP 800-38B]またはKecacakメッセージ認証コード（KMAC）、カスタマイズ可能なシェイク（cSHAKE）、またはパラレルハッシュ[SP 800-185]。キー導出関数の選択された出力長は、基本的な一方向関数出力の長さと同じでなければならない（SHOULD）。
ソルトは少なくとも32ビットの長さでなければならず、格納されたハッシュ間のソルト値の衝突を最小にするために任意に選択されるべきである（SHALL）。ソルト値と結果のハッシュは、記憶された秘密オーセンティケータを使用して各加入者ごとに格納される。
PBKDF2の場合、コスト係数は反復回数です.PBKDF2関数が反復される回数が増えるほど、パスワードハッシュを計算するのに時間がかかります。したがって、反復回数は検証サーバのパフォーマンスが許す限り、通常10,000回以上の反復回数であるべきです（SHOULD）。
さらに、検証者は秘密で検証者にのみ知られている塩の値を使用して、鍵の導出関数の追加の反復を実行すべきである（SHOULD）。このソルト値は、使用する場合、承認されたランダムビット発生器によって発生するもの[SP 800-90Ar1]と少なくともの最新版で指定された最小セキュリティ強度提供SP 800-131Aをこの刊行物の日付のように（112ビットを）。秘密の塩の値は、ハッシュされた記憶された秘密とは別に（例えば、ハードウェアセキュリティモジュールのような特殊な装置に）保存されるべきである（SHALL）。この追加の反復では、ハッシュされた記憶された秘密に対するブルートフォース攻撃は、秘密のソルト値が秘密のままである限り実用的ではありません。
とても長いですね。
ここは検証者、つまりパスワードを確認するサービス提供者側に求められている項目になります。
①サービス提供者は、パスワードの設定を求めるなら以下の基準を満たす必要がある。
1)8文字以上のパスワードを要求する。
2)少なくとも64文字までのパスワードを受け入れる。
3)すべてのASCII文字、スペース、Unicodeをパスワードとして受け入れる。
4)8文字以上の長さであれば、複数の連続するスペースを１つのスペースに置き換えても良い。
5)Unicodeのコードポイントは1文字として数える。
6)Unicodeをパスワードとして受け入れるのであれば、UAX15セクション12.1に定義さるNFKCまたはNFKD正規化を使用して安定化文字列の正規化プロセスを適用する。
7)いわゆる「秘密の質問」（母親の旧姓は？出身地は？などの質問）を設定するよう促すべきではない。
8)パスワード設定時、変更時は次のようなリストと比較して、一致する場合はその根拠を示し、他のパスワードを設定させる必要がある。
a.過去に突破されたことがあるパスワード
b.辞書に載っている単語
c.繰り返し、または連続した文字（例：aaaaa abc1234 等）
d.サービスの名前、ユーザの名前、およびその派生語などの推測されやすい固有の単語
※リストの代表的なものを示しましたが、内容はこれに限らない。
9)パスワードの強度計などのガイダンスを提示すべきである。
10)英数記号混在のパスワードにさせる、連続して繰り返す文字を禁止するなど、他の構成ルールを課すべきではない。
11)パスワードを定期的に変更する必要はない。
12)パスワードが漏れた場合は、変更を強制しなければならない。
②サービス提供者は、CSPなどによって無作為に生成されるパスワードを発行する場合、以下の基準を満たす必要がある。
1)6文字以上のパスワードを発行する。
③サービス提供者は、ユーザにパスワードを入力させる際には、以下の基準を満たす必要がある。
1)誰でも見れる場所に「ヒント」を表示させてはならない。
2)認証の失敗回数によって、認証を制限するメカニズムを実装しなければならない。
3)パスワード入力の際に「ペースト」機能を使用させるべきである。
4)パスワード入力時には、「.」や「*」でなく、パスワードを表示するべきである。
もしくは、短時間の間、入力した文字を表示させる方法でもよい。
5)パスワードを入力させる際には、暗号化し、認証された保護チャネルを使用する。
④サービス提供者は、パスワードを保管する際には、以下の基準を満たす必要がある。
1)記憶された秘密をオフライン攻撃に耐性のある形で格納する必要がある。
2)攻撃コストを増加させるため、メモリハード関数を使用すべきである。
3)saltは少なくとも32ビットの長さでなければならない。
4)反復回数は、サーバのパフォーマンスが許す限り、1万回以上行うべきである。
5)サービス提供者のみが知っているsaltの値を使用して、鍵の導出関数の追加の反復を実行すべきである。
6)パスワードのsaltは、ハッシュされたパスワードとは別に保存すべきである。
Appendix A—Strength of Memorized Secrets（記憶された秘密の強さ）
A.1 Introduction（はじめに）
Despite widespread frustration with the use of passwords from both a usability and security standpoint, they remain a very widely used form of authentication [Persistence]. Humans, however, have only a limited ability to memorize complex, arbitrary secrets, so they often choose passwords that can be easily guessed. To address the resultant security concerns, online services have introduced rules in an effort to increase the complexity of these memorized secrets. The most notable form of these is composition rules, which require the user to choose passwords constructed using a mix of character types, such as at least one digit, uppercase letter, and symbol. However, analyses of breached password databases reveal that the benefit of such rules is not nearly as significant as initially thought [Policies], although the impact on usability and memorability is severe.
Complexity of user-chosen passwords has often been characterized using the information theory concept of entropy [Shannon]. While entropy can be readily calculated for data having deterministic distribution functions, estimating the entropy for user-chosen passwords is difficult and past efforts to do so have not been particularly accurate. For this reason, a different and somewhat simpler approach, based primarily on password length, is presented herein.
Many attacks associated with the use of passwords are not affected by password complexity and length. Keystroke logging, phishing, and social engineering attacks are equally effective on lengthy, complex passwords as simple ones. These attacks are outside the scope of this Appendix.
＜Google翻訳＞
ユーザビリティとセキュリティの観点からパスワードを使用することに対する広範囲な不満にもかかわらず、それらは非常に広く使用されている認証の形態です[Persistence]。しかし、人間は複雑で恣意的な秘密を覚える能力は限られているので、簡単に推測できるパスワードを選ぶことがよくあります。結果として生じるセキュリティ問題に対処するために、オンラインサービスでは、これらの暗記された秘密の複雑さを増やすための規則が導入されています。これらの最も顕著な形式は、ユーザーが少なくとも1桁の数字、大文字、記号などの文字タイプを組み合わせて作成したパスワードを選択するように要求する合成ルールです。しかし、侵害されたパスワードデータベースの分析では、このようなルールの利点は、当初思ったほど重要ではないことが明らかになりました[ポリシー]、ただし、ユーザビリティと記憶力への影響は厳しいものです。
ユーザが選択したパスワードの複雑さは、しばしばエントロピー[シャノン]の情報理論の概念を用いて特徴付けられてきた。決定論的分布関数を有するデータに対してエントロピーを容易に計算することができるが、ユーザが選択したパスワードのエントロピーを推定することは困難であり、これを行うための過去の努力は特に正確ではない。このため、主にパスワードの長さに基づいて異なる、やや簡単なアプローチがここに示されています。
パスワードの使用に関連する多くの攻撃は、パスワードの複雑さと長さの影響を受けません。キーストロークのロギング、フィッシング、ソーシャルエンジニアリングの攻撃は、複雑で長すぎるパスワードを単純なものと同等に効果的です。これらの攻撃は、この付録の範囲外です。
この付録の目的が書かれていますね。要約すれば、パスワードという認証そのものに不満が多く、扱い方次第で、簡単に突破されるので、人が取り扱いやすく、かつ、強度の高いパスワードの設定方法のアプローチを示しますということでしょうか。
A.2 Length（長さ）
Password length has been found to be a primary factor in characterizing password strength [Strength] [Composition]. Passwords that are too short yield to brute force attacks as well as to dictionary attacks using words and commonly chosen passwords.The minimum password length that should be required depends to a large extent on the threat model being addressed. Online attacks where the attacker attempts to log in by guessing the password can be mitigated by limiting the rate of login attempts permitted. In order to prevent an attacker (or a persistent claimant with poor typing skills) from easily inflicting a denial-of-service attack on the subscriber by making many incorrect guesses, passwords need to be complex enough that rate limiting does not occur after a modest number of erroneous attempts, but does occur before there is a significant chance of a successful guess.
Offline attacks are sometimes possible when one or more hashed passwords is obtained by the attacker through a database breach. The ability of the attacker to determine one or more users’ passwords depends on the way in which the password is stored. Commonly, passwords are salted with a random value and hashed, preferably using a computationally expensive algorithm. Even with such measures, the current ability of attackers to compute many billions of hashes per second with no rate limiting requires passwords intended to resist such attacks to be orders of magnitude more complex than those that are expected to resist only online attacks.
Users should be encouraged to make their passwords as lengthy as they want, within reason. Since the size of a hashed password is independent of its length, there is no reason not to permit the use of lengthy passwords (or pass phrases) if the user wishes. Extremely long passwords (perhaps megabytes in length) could conceivably require excessive processing time to hash, so it is reasonable to have some limit.
＜Google翻訳＞
パスワードの長さは、パスワードの強度を特徴づける主要な要因であることが判明しています[Strength] [Composition]。短すぎるパスワードは、無差別攻撃だけでなく、単語や一般的に選択されたパスワードを使用した辞書攻撃にも適用されます。
必要なパスワードの最小長は、対処される脅威モデルによって大きく左右されます。攻撃者がパスワードを推測してログインしようとするオンライン攻撃は、許可されたログイン試行の割合を制限することで軽減できます。攻撃者（またはタイピング能力の低い永続的な主張者）が誤った推測を多くして加入者に対するサービス拒否攻撃を容易にしないようにするには、パスワードは控えめにしてもレートリミットが起こらないほど複雑である必要があります間違った試行の回数が発生しますが、成功する見込みが大きくなる前に発生します。
オフライン攻撃は、攻撃者がデータベース侵害によって1つまたは複数のハッシュされたパスワードを取得したときに、時々起こる可能性があります。 1つまたは複数のユーザーのパスワードを決定する攻撃者の能力は、パスワードの格納方法によって異なります。一般的に、パスワードは、好ましくは計算コストの高いアルゴリズムを使用して、ランダム値とハッシュで塩漬けされる。このような措置を講じても、レート制限なしで毎秒何十億ものハッシュを計算する現在の攻撃者の能力は、そのような攻撃に対抗するためのパスワードは、オンライン攻撃のみに抵抗するものよりも複雑なオーダーでなければなりません。
ユーザは、理由の中で、自分のパスワードを望みどおりに長くするよう奨励されるべきです。ハッシュされたパスワードのサイズはその長さとは無関係であるため、ユーザーが望む場合は長いパスワード（またはパスフレーズ）の使用を許可しない理由はありません。極端に長いパスワード（おそらくはメガバイト）は、ハッシュ処理に過剰な処理時間がかかる可能性があるため、いくらか制限があるのは妥当です。
まとめると、以下のようになるかと思います。
①パスワードの最小の長さは、サービスや脅威によって異なる。
1)オンラインで使用する場合、ログイン回数に制限をかけることで極端に短くなければ、ある程度短いパスワードでも安全といえる。
2)オフラインでの攻撃は、攻撃者がハッシュされたパスワードを取得するところからはじまるため、その解析を複雑にするために長いパスワードが有効である。
②ユーザは、自分の希望する長いパスワードを設定することができるのが理想である。
A.3 Complexity（複雑さ）
As noted above, composition rules are commonly used in an attempt to increase the difficulty of guessing user-chosen passwords. Research has shown, however, that users respond in very predictable ways to the requirements imposed by composition rules [Policies]. For example, a user that might have chosen “password” as their password would be relatively likely to choose “Password1” if required to include an uppercase letter and a number, or “Password1!” if a symbol is also required.
Users also express frustration when attempts to create complex passwords are rejected by online services. Many services reject passwords with spaces and various special characters. In some cases, the special characters that are not accepted might be an effort to avoid attacks like SQL injection that depend on those characters. But a properly hashed password would not be sent intact to a database in any case, so such precautions are unnecessary. Users should also be able to include space characters to allow the use of phrases. Spaces themselves, however, add little to the complexity of passwords and may introduce usability issues (e.g., the undetected use of two spaces rather than one), so it may be beneficial to remove repeated spaces in typed passwords prior to verification.
Users’ password choices are very predictable, so attackers are likely to guess passwords that have been successful in the past. These include dictionary words and passwords from previous breaches, such as the “Password1!” example above. For this reason, it is recommended that passwords chosen by users be compared against a “black list” of unacceptable passwords. This list should include passwords from previous breach corpuses, dictionary words, and specific words (such as the name of the service itself) that users are likely to choose. Since user choice of passwords will also be governed by a minimum length requirement, this dictionary need only include entries meeting that requirement.
Highly complex memorized secrets introduce a new potential vulnerability: they are less likely to be memorable, and it is more likely that they will be written down or stored electronically in an unsafe manner. While these practices are not necessarily vulnerable, statistically some methods of recording such secrets will be. This is an additional motivation not to require excessively long or complex memorized secrets.
＜Google翻訳＞
上記のように、構成ルールは、ユーザーが選択したパスワードを推測することの難しさを増やすために一般的に使用されます。しかし、研究者は、構成ルール[ポリシー]によって課せられた要件に、ユーザーが非常に予測可能な方法で応答することを示しています。たとえば、パスワードとして「パスワード」を選択したユーザーは、大文字と数字を含む必要がある場合は「Password1」、記号も必要な場合は「Password1！」を選択する可能性が比較的高くなります。
複雑なパスワードを作成しようとする試みがオンラインサービスによって拒否されると、ユーザーはまた不満を表明します。多くのサービスは、スペースとさまざまな特殊文字を含むパスワードを拒否します。場合によっては、受け入れられない特殊文字は、それらの文字に依存するSQLインジェクションのような攻撃を避けるためのものです。しかし、適切にハッシュ化されたパスワードは、いかなる場合でもデータベースにそのまま送られることはないので、そのような予防措置は不要です。フレーズを使用できるようにスペース文字を含めることもできます。しかし、スペース自体はパスワードの複雑さを少し増やし、使い勝手の問題（例えば、1つではなく2つのスペースの検出されない使用）を導入する可能性があるため、検証前に入力されたパスワードの繰り返しスペースを削除すると効果的です。
ユーザーのパスワードは非常に予測可能であるため、攻撃者は過去に成功したパスワードを推測する可能性があります。これには、上記の「Password1！」の例のような、以前の違反の辞書の単語やパスワードが含まれます。このため、ユーザーが選択したパスワードと、許容できないパスワードの「ブラックリスト」を比較することをお勧めします。このリストには、以前の違反コーパス、辞書の単語、およびユーザーが選択する可能性が高い特定の単語（サービス自体の名前など）のパスワードが含まれている必要があります。ユーザーのパスワード選択には最小長要件が適用されるため、この辞書はその要件を満たすエントリのみを含める必要があります。
非常に複雑に記憶された秘密は、新たな潜在的な脆弱性をもたらします。記憶に残る可能性は低く、電子的に安全でない方法で書き留められたり保存される可能性が高くなります。これらの慣習は必ずしも脆弱ではありませんが、統計的にはそのような秘密を記録するいくつかの方法があります。これは、過度に長く複雑な記憶された秘密を必要としないという追加的な動機である。
まとめると、以下のようになるかと思います。
①英数字記号混在などの複雑すぎるパスワードを求めると、ユーザが不満を募らせる。また、安全でない方法（付箋でモニタに貼りつけるなど？）でパスワードが管理されるリスクが高くなる。
②ハッシュ化されたパスワードであれば、スペースや特殊文字を含めても問題はない。
③ユーザのパスワードは攻撃者にとっても予測しやすいため、ブラックリストを作成して、それに該当するとパスワードを弾く仕組みが良い。リストは以下の内容が考えられる。
1)漏えいしたパスワード
2)辞書の単語
3)ユーザが選択する可能性が高い特定の単語
なお、長さの最小要件が適用されるため、この辞書には要件を満たすものだけを入れておけばよい。
A.4 Randomly-Chosen Secrets（ランダムに選ばれた秘密 ）
Another factor that determines the strength of memorized secrets is the process by which they are generated. Secrets that are randomly chosen (in most cases by the verifier or CSP) and are uniformly distributed will be more difficult to guess or brute-force attack than user-chosen secrets meeting the same length and complexity requirements. Accordingly, at LOA2, SP 800-63-2 permitted the use of randomly generated PINs with 6 or more digits while requiring user-chosen memorized secrets to be a minimum of 8 characters long.
As discussed above, the threat model being addressed with memorized secret length requirements includes rate-limited online attacks, but not offline attacks. With this limitation, 6 digit randomly-generated PINs are still considered adequate for memorized secrets.
＜Google翻訳＞
記憶された秘密の強さを決定する別の要因は、それらが生成されるプロセスです。ランダムに選択された（ほとんどの場合、検証者またはCSPによって）一様に分散された秘密は、同じ長さおよび複雑さの要件を満たすユーザが選択した秘密よりも推測またはブルートフォース攻撃が困難です。したがって、LOA2では、SP 800-63-2は、ランダムに生成された6桁以上のPINの使用を許可し、ユーザーが選択した記憶済みの秘密は最低8文字の長さにする必要がありました。
上記のように、記憶された秘密の長さの要件に対応する脅威モデルには、レート制限オンライン攻撃が含まれますが、オフライン攻撃は含まれません。この制限により、6桁のランダムに生成されたPINは、依然として記憶された秘密に十分であると考えられる。
A.5 Summary（要約 ）
Length and complexity requirements beyond those recommended here significantly increase the difficulty of memorized secrets and increase user frustration. As a result, users often work around these restrictions in a way that is counterproductive. Furthermore, other mitigations such as blacklists, secure hashed storage, and rate limiting are more effective at preventing modern brute-force attacks. Therefore, no additional complexity requirements are imposed.
＜Google翻訳＞
長さと複雑さの要件は、ここで推奨されているものを超えると、記憶された秘密の難易度を大幅に高め、ユーザーの不満を増大させます。その結果、ユーザーはしばしばこのような制限を回避することができます。さらに、ブラックリスト、セキュアハッシュストレージ、レート制限などの他の緩和策は、現代のブルートフォース攻撃を防止する上でより効果的です。したがって、複雑さの追加要件は課されません。
まとめ
NIST Special Publication 800-63Bをまとめると、以下のようになるかと思います。
実施しなければならない＝赤文字
実施すべきである＝青文字
実施してもよい＝黒文字
利用者がパスワードを設定する場合の指針
①最低8文字以上の長さでパスワードを設定する。
②サービス提供者が用意したブラックリストに存在しないパスワードを設定する。
③これ以上の複雑さは、必要としない。
※パスワード設定の際は、以下の内容を参考にする。
求められるパスワードの最小の長さは、サービスや脅威によって異なる。
1)オンラインで使用する場合、ログイン回数に制限をかけることで極端に短くなければ、ある程度短いパスワードでも安全といえる。
2)オフラインでの攻撃は、攻撃者がハッシュされたパスワードを取得するところからはじまるため、その解析を複雑にするために長いパスワードが有効である。
ユーザは、自分の希望する長いパスワードを設定することができるのが理想である。
サービス提供者がパスワードを要求する場合の指針
パスワードの設定に関する指針
①サービス提供者がランダムに発行するパスワードは、最低6文字以上長さで、数字のみで構成する。
②ユーザにパスワードを設定させる場合は、以下の基準で設定させる。
1)8文字以上のパスワード
2)最低でも64文字以上のパスワードの受け入れ
3)すべてのASCII文字、スペース、Unicodeをパスワードとして受け入れ
4)複数の連続するスペースを１つのスペースに置き換え
5)Unicodeのコードポイントは1文字として数える。
6)Unicodeをパスワードとして受け入れるのであれば、UAX15セクション12.1に定義さるNFKCまたはNFKD正規化を使用して安定化文字列の正規化プロセスを適用する。
7)いわゆる「秘密の質問」（母親の旧姓は？出身地は？などの質問）を設定するよう促すべきではない。
8)パスワード設定時、変更時は次のようなリストと比較して、一致する場合はその根拠を示し、他のパスワードを設定させる必要がある。
a.過去に突破されたことがあるパスワード
b.辞書に載っている単語
c.繰り返し、または連続した文字（例：aaaaa abc1234 等）
d.サービスの名前、ユーザの名前、およびその派生語などの推測されやすい固有の単語
※リストの代表的なものを示しましたが、内容はこれに限らない。
10)パスワードの強度計などのガイダンスを提示すべきである。
11)英数記号混在のパスワードにさせる、連続して繰り返す文字を禁止するなど、他の構成ルールを課すべきではない。
12)パスワードを定期的に変更する必要はない。
13)パスワードが漏れた場合は、変更を強制しなければならない。
※パスワードを設定させる際は、以下の内容を参考にする。
1)英数字記号混在などの複雑すぎるパスワードを求めると、ユーザが不満を募らせる。また、安全でない方法（付箋でモニタに貼りつけるなど？）でパスワードが管理されるリスクが高くなる。
2)ハッシュ化されたパスワードであれば、スペースや特殊文字を含めても問題はない。
パスワードの入力に関する指針
①サービス提供者は、ユーザにパスワードを入力させる際には、以下の基準を満たす必要がある。
1)誰でも見れる場所に「ヒント」を表示させてはならない。
2)認証の失敗回数によって、認証を制限するメカニズムを実装しなければならない。
3)パスワード入力の際に「ペースト」機能を使用させるべきである。
4)パスワード入力時には、「.」や「*」でなく、パスワードを表示するべきである。
もしくは、短時間の間、入力した文字を表示させる方法でもよい。
5)パスワードを入力させる際には、暗号化し、認証された保護チャネルを使用する。
パスワードの保管に関する指針
①サービス提供者は、パスワードを保管する際には、以下の基準を満たす必要がある。
1)記憶された秘密をオフライン攻撃に耐性のある形で格納する必要がある。
2)攻撃コストを増加させるため、メモリハード関数を使用すべきである。
3)saltは少なくとも32ビットの長さでなければならない。
4)反復回数は、サーバのパフォーマンスが許す限り、1万回以上行うべきである。
5)サービス提供者のみが知っているsaltの値を使用して、鍵の導出関数の追加の反復を実行すべきである。
6)パスワードのsaltは、ハッシュされたパスワードとは別に保存すべきである。
次の記事
