V2: 認証
Last updated
Was this helpful?
Last updated
Was this helpful?
認証とは誰か (あるいは何か) を真正であるとして確立または確認する行為であり、個人またはデバイスに関する申し出は正しく、なりすましに耐性があり、パスワードの回復や傍受を防ぐことです。
ASVS が最初にリリースされたとき、ユーザ名 + パスワードは高度なセキュリティシステム以外で最も一般的な認証形式でした。多要素認証 (Multi-factor Authentication, MFA) はセキュリティサークルで一般的に受け入れられていますが、他ではほとんど必要とされていません。パスワード侵害の数が増加するにつれ、ユーザ名は何かしらの形で機密情報であり、パスワードは不明であるという考えでは、多くのセキュリティ管理策は維持できなくなりました。例えば、NIST 800-63 はユーザ名とナレッジベース認証 (Knowledge Based Authentication, KBA) を公開情報、SMS および電子メール通知を 、パスワードを pre-breached としています。この本質は、知識ベースの認証符号、SMS および電子メールでのリカバリー、パスワード履歴、複雑さ、ローテーション管理を無用とします。これらの管理はまったく役に立たず、ユーザは数か月ごとに脆弱なパスワードを考えてきました。しかし、50億を超えるユーザ名とパスワード侵害のリリースにより、先に進む時がきました。
ASVS のすべての章の中で、認証とセッション管理の章が最も変更されています。効果的で、エビデンスベースのリーディングプラクティスの採用は多くの人にとって挑戦となるでしょうが、それはまったく問題ありません。今ここでポストパスワードの将来への移行を開始する必要があります。
は最新のエビデンスベースの標準であり、適用可能性とは関係なく、利用可能な最適なアドバイスを表しています。この標準は世界中のすべての組織に役立ちますが、特に米国の代理店および米国の代理店を扱う組織に関連します。
NIST 800-63 の用語は、特にユーザ名 + パスワードの認証にしか慣れていない場合には、最初は少しわかりにくいかもしれません。最新の認証に進歩する必要があるため、将来一般的になるであろう用語を導入する必要がありますが、業界がこれらの新しい用語に落ち着くまで理解の難しさを理解しています。この章の最後に支援のための用語集があります。要件の表記ではなく、要件の意図を満たすために多くの要件を言い換えました。例えば、NIST が「記憶された秘密 (memorized secret)」を使用する場合、ASVS では「パスワード」という用語を使用します。
ASVS V2 認証、V3 セッション管理、および範囲は狭いですが、V4 アクセス制御は選択された NIST 800-63b 管理策の準拠サブセットに適応し、一般的な脅威と一般的に悪用される認証の脆弱性に焦点を当てています。NIST 800-63 に完全に準拠する必要がある場合には、NIST 800-63 を確認してください。
アプリケーションセキュリティ検証標準は ASVS L1 を NIST AAL1 要件に、L2 を AAL2 に、L3 を AAL3 にマップしようとしました。しかし、「必須」管理策としての ASVS レベル 1 のアプローチはアプリケーションや API を検証するための正しい AAL レベルであるとは限りません。例えば、アプリケーションがレベル 3 アプリケーションである場合や AAL3 とする規制要件がある場合には、章 V2 および V3 セッション管理でレベル 3 を選択すべきです。NIST 準拠の認証アサーションレベル (Authentication Assertion Level, AAL) の選択は NIST-63b ガイドラインに従って実行すべきです。 の Selecting AAL に記載されています。
特に最新の認証がアプリケーションのロードマップ上にある場合には、アプリケーションは常に現在のレベルの要件を超える可能性があります。以前は、ASVS には必須の MFA を要求していました。NIST は必須の MFA を要求しません。したがって、この章では ASVS が推奨するが管理策を要求しない場所を示すために、オプションの指定を使用しました。この標準では以下のキーが使用されます。
必須ではない
o
推奨、但し必須ではない
✓
必須
NIST 800-63 により「記憶された秘密」と呼ばれるパスワードには、パスワード、PIN、ロック解除パターン、正しい子猫や他の画像要素の選択、およびパスフレーズがあります。それらは一般に「あなたが知っているもの (something you know)」とみなされ、多くの場合に単一要素認証子として使用されます。インターネットで公開されている数十億の有効なユーザ名とパスワード、デフォルトパスワードや脆弱なパスワード、レインボーテーブルや最も一般的なパスワードの順序付き辞書など、単一要素認証の継続使用には大きな課題があります。
アプリケーションはユーザに多要素認証への登録を強く推奨し、ユーザが FIDO や U2F トークンなどすでに所有しているトークンを再利用できるようにするか、多要素認証を提供するクレデンシャルサービスプロバイダーにリンクします。
クレデンシャルサービスプロバイダ (Credential Service Provider, CSP) はユーザにフェデレーション ID (federated identity) を提供します。ユーザは一般的な選択肢として Azure AD, Okta, Ping Identity, Google を使用するエンタープライズ ID や、Facebook, Twitter, Google, WeChat を使用するコンシューマ ID など、複数の CSP で複数の ID を持つことがよくあります。このリストはこれらの企業やサービスを支持するものではなく、多くのユーザが多くの ID をすでに持っているという現実を、開発者が検討することを推奨するものです。組織はCSP の ID プルーフィングの強度のリスクプロファイルに従って、既存のユーザ ID との統合を検討すべきです。例えば、政府機関がソーシャルメディア ID を機密システムのログインとして受け入れることはまずありません。偽の ID を作成したり、ID を破棄することが簡単であるためです。一方、モバイルゲーム会社はアクティブなプレイヤーベースを拡大するために、主要なソーシャルメディアプラットフォームと統合する必要があると考えるかもしれません。
#
説明
L1
L2
L3
CWE
2.1.1
✓
✓
✓
521
5.1.1.2
2.1.2
✓
✓
✓
521
5.1.1.2
2.1.3
✓
✓
✓
521
5.1.1.2
2.1.4
スペースや絵文字などの言語ニュートラルな文字を含む、印字可能な Unicode 文字がパスワードで許可されている。
✓
✓
✓
521
5.1.1.2
2.1.5
ユーザがパスワードを変更できる。
✓
✓
✓
620
5.1.1.2
2.1.6
パスワード変更機能にはユーザの現在のパスワードと新しいパスワードが必要である。
✓
✓
✓
620
5.1.1.2
2.1.7
✓
✓
✓
521
5.1.1.2
2.1.8
ユーザがより強力なパスワードを設定できるように、パスワード強度メーターが提供されている。
✓
✓
✓
521
5.1.1.2
2.1.9
✓
✓
✓
521
5.1.1.2
2.1.10
定期的なクレデンシャル変更やパスワード履歴に関する要件がない。
✓
✓
✓
263
5.1.1.2
2.1.11
「貼り付け」機能、ブラウザパスワードヘルパー、および外部のパスワードマネージャが許可されている。
✓
✓
✓
521
5.1.1.2
2.1.12
ユーザがマスクされたパスワード全体を一時的に表示するか、ビルトイン機能としてこれを持たないプラットフォームでパスワードの最後に入力された文字を一時的に表示するかを選択できる。
✓
✓
✓
521
5.1.1.2
注意: ユーザーにパスワードの表示または最後の一文字の一時的な表示を許可する目的は、特に長いパスワード、パスフレーズ、およびパスワードマネージャの使用に関して、クレデンシャルエントリの使いやすさを向上させることです。この要件を含めるもう一つの理由は、この最新のユーザフレンドリなセキュリティエクスペリエンスを削除するために、組織がビルトインプラットフォームパスワードフィールドの動作をオーバーライドすることを不必要に要求するテストレポートを抑止または防止することです。
認証子の俊敏性は将来も使い続けるアプリケーションにとって不可欠です。アプリケーション検証器をリファクタリングして、ユーザの好みに応じて追加の認証子を許可し、非推奨の認証子や安全でない認証子を規則正しく廃止できるようにします。
#
説明
L1
L2
L3
CWE
2.2.1
耐自動化コントロールが流出済みクレデンシャルテスト攻撃、ブルートフォース攻撃、およびアカウントロックアウト攻撃の軽減に効果的である。このようなコントロールには最も一般的な流出パスワードのブロック、ソフトロックアウト、レート制限、CAPTCHA、試行間の遅延増加、IP アドレスの制限、または場所、デバイスへの最初のログイン、アカウントロック解除の最近の試行などのリスクベースの制限がある。一つのアカウントで一時間あたり 100 回以上の試行失敗が可能ではない。
✓
✓
✓
307
5.2.2 / 5.1.1.2 / 5.1.4.2 / 5.1.5.2
2.2.2
弱い認証子 (SMS や電子メールなど) の使用がよりセキュアな認証方式の代わりとしてではなく、二次検証とトランザクション承認に限定されている。より強い方式が弱い方式の前に提示されている、ユーザがリスクを承知している、またはアカウント侵害のリスクを制限するために適切な対策が講じられている。
✓
✓
✓
304
5.2.10
2.2.3
クレデンシャルのリセット、電子メールやアドレスの変更、不明な場所や危険な場所からのログインなどの認証詳細の更新後に、セキュアな通知がユーザに送信される。SMS や電子メールではなく、プッシュ通知の使用が推奨されるが、プッシュ通知がない場合、通知に機密情報が開示されていない限り SMS や電子メールは受け入れられる。
✓
✓
✓
620
2.2.4
多要素認証、目的別暗号化デバイス (プッシュして認証する接続キーなど) 、またはより高い AAL レベルのクライアント側証明書の使用など、フィッシングに対する偽装耐性がある。
✓
308
5.2.5
2.2.5
クレデンシャルサービスプロバイダ (Credential Service Providers, CSP) と認証を検証するアプリケーションが分離されている箇所で、相互認証された TLS が二つのエンドポイント間に配置されている。
✓
319
5.2.6
2.2.6
ワンタイムパスワード (One-time Password, OTP) デバイス、暗号化認証子、またはルックアップコードの使用を義務付けることにより、リプレイ耐性がある。
✓
308
5.2.8
2.2.7
OTP トークンの入力や、FIDO ハードウェアキーのボタンを押すなどのユーザ始動アクションを要求することにより、認証の意思を検証している。
✓
308
5.2.9
認証子にはパスワード、ソフトトークン、ハードウェアトークン、生体認証デバイスがあります。認証子のライフサイクルはアプリケーションのセキュリティにとって重要です。任意の人が同一性の証拠がないアカウントを自己登録できる場合、ID アサーションに対する信頼はほとんどありません。Reddit のようなソーシャルメディアサイトでは、それはまったく問題ありません。銀行システムでは、クレデンシャルとデバイスの登録と発行に重点を置くことが、アプリケーションのセキュリティにとって重要です。
注意: パスワードの最大有効期間をもつべきではありません。パスワードローテーションの原因となります。パスワードは定期的に入れ替えるのではなく、侵害されているかどうかを確認する必要があります。
#
説明
L1
L2
L3
CWE
2.3.1
システムで生成された初期パスワードやアクティベーションコードはセキュアでランダムに生成されており、6文字以上であり、文字と数字を含むことができ、短期間で有効期限が切れる。これらの初期の秘密は長期パスワードとなることを許可されてはいけない。
✓
✓
✓
330
5.1.1.2 / A.3
2.3.2
U2F や FIDO トークンなど、ユーザが提供する認証デバイスの登録と使用がサポートされている。
✓
✓
308
6.1.3
2.3.3
期限付き認証子を更新するために十分な更新時間で更新指示が送信されている。
✓
✓
287
6.1.4
アーキテクトおよび開発者はコードをビルドまたはリファクタリングする際にこのセクションを順守すべきです。このセクションはソースコードレビューを使用するか、セキュア単体テストまたはセキュア統合テストを通してのみ、完全に検証できます。ペネトレーションテストではこれらの問題を特定できません。
このセクションはペネトレーションテストができないため、管理策は L1 としてマークされていません。但し、このセクションはクレデンシャルが盗まれた場合にそのセキュリティにとって非常に重要であるため、アーキテクチャ、コーディングガイドライン、コードレビューチェックリストに対して ASVS をフォークする場合は、これらの管理策をあなたのプライベートバージョンでは L1 に戻してください。
#
説明
L1
L2
L3
CWE
2.4.1
✓
✓
916
5.1.1.2
2.4.2
✓
✓
916
5.1.1.2
2.4.3
✓
✓
916
5.1.1.2
2.4.4
✓
✓
916
5.1.1.2
2.4.5
秘密であり検証子のみが知っているソルト値を使用して、鍵生成関数の追加のイテレーションが実行される。承認された乱数ビット生成器 [SP 800-90Ar1] を使用してソルト値を生成し、少なくとも SP 800-131A の最新リビジョンで指定されている最小セキュリティ強度を提供する。秘密のソルト値はハッシュされたパスワードとは別に (例えば、ハードウェアセキュリティモジュールのような専用デバイスに) 保存すべきである。
✓
✓
916
5.1.1.2
米国標準が言及されている場合、必要に応じて米国標準の代わりに、またはそれに加えて、地域またはローカルの標準を使用できます。
#
説明
L1
L2
L3
CWE
2.5.1
✓
✓
✓
640
5.1.1.2
2.5.2
パスワードのヒントまたは知識ベースの認証 (いわゆる「秘密の質問」) が存在しない。
✓
✓
✓
640
5.1.1.2
2.5.3
✓
✓
✓
640
5.1.1.2
2.5.4
共有アカウントまたはデフォルトアカウントが存在しない (例 "root", "admin", "sa") 。
✓
✓
✓
16
5.1.1.2 / A.3
2.5.5
認証要素が変更または置換された場合、ユーザにこのイベントが通知される。
✓
✓
✓
304
6.1.2.3
2.5.6
✓
✓
✓
640
5.1.1.2
2.5.7
OTP または多要素認証要素が失われた場合、登録時と同じレベルで同一性証明の証拠が実行される。
✓
✓
308
6.1.2.3
ルックアップシークレットはトランザクション認証番号 (TAN) 、ソーシャルメディアリカバリーコードなどの、事前に生成されたシークレットコードのリスト、またはランダム値のセットを含むグリッドです。これらはユーザにセキュアに配布されます。これらのルックアップコードは一度使用され、すべて使用されると、ルックアップシークレットリストは破棄されます。このタイプの認証子は「あなたが持っているもの (something you have)」とみなされます。
#
説明
L1
L2
L3
CWE
2.6.1
ルックアップシークレットは一度のみ使用できる。
✓
✓
308
5.1.2.2
2.6.2
ルックアップシークレットに十分なランダム性 (112ビットのエントロピー) がある、または112ビット未満のエントロピーの場合、一意でランダムな32ビットソルトでソルトされ、承認された一方向ハッシュでハッシュされている。
✓
✓
330
5.1.2.2
2.6.3
ルックアップシークレットは予測可能な値などのオフライン攻撃に対して耐性がある。
✓
✓
310
5.1.2.2
過去において、一般的な帯域外検証子はパスワードリセットリンクを含む電子メールまたは SMS でした。攻撃者はこの脆弱なメカニズムを使用して、ある人物の電子メールアカウントを乗っ取り、発見されたリセットリンクを再利用するなど、まだ制御していないアカウントをリセットします。帯域外検証を処理するためのより良い方法があります。
セキュアな帯域外認証子はセキュアなセカンダリチャネルを介して検証子と通信できる物理デバイスです。例えばモバイルデバイスへのプッシュ通信がそうです。このタイプの認証子は「あなたが持っているもの (something you have)」とみなされます。ユーザが認証したいとき、検証アプリケーションは認証子への接続を介して直接もしくは間接的にサードパーティサービスを通じて帯域外認証子にメッセージを送信します。メッセージには認証コード (通常はランダムな六桁の番号またはモーダル承認ダイアログ) が含まれます。検証アプリケーションはプライマリチャネルを通じて認証コードを受信することを待ち、受信した値のハッシュを元の認証コードのハッシュと比較します。それらが一致する場合、帯域外検証子はユーザが認証されたと想定できます。
ASVS はプッシュ通知などの新たな帯域外認証子を開発する開発者はごく少数であると想定しているため、認証 API 、アプリケーション、シングルサインオン実装などの検証子に次の ASVS 管理策が適用されます。新しい帯域外認証子を開発する場合には、NIST 800-63B § 5.1.3.1 を参照してください。
電子メールや VOIP などの安全でない帯域外認証子は許可されていません。PSTN および SMS 認証は現在 NIST により「制限」され、廃止対象であり、プッシュ通知などを推奨しています。電話または SMS の帯域外認証を使用する必要がある場合には、§ 5.1.3.3 を参照してください。
#
説明
L1
L2
L3
CWE
2.7.1
SMS や PSTN などのクリアテキスト帯域外 (NIST "制限(restricted)") 認証子がデフォルトで提供されておらず、プッシュ通知などの強力な代替が最初に提供されている。
✓
✓
✓
287
5.1.3.2
2.7.2
帯域外検証子は10分後に帯域外認証リクエスト、コード、またはトークンが期限切れになる。
✓
✓
✓
287
5.1.3.2
2.7.3
帯域外検証子の認証リクエスト、コード、またはトークンは元の認証リクエストに対してのみ一度だけ使用できる。
✓
✓
✓
287
5.1.3.2
2.7.4
帯域外認証子と検証子はセキュアで独立したチャネルを介して通信する。
✓
✓
✓
523
5.1.3.2
2.7.5
帯域外検証子は認証コードのハッシュバージョンのみを保持している。
✓
✓
256
5.1.3.2
2.7.6
初期認証コードは少なくとも20ビットのエントロピー (通常、6デジタル乱数で十分です) を持ち、セキュアな乱数生成器により生成されている。
✓
✓
310
5.1.3.2
単一要素ワンタイムパスワード (One-time Password, OTP) は継続的に変化する疑似ランダムワンタイムチャレンジを表示する物理トークンまたはソフトトークンです。これらのデバイスはフィッシング (なりすまし) を困難にしますが、不可能ではありません。このタイプの認証子は「あなたが持っているもの (something you have)」とみなされます。多要素トークンは単一要素 OTP と似ていますが、有効な PIN コード、生体認証ロック解除、USB 挿入または NFC ペアリングまたは追加の値 (トランザクション署名計算機など) を入力して最終 OTP を作成する必要があります。
#
説明
L1
L2
L3
CWE
2.8.1
時間ベースの OTP は期限切れまでの有効期間が定義されている。
✓
✓
✓
613
5.1.4.2 / 5.1.5.2
2.8.2
送信された OTP を検証するために使用される対称鍵は、ハードウェアセキュリティモジュールまたはセキュアなオペレーティングシステムベースのキーストレージなどを使用して、高度に保護されている。
✓
✓
320
5.1.4.2 / 5.1.5.2
2.8.3
承認された暗号化アルゴリズムが OTP の生成、シード、および検証に使用されている。
✓
✓
326
5.1.4.2 / 5.1.5.2
2.8.4
時間ベースの OTP は有効期間内に一度しか使用できない。
✓
✓
287
5.1.4.2 / 5.1.5.2
2.8.5
時間ベースの多要素 OTP が有効期間内に再使用される場合、デバイスの所有者に送信されるセキュアな通知でログに記録され、リジェクトされる。
✓
✓
287
5.1.5.2
2.8.6
物理的な単一要素 OTP 生成器は盗難またはその他の紛失の場合に無効にできる。場所に関係なく、ログインしたセッション全体で無効化がすぐに反映される。
✓
✓
613
5.2.1
2.8.7
生体認証子はあなたが持っているものかあなたが知っているもののいずれかと組み合わせて、二次的要素としてのみ使用するように制限されている。
o
✓
308
5.2.3
暗号化セキュリティキーはスマートカードまたは FIDO キーであり、ユーザは認証を完了するために暗号化デバイスをコンピュータに接続するかペアリングする必要があります。検証子はチャレンジナンスを暗号化デバイスまたはソフトウェアに送信し、デバイスまたはソフトウェアはセキュアに保存された暗号化鍵に基づいてレスポンスを計算します。
単一要素暗号化デバイスとソフトウェア、および多要素暗号化デバイスとソフトウェアの要件は同じです。これは暗号化認証子の検証が認証要素の所有を証明するためです。
#
説明
L1
L2
L3
CWE
2.9.1
検証に使用される暗号化鍵は、トラステッドプラットフォームモジュール (Trusted Platform Module, TPM) やハードウェアセキュリティモジュール (Hardware Security Module, HSM) またはこのセキュアなストレージを使用できる OS サービスを使用するなど、セキュアに保存され、開示から保護されている。
✓
✓
320
5.1.7.2
2.9.2
チャレンジナンスは少なくとも64ビットの長さがあり、統計的に一意であるか、暗号化デバイスの寿命において一意である。
✓
✓
330
5.1.7.2
2.9.3
承認された暗号化アルゴリズムが生成、シード、および検証に使用されている。
✓
✓
327
5.1.7.2
このセクションはペネトレーションテスト可能ではないため、L1 要件はありません。但し、アーキテクチャ、コーディングまたはセキュアコードレビューで使用する場合、ソフトウェアは (Java Key Store と同様に) L1 の最小要件であると想定してください。どのような状況でも秘密のクリアテキストストレージは受け入れられません。
#
説明
L1
L2
L3
CWE
2.10.1
サービス内シークレットはパスワード、API キーや特権アクセスを持つ共有アカウントなど不変のクレデンシャルに依存していない。
OS アシスト
HSM
287
5.1.1.1
2.10.2
サービス認証にパスワードが必要である場合、使用されるサービスアカウントがデフォルトクレデンシャルではない。 (例えば、あるサービスではインストール時に root/root または admin/admin がデフォルトである)
OS アシスト
HSM
255
5.1.1.1
2.10.3
ローカルシステムアクセスを含むオフラインリカバリー攻撃を防ぐために、パスワードは十分な保護で保存されている。
OS アシスト
HSM
522
5.1.1.1
2.10.4
パスワード、データベースおよびサードパーティシステムとの統合、シードおよび内部シークレット、および API キー がセキュアに管理され、ソースコードに含まれていない、またはソースコードリポジトリに保存されていない。このようなストレージはオフライン攻撃に耐える必要がある。パスワードストレージにはセキュアなソフトウェアキーストア (L1) 、ハードウェア TPM 、または HSM (L3) の使用を推奨する。
OS アシスト
HSM
798
米国政府機関には NIST 800-63 に関する必須要件があります。アプリケーションセキュリティ検証標準は常に、アプリのほぼ100%に適用される管理策の約80%であり、高度な管理策や適用が制限される管理策の残りの20%ではありません。そのため、ASVS は特に IAL1/2 および AAL1/2 分類では NIST 800-63 の厳密なサブセットですが、特に IAL3/AAL3 分類に関しては十分に包括的ではありません。
米国政府機関には NIST 800-63 全体をレビューし実装することを強くお勧めします。
CSP
クレデンシャルサービスプロバイダ (Credential Service Provider) は ID プロバイダ (Identity Provider) とも呼ばれます。
認証子 (Authenticator)
パスワード、トークン、MFA、フェデレーションアサーションなどを認証するコード。
検証子 (Verifier)
「認証プロトコルを使用して一つまたは二つの認証子の主張者の所有と制御を検証することにより、主張者の身元を検証するエンティティ。これを行うために、検証子は認証子をサブスクライバの識別子にリンクしそのステータスを確認するクレデンシャルを妥当性確認する必要もある可能性があります。」
OTP
ワンタイムパスワード (One-time password)
SFA
単一要素認証子 (Single-factor authenticators) 。あなたが知っているもの (記憶された秘密、パスワード、パスフレーズ、PIN) 、あなたであるもの (生体情報、指紋、顔スキャン) 、またはあなたが持っているもの (OTP トークン、スマートカードなどの暗号化デバイス) など。
MFA
多要素認証 (Multi-factor authentication)。二つ以上の単一要素を含む。
詳しくは以下の情報を参照してください。
ユーザが設定するパスワードの長さは (複数の空白が結合された後) 少なくとも 12 文字である。 ()
64 文字以上のパスワードが許可されている、および 128 文字を超えるパスワードが拒否されている。 ()
パスワードの切り捨てが行われていない。ただし、連続する複数のスペースは単一のスペースに置き換えることができる。 ()
アカウント登録、ログインおよびパスワード変更時に送信されるパスワードがローカル (システムのパスワードポリシーに一致する上位 1,000 または 10,000 の最も一般的なパスワードなど) または外部 API を使用した一連の流出済みパスワードと照合している。API を使用する場合には、パスワードの流出状況の検証に平文パスワードが送信または使用されないように、ゼロ知識証明またはその他のメカニズムを使用する必要がある。パスワードが流出している場合、アプリケーションはユーザに新しい未流出パスワードの設定を要求しなければならない。 ()
許可される文字の種類を制限するパスワード構成規則がない。大文字、小文字、数字、または特殊文字を要求すべきではありません。 ()
NIST は電子メールや SMS を と考えており、将来のある時点で NIST 800-63 および ASVS から削除される可能性があります。アプリケーションは電子メールや SMS の使用を必要としないロードマップを計画すべきです。
承認された一方向鍵生成関数のリストは NIST 800-63 B section 5.1.1.2 および で詳しく説明されています。これらの選択の代わりに、最新の国内または地域のアルゴリズムおよび鍵長標準を選択できます。
パスワードがオフライン攻撃に耐える形式で保存されている。パスワードは承認された一方向鍵生成またはパスワードハッシュ関数を使用してソルトおよびハッシュされているべきである。鍵生成およびパスワードハッシュ関数はパスワードハッシュを生成するときに入力としてパスワード、ソルト、およびコストファクターを受け取る。 ()
ソルトは少なくとも32ビットの長さがあり、格納されたハッシュ間のソルト値の衝突を最小限にするために任意に選択されている。クレデンシャルごとに、一意のソルト値と結果のハッシュが保存されているべきである。 ()
PBKDF2 が使用されている場合、イテレーションカウントは検証サーバのパフォーマンスが許す限り大きくすべきであり、通常は少なくとも 100,000 イテレーションである。 ()
bcrypt が使用されている場合、ワークファクターは検証サーバのパフォーマンスが許す限り大きくすべきであり、通常は少なくとも 10 である。 ()
システムが生成した初期アクティベーションまたはリカバリーシークレットがクリアテキストでユーザーに送信されていない ()
パスワードクレデンシャルリカバリーは決して現在のパスワードを明らかにしない。 ()
パスワードを忘れた場合、他のリカバリーパスはタイムベースのワンタイムパスワード (time-based OTP, TOTP) またはその他のソフトトークン、モバイルパス、または別のオフラインリカバリーメカニズムなどのセキュアなリカバリーメカニズムを使用する。 ()