Skip to content

Latest commit

 

History

History
234 lines (168 loc) · 31.2 KB

0x11-V2-Authentication.md

File metadata and controls

234 lines (168 loc) · 31.2 KB

V2 認証

管理目標

認証とは個人またはデバイスの信頼性を確立または確認するプロセスです。これには個人またはデバイスに関する主張を検証し、なりすましへの耐性を確保し、パスワードのリカバリや傍受を防止することが含まれます。

効果的で、エビデンスベースのリーディングプラクティスの採用は多くの人にとって挑戦となるでしょうが、それはまったくいいことです。今ここでポストパスワードの未来へ、移行を始める必要があります。

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

NIST SP 800-63B は最新のエビデンスベースの標準であり、適用可能性とは関係なく、利用可能な最適なアドバイスを表しています。この標準は世界中のすべての組織に役立ちますが、特に米国の代理店および米国の代理店を扱う組織に関連します。

NIST SP 800-63 の用語は少しわかりにくいことがあるため、可能な限り一般的に理解されている用語を使用し、わかりやすさに最適化して用語を標準化するように努めました。

そのため、この章では選択した NIST SP 800-63B コントロールのサブセットに準拠していますが、一般的な脅威と頻繁に悪用される認証の弱点に焦点を当てています。完全な NIST SP 800-63 準拠が必要な場合は、NIST SP 800-63 を参照してください。

私たちは米国政府機関に対して NIST SP 800-63 を全面的に見直し、実装することを強く要請します。

V1.2 認証ドキュメント

# 説明 L1 L2 L3 CWE
1.2.1 [14.6.2 へ移動]
1.2.2 [削除, 14.7.1 へマージ]
1.2.3 [削除, 1.2.4 と重複]
1.2.4 [修正, 2.2.11 へ分割] アプリケーションに複数の認証経路がある場合、それらすべてに一貫して適用されるべきセキュリティ制御と認証強度がともに文書化されている。 ✓ ✓ 306
1.2.5 [追加] コンテキスト固有の単語のリストが文書化されており、パスワードでの使用を防いでいる。 ✓ ✓ 521
1.2.6 [追加, 2.2.1 から分割] アプリケーションドキュメントでは、レート制限、自動化防止、適用応答などのコントロールが、クレデンシャルスタッフィングやパスワードブルートフォースなどの攻撃から防御するためにどのように使用されるかを定義している。このドキュメントでは、これらのコントロールがどのように構成されるかを明確にし、悪意のあるアカウントロックアウトを防ぐ必要がある。 ✓ ✓ ✓ 307

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

NIST SP 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 を破棄することが簡単なためです。一方、モバイルゲーム会社はアクティブなプレイヤベースを拡大するために、主要なソーシャルメディアプラットフォームと統合する必要があると考えるかもしれません。

このセクションの要件は主に NIST のガイダンス のセクション 5.1.1.2 に関連しています。

# 説明 L1 L2 L3 CWE
2.1.1 [修正] ユーザが設定するパスワードの長さは少なくとも 8 文字であるが、最低限 15 文字にすることを強く推奨している。 ✓ ✓ ✓ 521
2.1.2 [修正] 64 文字以上のパスワードが許可されている。 ✓ ✓ ✓ 521
2.1.3 [修正] アプリケーションは切り捨てや大文字小文字の変換などの修正をなにも加えずに、ユーザーから受け取ったパスワードを正確に検証している。 ✓ ✓ ✓
2.1.4 [削除, 不十分な影響]
2.1.5 [文法] ユーザは自身のパスワードを変更できる。 ✓ ✓ ✓ 620
2.1.6 パスワード変更機能には、ユーザの現在のパスワードと新しいパスワードが必要とされる。 ✓ ✓ ✓ 620
2.1.7 [修正, 2.1.13 へ分割] アカウント登録またはパスワード変更時に送信されるパスワードは少なくとも上位 3000 件の利用可能な一連のパスワードと照合されている。 ✓ ✓ ✓ 521
2.1.8 [削除, 不十分な影響]
2.1.9 使用可能な文字の種類を制限するパスワード規則がない。大文字、小文字、数字、特殊文字を要求する必要はない。 ✓ ✓ ✓ 521
2.1.10 [修正, レベル L1 > L2] ユーザのパスワードは侵害されたことが判明するか、ユーザーが変更するまで有効のままである。アプリケーションは定期的なクレデンシャルのローテーションを要求してはいけない。 ✓ ✓
2.1.11 パスワード入力に対して、ペースト、ブラウザのパスワードヘルパー、および外部パスワードマネージャが使用できる。 ✓ ✓ ✓ 521
2.1.12 [修正] パスワード入力フィールドは type=password を使用して、そのエントリをマスクしている。アプリケーションはユーザがマスクしたパスワード全体または最後に入力したパスワードの文字を一時的に閲覧できるようにしている。 ✓ ✓ ✓ 549
2.1.13 [追加, 2.1.7 から分割, レベル L1 > L3] アカウント登録またはパスワード変更時に送信されるパスワードは一連の侵害されたパスワードと照合されている。 ✓
2.1.14 [追加] コンテキスト固有の単語の文書化されたリストを使用して、推測されやすいパスワードが作成されることを防いでいる。 ✓ ✓ 521

