トップ   新規 一覧 検索 最終更新   ヘルプ   最終更新のRSS

V2 認証検証の要件 のバックアップ(No.5)

OWASP ASVS 4.0

管理目標 †

認証とは誰か (あるいは何か) を真正であるとして確立または確認する行為であり、個人またはデバイスに関する申し出は正しく、なりすましに耐性があり、パスワードの回復や傍受を防ぐことです。
ASVS が最初にリリースされたとき、ユーザー名 + パスワードは高度なセキュリティシステム以外で最も一般的な認証形式でした。多要素認証 (MFA) はセキュリティサークルで一般的に受け入れられていますが、他ではほとんど必要とされていません。パスワード侵害の数が増加するにつれ、ユーザー名は何かしらの形で機密情報であり、パスワードは不明であるという考えでは、多くのセキュリティコントロールは維持できなくなりました。例えば、NIST 800-63 はユーザー名とナレッジベース認証 (KBA) を公開情報、SMS および電子メール通知を "restricted" authenticator types 、パスワードを pre-breached としています。この本質は、知識ベースの認証符号、SMS および電子メールでのリカバリー、パスワード履歴、複雑さ、ローテーションコントロールを無用とします。これらのコントロールはまったく役に立たず、ユーザーは数か月ごとに脆弱なパスワードを考えてきました。しかし、50億を超えるユーザー名とパスワード侵害のリリースにより、先に進む時がきました。
ASVS のすべての章の中で、認証とセッション管理の章が最も変更されています。効果的で、エビデンスベースのリーディングプラクティスの採用は多くの人にとって挑戦となるでしょうが、それはまったく問題ありません。今ここでポストパスワードの将来への移行を開始する必要があります。

↑

NIST 800-63 - 最新のエビデンスベースの認証標準 †

NIST 800-63b は最新のエビデンスベースの標準であり、適用可能性とは関係なく、利用可能な最適なアドバイスを表しています。この標準は世界中のすべての組織に役立ちますが、特に米国の代理店および米国の代理店を扱う組織に関連します。
NIST 800-63 の用語は、特にユーザー名 + パスワードの認証にしか慣れていない場合には、最初は少しわかりにくいかもしれません。最新の認証に進歩する必要があるため、将来一般的になるであろう用語を導入する必要がありますが、業界がこれらの新しい用語に落ち着くまで理解の難しさを理解しています。この章の最後に支援のための用語集があります。要件の表記ではなく、要件の意図を満たすために多くの要件を言い換えました。例えば、NIST が「記憶された秘密 (memorized secret)」を使用する場合、ASVS では「パスワード」という用語を使用します。
ASVS V2 認証、V3 セッション管理、および範囲は狭いですが、V4 アクセス制御は選択された NIST 800-63b コントロールの準拠サブセットに適応し、一般的な脅威と一般的に悪用される認証の脆弱性に焦点を当てています。NIST 800-63 に完全に準拠する必要がある場合には、NIST 800-63 を確認してください。

↑

適切な NIST AAL レベルの選択 †

アプリケーションセキュリティ検証標準は ASVS L1 を NIST AAL1 要件に、L2 を AAL2 に、L3 を AAL3 にマップしようとしました。しかし、「必須」コントロールとしての ASVS レベル 1 のアプローチはアプリケーションや API を検証するための正しい AAL レベルであるとは限りません。例えば、アプリケーションがレベル 3 アプリケーションである場合や AAL3 とする規制要件がある場合には、セクション V2 および V3 セッション管理でレベル 3 を選択すべきです。NIST 準拠の認証アサーションレベル (AAL) の選択は NIST-63b ガイドラインに従って実行すべきです。NIST 800-63b Section 6.2 の Selecting AAL に記載されています。

↑

凡例 †

特に最新の認証がアプリケーションのロードマップ上にある場合には、アプリケーションは常に現在のレベルの要件を超える可能性があります。以前は、ASVS には必須の MFA を要求していました。NIST は必須の MFA を要求しません。したがって、この章では ASVS が推奨するがコントロールを要求しない場所を示すために、オプションの指定を使用しました。この標準では以下のキーが使用されます。

記号説明
必須ではない
o推奨、但し必須ではない
✓必須


↑

V2.1 パスワードセキュリティ要件 †

