規則まとめ
- パスワードの長さの下限を8文字以上とする。
- パスワードの長さの上限を64文字以上とする。
- ASCII 文字を許容する。
- Unicode 文字を許容する。
- パスワードの前後の切り詰めをしない。
- Unicode 符号位置は単一文字としてカウントする。
- パスワードの「ヒント」を記録しない。
- 特別なタイプの情報の入力を求めない (例えば、あなたの最初のペットの名前はなんですか？といったもの)。
- 一般的に利用されている値、予想できる値、セキュリティ侵害を受けた値と比較する。
- 異なるパスワードを選び直す必要があるということを知らされ、異なる値の選択を求められる。
- 認証失敗の回数を制限する。
- 他の構成ルール(例えば、異なる文字種の組み合わせ)を課すべきではない。
- 認証器が侵害されている、または加入者が変更要求を行った証拠がない限り、パスワードを任意で(例えば、定期的に)変更するよう要求すべきではない。
- パスワードを表示するオプションを提供する。
- 入力文字を非表示にする。
- 承認済み暗号化を利用する。
- 保護された認証済みのチャネルを用いる。
- オフライン攻撃へ対策する形式でパスワードを保存する。
- パスワードは、ソルト値と一緒に、承認済みのハッシュを用いてハッシュ化する。
- ソルト値は、32ビット以上のランダム値で、承認済みの乱数生成器を用いて生成され、ハッシュ結果とともに記録される。
- 少なくとも繰り返し10000回のハッシュ関数を適用する。
- ハッシュ認証器から分離されて記録される鍵を用いる鍵付ハッシュ関数(例: HMAC)を利用する。
原文訳
5.1.1.2. 記憶シークレット検証主体
- 検証主体は加入者が指定した、最低8文字の記憶シークレットを要求するものとする(SHALL)。
検証主体はユーザが決定した記憶シークレットの場合は最低でも64文字とすべきである(SHOULD)。
すべての印字可能なASCII [RFC 20] 文字(スペースも同様)は記憶シークレットとして許容されるべきである(SHOULD)。
Unicode[ISO/ISC 10646:2014]文字も同様に許容されるべきである(SHOULD)。
検証主体は、最低8文字以上であることの検証に先立って、連続した複数のスペースまたは全てのスペースを除去してもよい(MAY)。
シークレット文字列の前後の切り詰めについては実施しないものとする(SHALL NOT)。
前述の長さ要求を満たす目的で、それぞれのUnicode符号位置は単一文字としてカウントされるものとする(SHALL)。
もしUnicode文字が記憶シークレットとして許容されるならば、検証主体は、Unicode Standard Annex 15 [UAX 15] の Section 12.1で定義されている”Stablized Strings”を行うために、NFKCまたはNFKD正規化のどちらかを用いた正規化処理を適用すべきである(SHOULD)。
Unicode文字を含む記憶シークレットを選択した加入者は、いくつかのエンドポイントでは異なって表現されるかもしれない文字があることを通知されるべきであり(SHOULD)、それが彼らが正しく認証を行うための能力に影響する可能性がある。この処理は記憶シークレットのバイト文字表現のハッシュ化に先立って適用される。
記憶シークレットは、CSP(例えばエンロールメント時など)また検証主体(ユーザが新しいPINを要求した時など)によりランダムに決定されるもので、最低6文字であるものとし(SHALL)、承認済み(approved)乱数生成器を利用して生成されるものとする(SHALL)。
記憶シークレット検証主体は、加入者に対して、未認証の申請者が簡単に手に入れることができる「ヒント」を記録しないものとする(SHALL NOT)。
記憶シークレットを選択する際、検証主体は加入者に対して特別なタイプの情報(例えば、あなたの最初のペットの名前はなんですか？といったもの)の入力を求めないものとする(SHALL)。
記憶シークレットの設定、変更の要求を処理する際、検証主体はシークレットの値を、一般的に利用されている値、予想できる値、セキュリティ侵害を受けた値と比較するものとする(SHALL)。
-
例えば、以下のリスト(に限定するものではない)が含んでいるものでよい(MAY):
- 過去にセキュリティ侵害にあったパスワード集
- 辞書に含まれる言葉
- サービス名や、ユーザ名、そこから派生するようなものなど、文脈によって特定可能な単語
もし選択したシークレットがリスト中に存在したら、加入者は、それが一般的に使われているため異なるシークレット値を選び直す必要があるということを知らされ、異なる値の選択を求められるものとする(SHALL)。
検証主体は、攻撃者が加入者のアカウント乗っ取りのために試みた認証失敗の回数を有効に制限するスロットリングの仕組みSection 5.2.2を実装するものとする(SHALL)。
検証主体は他の構成ルール(例えば、異なる文字種の組み合わせ)を記憶シークレットに課すべきではない(SHOULD NOT)。
検証主体は、認証器が侵害されている、または加入者が変更要求を行った証拠がない限りは、記憶シークレットを任意で(例えば、定期的に)変更するよう要求すべきではない(SHOULD NOT)。
申請者が記憶シークレットを正しく入力することを支援するために、検証主体は(典型的なドットやアスタリスク表示ではなく)シークレットを表示するオプションを提供すべき(SHOULD)である。
検証主体は、申告者が入力文字を確認するのに十分な時間表示したあとは、文字を非表示にするものとする(SHALL)。これにより、申請者は彼らのスクリーンが盗み見られている可能性が高くない場所にいるとき、自身で入力を検証することができる。
検証主体は承認済み(approved)暗号化を利用するものとし(SHALL)、記憶シークレットを要求する際には、盗聴や中間者攻撃を防止する目的で保護された認証済みのチャネルを用いるものとする(SHALL)。
検証主体は、オフライン攻撃へ対策する形式で記憶シークレットを保存するものとする(SHALL)。
シークレットは、 ソルト値と一緒に、例えば[SP800-132]で記載されているPBKDF2のような承認済み(approved)のハッシュを用いてハッシュ化されるものとする(SHALL)。
ソルト値は32ビット以上のランダム値で、承認済み(approved)の乱数生成器を用いて生成され、ハッシュ結果とともに記録される。少なくとも繰り返し10000回のハッシュ関数を適用すべきである(SHOULD)。
ハッシュ認証器から分離されて記録される鍵(例:ハードウェアセキュリティモジュール中)を用いる鍵付ハッシュ関数(例:HMAC)は、記録済みハッシュ化認証器に対する辞書攻撃に対する更なる対抗方法として利用されるべきである(SHOULD)。