要件 2.1.7 でよく使用されるパスワードのソースとして考えられるものは以下のとおりです。

V2.2 一般的な認証セキュリティ

認証要素のアジリティは将来も使い続けるアプリケーションにとって不可欠です。アプリケーションは、ユーザーの好みに応じて、追加の安全な認証要素を使用できるようにし、非推奨または安全でない認証メカニズムを所定の方法に従って廃止する必要があります。

NIST は SMS を 「制限された」認証メカニズム ("restricted" authentication mechanism) と考えており、将来的に NIST SP 800-63 から、ひいては ASVS から削除される可能性があります。本稿執筆時点ではまだそうなっていませんが、アプリケーションは SMS の使用を必要としないロードマップを計画すべきです。

NIST SP 800-63 は電子メールを認証メカニズムとして 受け入れられない (not acceptable) としています。

このセクションの要件は NIST のガイダンス の 4.2.1, 4.3.1, 5.2.2, 6.1.2 などのさまざまなセクションに関連しています。

# 説明 L1 L2 L3 CWE
2.2.1 [修正, 1.2.6 へ分割] クレデンシャルスタッフィングやパスワードブルートフォースなどの攻撃を防ぐためのコントロールは、アプリケーションのセキュリティドキュメントに従って実装されている。 ✓ ✓ ✓ 307
2.2.2 [修正] 電子メールは単一要素認証メカニズムとしても多要素認証メカニズムとしても使用されない。 ✓ ✓ ✓ 304
2.2.3 [修正, 2.2.10 へ分割] クレデンシャルのリセットや、ユーザ名や電子メールアドレスの変更など、認証情報の更新された後に、ユーザに通知されている。 ✓ ✓ ✓ 778
2.2.4 [修正, 2.2.9 へ分割, 2.2.7, 2.3.2 からマージ] フィッシング攻撃に対するなりすまし耐性 (WebAuthn など) を提供し、ユーザによるアクション (FIDO ハードウェアキーのボタン押下など) を要求することで認証の意図を検証する、ハードウェア支援の認証メカニズムがサポートされている。 ✓ 308
2.2.5 [9.3.3 へ移動]
2.2.6 [削除, 2.7.3, 2.8.4 と重複]
2.2.7 [削除, 2.2.4 へマージ]
2.2.8 [追加] エラーメッセージ、HTTP レスポンスコード、またはさまざまなレスポンスタイムなどに基づくことによって、失敗した認証チャレンジから有効なユーザーを推定することはできない。登録とパスワード忘れ機能にもこの保護が必要である。 ✓
2.2.9 [追加, 2.2.4 から分割] アプリケーションは、ユーザに多要素認証メカニズムの使用を要求するか、単一要素認証メカニズムの組み合わせを要求している。 ✓ ✓ 308
2.2.10 [追加, 2.2.3 から分割] 不審な認証の試行があった場合にユーザに通知されている。これには、通常とは異なる場所やクライアントからの認証の成功または失敗、多要素のうち一つだけでの部分的な認証の成功、長期間使用しなかった後の認証の成功または失敗、数回失敗した後の認証の成功などがある。 ✓ ✓ 778
2.2.11 [追加, 1.2.4 から分割] アプリケーションに複数の認証経路がある場合、文書化されていない経路がなく、セキュリティ制御と認証強度が一貫して適用されている。 ✓ ✓ 306

V2.3 認証要素ライフサイクル