NIST 800-63 により「記憶された秘密」と呼ばれるパスワードには、パスワード、PIN、ロック解除パターン、正しい子猫や他の画像要素の選択、およびパスフレーズがあります。それらは一般に「あなたが知っているもの (something you know)」とみなされ、多くの場合に単一要素認証子として使用されます。インターネットで公開されている数十億の有効なユーザー名とパスワード、デフォルトパスワードや脆弱なパスワード、レインボーテーブルや最も一般的なパスワードの順序付き辞書など、単一要素認証の継続使用には大きな課題があります。
アプリケーションはユーザーに多要素認証への登録を強く推奨し、ユーザーが FIDO や U2F トークンなどすでに所有しているトークンを再利用できるようにするか、多要素認証を提供する資格情報サービスプロバイダーにリンクします。
資格情報サービスプロバイダ (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 を破棄することが簡単であるためです。一方、モバイルゲーム会社はアクティブなプレイヤーベースを拡大するために、主要なソーシャルメディアプラットフォームと統合する必要があると考えるかもしれません。

項番説明L1L2L3NoタイトルNISTSTIGsIPAガイドライン


#説明L1L2L3CWENIST
2.1.1ユーザーが設定するパスワードの長さは (複数の空白が結合された後) 少なくとも 12 文字であることを検証します。[6]✓✓✓5215.1.1.2
2.1.264 文字以上 (ただし 128 文字以下) のパスワードが許可されていることを検証します。[6]✓✓✓5215.1.1.2
2.1.3パスワードの切り捨てが行われていないことを検証します。ただし、連続する複数のスペースは単一のスペースに置き換えることができます。[6]✓✓✓5215.1.1.2
2.1.4スペースや絵文字などの言語ニュートラルな文字を含む、印字可能な Unicode 文字がパスワードで許可されていることを検証します。✓✓✓5215.1.1.2
2.1.5ユーザーがパスワードを変更できることを検証します。✓✓✓6205.1.1.2
2.1.6パスワード変更機能にはユーザーの現在のパスワードと新しいパスワードが必要であることを検証します。✓✓✓6205.1.1.2
2.1.7アカウント登録、ログイン、パスワード変更時に送信されるパスワードがローカル (システムのパスワードポリシーに一致する上位 1,000 または 10,000 の最も一般的なパスワードなど) または外部 API を使用した一連の流出済みパスワードと照合することを検証します。API を使用する場合には、パスワードの流出状況の検証に平文パスワードが送信または使用されないように、ゼロ知識証明またはその他のメカニズムを使用する必要があります。パスワードが流出している場合、アプリケーションはユーザーに新しい未流出パスワードの設定を要求しなければなりません。[6]✓✓✓5215.1.1.2
2.1.8ユーザーがより強力なパスワードを設定できるように、パスワード強度メーターが提供されていることを検証します。✓✓✓5215.1.1.2
2.1.9許可される文字の種類を制限するパスワード構成規則がないことを検証します。大文字、小文字、数字、または特殊文字を要求すべきではありません。[6]✓✓✓5215.1.1.2
2.1.10定期的な資格情報のローテーションやパスワード履歴の要件がないことを検証します。✓✓✓2635.1.1.2
2.1.11「貼り付け」機能、ブラウザパスワードヘルパー、および外部のパスワードマネージャが許可されていることを検証します。✓✓✓5215.1.1.2
2.1.12ユーザーがマスクされたパスワード全体を一時的に表示するか、ビルトイン機能としてこれを持たないプラットフォームでパスワードの最後に入力された文字を一時的に表示するかを選択できることを検証します。✓✓✓5215.1.1.2

注意: ユーザーにパスワードの表示または最後の一文字の一時的な表示を許可する目的は、特に長いパスワード、パスフレーズ、およびパスワードマネージャの使用に関して、資格情報エントリの使いやすさを向上させることです。この要件を含めるもう一つの理由は、この最新のユーザーフレンドリなセキュリティエクスペリエンスを削除するために、組織がビルトインプラットフォームパスワードフィールドの動作をオーバーライドすることを不必要に要求するテストレポートを抑止または防止することです。

↑

V2.2 一般的な認証子要件 †

認証子の俊敏性は将来も使い続けるアプリケーションにとって不可欠です。アプリケーション検証器をリファクタリングして、ユーザーの好みに応じて追加の認証子を許可し、非推奨の認証子や安全でない認証子を規則正しく廃止できるようにします。
NIST は電子メールや SMS を [「制限された」認証子タイプ ("restricted" authenticator types)](https://pages.nist.gov/800-63-FAQ/#q-b1) と考えており、将来のある時点で NIST 800-63 および ASVS から削除される可能性があります。アプリケーションは電子メールや SMS の使用を必要としないロードマップを計画すべきです。

#説明L1L2L3CWENIST
2.2.1耐自動化コントロールが流出済み資格情報テスト攻撃、ブルートフォース攻撃、およびアカウントロックアウト攻撃の軽減に効果的であることを検証します。このようなコントロールには最も一般的な流出パスワードのブロック、ソフトロックアウト、レート制限、CAPTCHA、試行間の遅延増加、IP アドレスの制限、または場所、デバイスへの最初のログイン、アカウントロック解除の最近の試行などのリスクベースの制限があります。一つのアカウントで一時間あたり 100 回以上の試行失敗が可能ではないことを検証します。✓✓✓3075.2.2 / 5.1.1.2 / 5.1.4.2 / 5.1.5.2
2.2.2弱い認証子 (SMS や電子メールなど) の使用がよりセキュアな認証方式の代わりとしてではなく、二次検証とトランザクション承認に限定されていることを検証します。より強い方式が弱い方式の前に提示されていること、ユーザーがリスクを承知していること、またはアカウント侵害のリスクを制限するために適切な対策が講じられていることを検証します。✓✓✓3045.2.10
2.2.3資格情報のリセット、電子メールやアドレスの変更、不明な場所や危険な場所からのログインなどの認証詳細の更新後に、セキュアな通知がユーザーに送信されることを検証します。SMS や電子メールではなく、プッシュ通知の使用が推奨されますが、プッシュ通知がない場合、通知に機密情報が開示されていない限り SMS や電子メールは受け入れられます。✓✓✓620
2.2.4多要素認証、目的別暗号化デバイス (プッシュして認証する接続キーなど) 、またはより高い AAL レベルのクライアント側証明書の使用など、フィッシングに対する偽装耐性を検証します。✓3085.2.5
2.2.5資格情報サービスプロバイダ (CSP) と認証を検証するアプリケーションが分離されている箇所で、相互認証された TLS が二つのエンドポイント間に配置されていることを検証します。✓3195.2.6
2.2.6OTP デバイス、暗号化認証子、またはルックアップコードの使用を義務付けることにより、リプレイ耐性を検証します。✓3085.2.8
2.2.7OTP トークンの入力や、FIDO ハードウェアキーのボタンを押すなどのユーザー始動アクションを要求することにより、認証の意思を検証します。✓3085.2.9
↑

V2.3 認証子ライフサイクル要件 †

認証子にはパスワード、ソフトトークン、ハードウェアトークン、生体認証デバイスがあります。認証子のライフサイクルはアプリケーションのセキュリティにとって重要です。任意の人が同一性の証拠がないアカウントを自己登録できる場合、ID アサーションに対する信頼はほとんどありません。Reddit のようなソーシャルメディアサイトでは、それはまったく問題ありません。銀行システムでは、資格情報とデバイスの登録と発行に重点を置くことが、アプリケーションのセキュリティにとって重要です。
注意: パスワードの最大有効期間をもつべきではありません。パスワードローテーションの原因となります。パスワードは定期的に入れ替えるのではなく、侵害されているかどうかを確認する必要があります。

#説明L1L2L3CWENIST
2.3.1システムで生成された初期パスワードやアクティベーションコードはセキュアでランダムに生成されており、6文字以上であり、文字と数字を含むことができ、短期間で有効期限が切れることを検証します。これらの初期の秘密は長期パスワードとなることを許可されてはいけません。✓✓✓3305.1.1.2 / A.3
2.3.2U2F や FIDO トークンなど、加入者が提供する認証デバイスの登録と使用がサポートされていることを検証します。✓✓3086.1.3
2.3.3期限付き認証子を更新するために十分な更新時間で更新指示が送信されていることを検証します。✓✓2876.1.4
↑

V2.4 資格情報ストレージ要件 †

アーキテクトおよび開発者はコードをビルドまたはリファクタリングする際にこのセクションを順守すべきです。このセクションはソースコードレビューを使用するか、セキュア単体テストまたはセキュア統合テストを通してのみ、完全に検証できます。ペネトレーションテストではこれらの問題を特定できません。
承認された一方向鍵生成関数のリストは NIST 800-63 B section 5.1.1.2 および [BSI Kryptographische Verfahren: Empfehlungen und Schlussellängen (2018)](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102.pdf?__blob=publicationFile) で詳しく説明されています。これらの選択の代わりに、最新の国内または地域のアルゴリズムおよび鍵長標準を選択できます。
このセクションはペネトレーションテストができないため、コントロールは L1 としてマークされていません。但し、このセクションは資格情報が盗まれた場合にそのセキュリティにとって非常に重要であるため、アーキテクチャ、コーディングガイドライン、コードレビューチェックリストに対して ASVS をフォークする場合は、これらのコントロールをあなたのプライベートバージョンでは L1 に戻してください。

#説明L1L2L3CWENIST
2.4.1パスワードがオフライン攻撃に耐える形式で保存されていることを検証します。パスワードは承認された一方向鍵生成またはパスワードハッシュ関数を使用してソルトおよびハッシュされているべきです。鍵生成およびパスワードハッシュ関数はパスワードハッシュを生成するときに入力としてパスワード、ソルト、およびコストファクターを受け取ります。[6]✓✓9165.1.1.2
2.4.2ソルトは少なくとも32ビットの長さがあり、格納されたハッシュ間のソルト値の衝突を最小限にするために任意に選択されていることを検証します。資格情報ごとに、一意のソルト値と結果のハッシュが保存されているべきです。[6]✓✓9165.1.1.2
2.4.3PBKDF2 が使用されている場合、イテレーションカウントは検証サーバーのパフォーマンスが許す限り大きくすべきであり、通常は少なくとも 100,000 イテレーションであることを検証します。[6]✓✓9165.1.1.2
2.4.4bcrypt が使用されている場合、ワークファクターは検証サーバーのパフォーマンスが許す限り大きくすべきであり、通常は少なくとも 13 であることを検証します。[6]✓✓9165.1.1.2
2.4.5秘密であり検証者のみが知っているソルト値を使用して、鍵生成関数の追加のイテレーションが実行されることを検証します。承認された乱数ビット生成器 [SP 800-90Ar1] を使用してソルト値を生成し、少なくとも SP 800-131A の最新リビジョンで指定されている最小セキュリティ強度を提供します。秘密のソルト値はハッシュされたパスワードとは別に (例えば、ハードウェアセキュリティモジュールのような専用デバイスに) 保存すべきです。✓✓9165.1.1.2


米国標準が言及されている場合、必要に応じて米国標準の代わりに、またはそれに加えて、地域またはローカルの標準を使用できます。

↑

V2.5 資格情報の回復要件 †

#説明L1L2L3CWENIST
2.5.1システムが生成した初期アクティベーションまたはリカバリーシークレットがユーザーに送信されている場合、それはシングルユースであり、時間制限があり、ランダムであることを検証します。[6]✓✓✓6405.1.1.2
2.5.2パスワードのヒントまたは知識ベースの認証 (いわゆる「秘密の質問」) が存在しないことを検証します。✓✓✓6405.1.1.2
2.5.3パスワード資格情報リカバリーは決して現在のパスワードを明らかにしないことを検証します。[6]✓✓✓6405.1.1.2
2.5.4共有アカウントまたはデフォルトアカウントが存在しないことを検証します (例 "root", "admin", "sa") 。✓✓✓165.1.1.2 / A.3
2.5.5認証要素が変更または置換された場合、ユーザーにこのイベントが通知されることを検証します。✓✓✓3046.1.2.3
2.5.6パスワードを忘れた場合、他のリカバリーパスは TOTP またはその他のソフトトークン、モバイルパス、または別のオフラインリカバリーメカニズムなどのセキュアなリカバリーメカニズムを使用することを検証します。[6]✓✓✓6405.1.1.2
2.5.7OTP または多要素認証要素が失われた場合、登録時と同じレベルで同一性証明の証拠が実行されることを検証します。✓✓3086.1.2.3
↑

V2.6 Look-up Secret Verifier 要件 †

ルックアップシークレットはトランザクション認証番号 (TAN) 、ソーシャルメディアリカバリーコードなどの、事前に生成されたシークレットコードのリスト、またはランダム値のセットを含むグリッドです。これらはユーザーにセキュアに配布されます。これらのルックアップコードは一度使用され、すべて使用されると、ルックアップシークレットリストは破棄されます。このタイプの認証子は「あなたが持っているもの (something you have)」とみなされます。

#説明L1L2L3CWENIST
2.6.1ルックアップシークレットは一度のみ使用できることを検証します。✓✓3085.1.2.2
2.6.2ルックアップシークレットに十分なランダム性 (112ビットのエントロピー) があること、または112ビット未満のエントロピーの場合、一意でランダムな32ビットソルトでソルトされ、承認された一方向ハッシュでハッシュされていることを検証します。✓✓3305.1.2.2
2.6.3ルックアップシークレットは予測可能な値などのオフライン攻撃に対して耐性があることを検証します。✓✓3105.1.2.2
↑

V2.7 Out of Band Verifier 要件 †

過去において、一般的な帯域外検証子はパスワードリセットリンクを含む電子メールまたは SMS でした。攻撃者はこの脆弱なメカニズムを使用して、ある人物の電子メールアカウントを乗っ取り、発見されたリセットリンクを再利用するなど、まだ制御していないアカウントをリセットします。帯域外検証を処理するためのより良い方法があります。
セキュアな帯域外認証子はセキュアなセカンダリチャネルを介して検証子と通信できる物理デバイスです。例えばモバイルデバイスへのプッシュ通信がそうです。このタイプの認証子は「あなたが持っているもの (something you have)」とみなされます。ユーザーが認証したいとき、検証アプリケーションは認証子への接続を介して直接もしくは間接的にサードパーティサービスを通じて帯域外認証子にメッセージを送信します。メッセージには認証コード (通常はランダムな六桁の番号またはモーダル承認ダイアログ) が含まれます。検証アプリケーションはプライマリチャネルを通じて認証コードを受信することを待ち、受信した値のハッシュを元の認証コードのハッシュと比較します。それらが一致する場合、帯域外検証子はユーザーが認証されたと想定できます。
ASVS はプッシュ通知などの新たな帯域外認証子を開発する開発者はごく少数であると想定しているため、認証 API 、アプリケーション、シングルサインオン実装などの検証子に次の ASVS コントロールが適用されます。新しい帯域外認証子を開発する場合には、NIST 800-63B § 5.1.3.1 を参照してください。
電子メールや VOIP などの安全でない帯域外認証子は許可されていません。PSTN および SMS 認証は現在 NIST により「制限」され、廃止対象であり、プッシュ通知などを推奨しています。電話または SMS の帯域外認証を使用する必要がある場合には、§ 5.1.3.3 を参照してください。

#説明L1L2L3CWENIST
2.7.1SMS や PSTN などのクリアテキスト帯域外 (NIST "制限(restricted)") 認証子がデフォルトで提供されておらず、プッシュ通知などの強力な代替が最初に提供されていることを検証します。✓✓✓2875.1.3.2
2.7.2帯域外検証子は10分後に帯域外認証リクエスト、コード、またはトークンが期限切れになることを検証します。✓✓✓2875.1.3.2
2.7.3帯域外検証子の認証リクエスト、コード、またはトークンは元の認証リクエストに対してのみ一度だけ使用できることを検証します。✓✓✓2875.1.3.2
2.7.4帯域外認証子と検証子はセキュアで独立したチャネルを介して通信することを検証します。✓✓✓5235.1.3.2
2.7.5帯域外検証子は認証コードのハッシュバージョンのみを保持していることを検証します。✓✓2565.1.3.2
2.7.6初期認証コードは少なくとも20ビットのエントロピー (通常、6デジタル乱数で十分です) を持ち、セキュアな乱数生成器により生成されていることを検証します。✓✓3105.1.3.2
↑

V2.8 シングルまたはマルチファクターのワンタイム検証子要件 †

単一要素ワンタイムパスワード (OTP) は継続的に変化する疑似ランダムワンタイムチャレンジを表示する物理トークンまたはソフトトークンです。これらのデバイスはフィッシング (なりすまし) を困難にしますが、不可能ではありません。このタイプの認証子は「あなたが持っているもの (something you have)」とみなされます。多要素トークンは単一要素 OTP と似ていますが、有効な PIN コード、生体認証ロック解除、USB 挿入または NFC ペアリングまたは追加の値 (トランザクション署名計算機など) を入力して最終 OTP を作成する必要があります。

説明L1L2L3CWENIST
2.8.1時間ベースの OTP は期限切れまでの有効期間が定義されていることを検証します。✓✓✓6135.1.4.2 / 5.1.5.2
2.8.2送信された OTP を検証するために使用される対称鍵は、ハードウェアセキュリティモジュールまたはセキュアなオペレーティングシステムベースのキーストレージなどを使用して、高度に保護されていることを検証します。✓✓3205.1.4.2 / 5.1.5.2
2.8.3承認された暗号化アルゴリズムが OTP の生成、シード、および検証に使用されていることを検証します。✓✓3265.1.4.2 / 5.1.5.2
2.8.4時間ベースの OTP は有効期間内に一度しか使用できないことを検証します。✓✓2875.1.4.2 / 5.1.5.2
2.8.5時間ベースの多要素 OTP が有効期間内に再使用される場合、デバイスの所有者に送信されるセキュアな通知でログに記録され、リジェクトされることを検証します。✓✓2875.1.5.2
2.8.6物理的な単一要素 OTP 生成器は盗難またはその他の紛失の場合に無効にできることを検証します。場所に関係なく、ログインしたセッション全体で無効化がすぐに反映されるようにします。✓✓6135.2.1
2.8.7生体認証子はあなたが持っているものかあなたが知っているもののいずれかと組み合わせて、二次的要素としてのみ使用するように制限されていることを検証します。o✓3085.2.3
↑

V2.9 暗号化ソフトウェアおよびデバイス検証子要件 †

暗号化セキュリティキーはスマートカードまたは FIDO キーであり、ユーザーは認証を完了するために暗号化デバイスをコンピュータに接続するかペアリングする必要があります。検証子はチャレンジナンスを暗号化デバイスまたはソフトウェアに送信し、デバイスまたはソフトウェアはセキュアに保存された暗号化鍵に基づいてレスポンスを計算します。
単一要素暗号化デバイスとソフトウェア、および多要素暗号化デバイスとソフトウェアの要件は同じです。これは暗号化認証子の検証が認証要素の所有を証明するためです。

#説明L1L2L3CWENIST
2.9.1検証に使用される暗号化鍵は、TPM や HSM またはこのセキュアなストレージを使用できる OS サービスを使用するなど、セキュアに保存され、開示から保護されていることを検証します。✓✓3205.1.7.2
2.9.2チャレンジナンスは少なくとも64ビットの長さがあり、統計的に一意であるか、暗号化デバイスの寿命において一意であることを検証します。✓3305.1.7.2
2.9.3承認された暗号化アルゴリズムが生成、シード、および検証に使用されていることを検証します。✓✓3275.1.7.2
↑

V2.10 サービス認証要件 †

このセクションはペネトレーションテスト可能ではないため、L1 要件はありません。但し、アーキテクチャ、コーディングまたはセキュアコードレビューで使用する場合、ソフトウェアは (Java Key Store と同様に) L1 の最小要件であると想定してください。どのような状況でも秘密のクリアテキストストレージは受け入れられません。

説明L1L2L3CWENIST
2.10.1サービス内シークレットはパスワード、API キーや特権アクセスを持つ共有アカウントなど不変の資格情報に依存していないことを検証します。OS アシストHSM2875.1.1.1
2.10.2パスワードが必要である場合、資格情報がデフォルトアカウントではないことを検証します。OS アシストHSM2555.1.1.1
2.10.3ローカルシステムアクセスを含むオフラインリカバリー攻撃を防ぐために、パスワードは十分な保護で保存されていることを検証します。OS アシストHSM5225.1.1.1
2.10.4パスワード、データベースおよびサードパーティシステムとの統合、シードおよび内部シークレット、および API キー がセキュアに管理され、ソースコードに含まれていないこと、またはソースコードリポジトリに保存されていないことを検証します。このようなストレージはオフライン攻撃に耐える必要があります。パスワードストレージにはセキュアなソフトウェアキーストア (L1) 、ハードウェアトラステッドプラットフォームモジュール (TPM) 、またはハードウェアセキュリティモジュール (L3) の使用を推奨します。OS アシストHSM798
↑

追加の米国政府機関要件 †

米国政府機関には 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)。二つ以上の単一要素を含む。
↑

参考情報 †

詳細については、以下も参照してください。