認証メカニズムにはパスワード、ソフトトークン、ハードウェアトークン、生体認証デバイスが含まれます。これらの認証メカニズムのライフサイクルはアプリケーションのセキュリティにとって重要です。任意の人が身分証明のないアカウントを自己登録できる場合、ID アサーションに対する信頼はほとんどありません。Reddit のようなソーシャルメディアサイトでは、それはまったく問題ありません。銀行システムでは、クレデンシャルやデバイスの登録と発行にフォーカスすることが、アプリケーションのセキュリティにとって重要です。

注: パスワードの最大有効期間をもつべきではありません。パスワードローテーションの原因となります。パスワードは定期的に入れ替えるのではなく、侵害されているかどうかを確認する必要があります。

# 説明 L1 L2 L3 CWE
2.3.1 [修正] システムで生成される初期パスワードやアクティベーションコードは安全にランダムに生成され、既存のパスワードポリシーに従い、短期間または初期使用後に失効している。これらの初期シークレットが長期パスワードになることは許可されない。 ✓ ✓ ✓ 330
2.3.2 [削除, 2.2.4 へマージ]
2.3.3 [修正] 期限切れになる認証メカニズムの更新指示は、古い認証メカニズムの期限が切れる前に実行できるように、十分な時間をとって送信され、必要に応じて自動リマインダを設定している。 ✓ ✓ 287
2.3.4 [追加] 管理ユーザはユーザのパスワードリセット処理を開始できるが、ユーザのパスワードを変更したり選択することはできない。これによりユーザのパスワードを管理ユーザに知られる状況を防いでいる。 ✓ ✓ ✓ 620

V2.4 クレデンシャルの保管

アーキテクトおよび開発者はコードをビルドまたはリファクタリングする際にこのセクションを順守すべきです。

承認されたパスワードハッシュアルゴリズムの現行リストは NIST SP 800-63B section 5.1.1.2 および OWASP Password Storage Cheatsheet で詳しく説明されています。構成ガイダンスに細心の注意を払い、各アルゴリズムの実装上の課題や制限に注意します。執筆時点では、サイドチャネル攻撃への耐性と、カスタマイズ可能なメモリ、CPU、並列処理パラメータに基づいて、Argon2id が推奨されるパスワードハッシュアルゴリズムです。

特に、これらのアルゴリズムは意図的に計算量を多くしているため、非常に長いパスワードを入力するとサービス拒否状態に陥るケースが過去にあったことに注意してください。したがって、これを防ぐことは非常に重要です。

# 説明 L1 L2 L3 CWE
2.4.1 [6.6.2 へ移動]
2.4.2 [削除, 不正確]
2.4.3 [削除, 6.6.2 へマージ]
2.4.4 [削除, 6.6.2 へマージ]
2.4.5 [削除, 不正確]

V2.5 クレデンシャルリカバリ

このセクションの要件は主に NIST のガイダンス のセクション 5.1.1.2 または 6.1.2.3 に関連しています。

# 説明 L1 L2 L3 CWE
2.5.1 [削除, 不正確]
2.5.2 [文法] パスワードのヒントや知識ベースの認証（いわゆる「秘密の質問」）が存在しない。 ✓ ✓ ✓ 640
2.5.3 [削除, 2.4.1 と重複]
2.5.4 [14.1.10 へ移動]
2.5.5 [削除, 2.2.3 と重複]
2.5.6 [修正] 忘れたパスワードをリセットするための安全なプロセスが実装されており、有効になっている多要素認証メカニズムをバイパスしない。 ✓ ✓ ✓ 640
2.5.7 [文法, レベル L2 > L1] OTP またはその他の多要素認証要素が失われた場合、登録時と同じレベルで同一性証明の証拠が実行される。 ✓ ✓ ✓ 308

V2.6 ルックアップシークレット

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

このセクションの要件は主に NIST のガイダンス のセクション 5.1.2 に関連しています。

# 説明 L1 L2 L3 CWE
2.6.1 ルックアップシークレットは一度だけしか使用されない。 ✓ ✓ 308
2.6.2 [修正, 2.6.4 へ分割] アプリケーションのバックエンドに保存される際、112 ビット未満のエントロピー (19 個のランダムな英数字または 34 個のランダムな数字) を持つルックアップシークレットは、32 ビットのランダムソルトを組み込んだ承認済みのパスワードストレージハッシュアルゴリズムでハッシュされる。シークレットが 112 ビット以上のエントロピーを持つ場合は、標準的なハッシュ関数を使用できる。 ✓ ✓ 330
2.6.3 [修正] ルックアップシークレットは予測可能な値を避けるために暗号的に安全な疑似乱数ジェネレータ (Cryptographically Secure Pseudorandom Number Generator, CSPRNG) を使用して生成されている。 ✓ ✓ 310
2.6.4 [追加, 2.6.2 から分割] ルックアップシークレットは最低 20 ビットのエントロピー (通常 4 個のランダムな英数字または 6 個のランダムな数字で十分です) を持っている。 ✓ ✓ 330

V2.7 経路外認証メカニズム

過去において、一般的な経路外認証メカニズムはパスワードリセットリンクを含む電子メールまたは SMS でした。攻撃者はこの脆弱なメカニズムを使用して、ある人物の電子メールアカウントを乗っ取り、発見されたリセットリンクを再利用するなど、まだ制御していないアカウントをリセットします。経路外の検証を処理するためのより良い方法があります。

安全な経路外認証メカニズムでは一般的に認証サーバが安全なセカンダリチャネルをを介して物理デバイスと通信します。たとえばモバイルデバイスへのプッシュ通知などがあります。このタイプの認証メカニズムは「あなたが持っているもの (something you have)」とみなされます。

通信には認証コード (通常はランダムな数字/コード (プライマリチャネルを介してコンファメーションとして送り返されます)) を含めたり、何らかの形の承認ダイアログを使用することがあります。認証サーバはコンファメーションの受信を待ち、正しく受信された場合は認証が成功したとみなすことができます。

ASVS では、新しいタイプの経路外認証メカニズムを開発する開発者はほとんどおらず、むしろ既存のタイプを利用することを想定しています。そのため、以下の ASVS 要件は既存のメカニズムに焦点を当てています。新しいタイプの経路外メカニズムを開発する場合は、NIST SP 800-63B § 5.1.3.1 を参照してください。

電子メールや VOIP などの安全でない経路外認証メカニズムは許可されていません。PSTN および SMS 認証は現在 NIST により「制限」され、廃止対象であり、プッシュ通知などを推奨しています。電話または SMS の経路外認証を使用する必要がある場合には、NIST SP 800-63B § 5.1.3.3 を参照してください。

このセクションの要件は主に NIST のガイダンス のセクション 5.1.3 に関連しています。

# 説明 L1 L2 L3 CWE
2.7.1 [修正] 公衆交換電話網 (PSTN) を使用して電話または SMS 経由でワンタイムパスワード (OTP) を配信する認証メカニズムは、より強力な代替手段 (プッシュ通知など) も提供され、サービスがそのセキュリティリスクに関する情報をユーザに提供する場合にのみ提供される。 ✓ ✓ ✓ 287
2.7.2 [修正] 経路外認証リクエスト、コード、またはトークンは 10 分以内に期限切れになる。 ✓ ✓ ✓ 287
2.7.3 [文法] 経路外認証リクエストやコード、またはトークンが 1 回しか使用できず、元の認証リクエストに対してのみ使用可能となっている。 ✓ ✓ ✓ 287
2.7.4 [文法] 使用されているセカンダリ通信チャネルは安全であり、プライマリチャネルから独立している。 ✓ ✓ ✓ 523
2.7.5 [削除, 不十分な影響]
2.7.6 [修正] 経路外認証で使用されるコードは暗号的に安全な乱数生成器 (CSPRNG) を使用して生成され、少なくとも 20 ビットのエントロピーを含む (通常は 4 つのランダムな英数字または 6 つのランダムな数字で十分である)。 ✓ ✓ 310
2.7.7 [追加] コードベースの経路外認証メカニズムはレート制限または少なくとも64ビットのエントロピーを持つコードのいすれかを使用して、ブルートフォース攻撃から保護されている。 ✓ ✓ 307
2.7.8 [追加] プッシュ通知が多要素認証に使用される場合、レート制限や番号照合を使用して、プッシュ爆撃攻撃を防いでいる。 ✓

V2.8 時間ベースのワンタイムパスワード

単一要素で時間ベースのワンタイムパスワード（Time-based, One-time Password, TOTP）は継続的に変化する疑似ランダムワンタイムチャレンジを表示する物理トークンまたはソフトトークンです。このタイプの認証メカニズムは「持っているもの (something you have)」とみなされます。

多要素トークンは単一要素 TOTP と似ていますが、有効な PIN コード、生体認証ロック解除、USB 挿入または NFC ペアリングまたは追加の値（トランザクション署名計算機など）を入力して最終 OTP を作成する必要があります。

このセクションの要件は NIST のガイダンス の 5.1.4.2, 5.1.5.2, 5.2.1, 5.2.3 などのさまざまなセクションに関連しています。

# 説明 L1 L2 L3 CWE
2.8.1 [文法] 時間ベースのワンタイムパスワードは期限切れまでの有効期間が定義されている。 ✓ ✓ ✓ 613
2.8.2 [文法] 送信された時間ベースのワンタイムパスワードを検証するために使用される対称鍵は、ハードウェアセキュリティモジュールまたはセキュアなオペレーティングシステムベースのキーストレージなどを使用して、高度に保護されている。 ✓ ✓ 320
2.8.3 [文法] 承認済みの暗号化アルゴリズムが時間ベースのワンタイムパスワードの生成、シード、検証に使用されている。 ✓ ✓ 326
2.8.4 [文法] 時間ベースのワンタイムパスワードが有効期間内に 1 回しか使用できない。 ✓ ✓ 287
2.8.5 [削除, 不十分な影響]
2.8.6 [修正, レベル L2 > L3] 盗難やその他の損失が発生した場合は、物理的な単一要素の OTP ジェネレータを無効にすることができる。場所に関係なく、ログインしたセッション全体で失効がすぐに反映される。 ✓ 613
2.8.7 [修正, レベル L2 > L3] 生体認証メカニズムが、自分が持っているものと自分が知っているものの、いずれかと一緒に二次的要素としてのみ使用されている。 ✓ 308
2.8.8 [追加] 時間ベースの多要素 OTP トークンの生成がクライアントのマシンではなくサーバーのシステム時間に基づいている。 ✓ 367

V2.9 暗号化認証メカニズム

暗号化認証メカニズムはスマートカードまたは FIDO キーを含み、ユーザは認証を完了するために暗号化デバイスをコンピュータに接続するかペアリングする必要があります。認証サーバはチャレンジナンスを暗号化デバイスまたはソフトウェアに送信し、デバイスまたはソフトウェアはセキュアに保存された暗号化キーに基づいてレスポンスを計算します。

単一要素暗号化デバイスとソフトウェア、および多要素暗号化デバイスとソフトウェアの要件は同じです。これは暗号化デバイスの検証が認証要素の所有を証明するためです。

このセクションの要件は主に NIST のガイダンス のセクション 5.1.7.2 に関連しています。

# 説明 L1 L2 L3 CWE
2.9.1 [修正, レベル L2 > L3] 認証サーバは、Trusted Platform Module (TPM) や Hardware Security Module (HSM)、またはこの安全なストレージを使用できる OS サービスなどを使用して、検証に使用される暗号鍵を安全に保存し、漏洩から保護している。 ✓ 320
2.9.2 [レベル L2 > L3] チャレンジナンスは少なくとも 64 ビットの長さがあり、統計的に一意か、暗号化デバイスの有効期間を通じて一意となっている。 ✓ 330
2.9.3 [修正, レベル L2 > L3] 承認された暗号化アルゴリズムが暗号化キーの生成、シード、および検証に使用されている。 ✓ 327

V2.10 サービス認証

# 説明 L1 L2 L3 CWE
2.10.1 [14.7.1 へ移動]
2.10.2 [14.7.2 へ移動]
2.10.3 [削除, 2.10.4 と重複]
2.10.4 [削除, 14.8.1 へマージ]

V2.11 アイデンティティプロバイダによる認証

# 説明 L1 L2 L3 CWE
2.11.1 [追加] アプリケーションが複数のアイデンティティプロバイダ (IDP) をサポートしている場合、サポートされている別のアイデンティティプロバイダを介して (たとえば同じユーザ識別子を使用して) ユーザのアイデンティティを偽装できない。通常、アプリケーションは (名前空間として機能する) IdP ID と IDP 内のユーザ ID の組み合わせを使用して、ユーザを登録および識別する必要がある。 ✓ ✓
2.11.2 [追加] 認証アサーション (JWT や SAML アサーションなど) のデジタル署名の存在と完全性は常に検証され、署名されていないアサーションや無効な署名を持つアサーションは拒否される。 ✓ ✓
2.11.3 [追加] SAML アサーションは一意に処理され、有効期間内に一度だけ使用され、リプレイ攻撃を防いでいる。 ✓ ✓

参考情報

詳しくは以下の情報を参照してください。