V6: 認証
Last updated
Was this helpful?
Last updated
Was this helpful?
認証とは個人またはデバイスの信頼性を確立または確認するプロセスです。これには個人またはデバイスに関する主張を検証し、なりすましへの耐性を確保し、パスワードのリカバリや傍受を防止することが含まれます。
は最新のエビデンスベースの標準であり、適用可能性とは関係なく、利用可能な最適なアドバイスを表しています。この標準は世界中のすべての組織に役立ちますが、特に米国の代理店および米国の代理店を扱う組織に関連します。
この章では、要件を準備する際に NIST SP 800-63B "Digital Identity Guidelines - Authentication and Lifecycle Management" として知られる NIST 標準の二番目のセクションを参照することが役立ちました。
ただし、NIST SP 800-63 の用語は時として異なることがあるため、可能な限り一般的に理解されている用語を使用して、章をより明確にするように努めました。
つまり、この章では選択した NIST SP 800-63B コントロールのサブセットに準拠していますが、一般的な脅威と頻繁に悪用される認証の弱点に焦点を当てています。完全な NIST SP 800-63 準拠が必要な場合は、NIST SP 800-63 を参照してください。
このセクションはアプリケーションについて保持すべき認証ドキュメントの詳細を規定する要件を含みます。これは関連する認証コントロールをどのように構成すべきかを実装して評価する上で非常に重要です。
1.2.6
[追加, 2.2.1 から分割] アプリケーションドキュメントでは、レート制限、自動化防止、適用応答などのコントロールが、クレデンシャルスタッフィングやパスワードブルートフォースなどの攻撃から防御するためにどのように使用されるかを定義している。このドキュメントでは、これらのコントロールがどのように構成されるかを明確にし、悪意のあるアカウントロックアウトを防ぐ必要がある。
1
v5.0.be-1.2.6
1.2.5
[追加] コンテキスト固有の単語のリストが文書化されており、パスワードでの使用を防いでいる。
2
v5.0.be-1.2.5
1.2.4
[修正, 2.2.11 へ分割, 1.2.3 をカバー] アプリケーションに複数の認証経路がある場合、それらすべてに一貫して適用されるべきセキュリティ制御と認証強度がともに文書化されている。
2
v5.0.be-1.2.4
NIST SP 800-63 により「記憶された秘密」と呼ばれるパスワードには、パスワード、PIN、ロック解除パターン、正しい子猫や他の画像要素の選択、およびパスフレーズがあります。それらは一般に「知識認証 (something you know)」とみなされ、多くの場合に単要素認証メカニズムとして使用されます。L2 以降では、多要素認証メカニズムが必要となり、パスワードはその要素の一つとなることがあります。
そのため、このセクションはパスワードが安全に作成され処理されるようにするための要件を含みます。
このセクションの要件は主に の に関連しています。
2.1.1
[修正] ユーザが設定するパスワードの長さは少なくとも 8 文字であるが、最低限 15 文字にすることを強く推奨している。
1
v5.0.be-2.1.1
2.1.5
[文法] ユーザは自身のパスワードを変更できる。
1
v5.0.be-2.1.5
2.1.6
パスワード変更機能にはユーザの現在のパスワードと新しいパスワードが必要とされる。
1
v5.0.be-2.1.6
2.1.7
[修正, 2.1.13 へ分割] アカウント登録またはパスワード変更時に送信されるパスワードは、アプリケーションのパスワードポリシー (最小長など) に合致する、少なくとも上位 3000 件の利用可能な一連のパスワードと照合されている。
1
v5.0.be-2.1.7
2.1.9
使用すべき文字の種類を制限するパスワード構成規則がない。大文字、小文字、数字、特殊文字を要求する必要はない。
1
v5.0.be-2.1.9
2.1.12
[修正] パスワード入力フィールドは type=password を使用して、そのエントリをマスクしている。アプリケーションはユーザがマスクしたパスワード全体または最後に入力したパスワードの文字を一時的に閲覧できるようにしている。
1
v5.0.be-2.1.12
2.1.11
「貼り付け」機能、ブラウザパスワードヘルパー、および外部のパスワードマネージャが許可されている。
1
v5.0.be-2.1.11
2.1.3
[修正] アプリケーションは切り捨てや大文字小文字の変換などの修正をなにも加えずに、ユーザーから受け取ったパスワードを正確に検証している。
2
v5.0.be-2.1.3
2.1.2
[修正] 64 文字以上のパスワードが許可されている。
2
v5.0.be-2.1.2
2.1.10
[修正, レベル L1 > L2] ユーザのパスワードは侵害されたことが判明するか、ユーザーが変更するまで有効のままである。アプリケーションは定期的なクレデンシャルのローテーションを要求してはいけない。
2
v5.0.be-2.1.10
2.1.14
[追加] コンテキスト固有の単語の文書化されたリストを使用して、推測されやすいパスワードが作成されることを防いでいる。
2
v5.0.be-2.1.14
2.1.13
[追加, 2.1.7 から分割, レベル L1 > L3] アカウント登録またはパスワード変更時に送信されるパスワードは一連の侵害されたパスワードと照合されている。
3
v5.0.be-2.1.13
要件 2.1.7 でよく使用されるパスワードのソースとして考えられるものは以下のとおりです。
このセクションは認証メカニズムのセキュリティに関する一般的な要件を含むほか、L2 では多要素認証を要求し、L3 ではハードウェアベースのメカニズムをサポートするなど、レベルごとにさまざまな期待事項を規定しています。
2.2.1
[修正, 1.2.6 へ分割] クレデンシャルスタッフィングやパスワードブルートフォースなどの攻撃を防ぐためのコントロールは、アプリケーションのセキュリティドキュメントに従って実装されている。
1
v5.0.be-2.2.1
2.2.9
[追加, 2.2.4 から分割] アプリケーションは、ユーザに多要素認証メカニズム、または単要素認証メカニズムの組み合わせのいずれかの使用を要求している。
2
v5.0.be-2.2.9
2.2.11
[追加, 1.2.4 から分割] アプリケーションに複数の認証経路がある場合、文書化されていない経路がなく、セキュリティ制御と認証強度が一貫して適用されている。
2
v5.0.be-2.2.11
2.2.10
[追加, 2.2.3 から分割] 不審な認証の試行があった場合にユーザに通知されている。これには、通常とは異なる場所やクライアントからの認証の成功または失敗、多要素のうち一つだけでの部分的な認証の成功、長期間使用しなかった後の認証の成功または失敗、数回失敗した後の認証の成功などがある。
3
v5.0.be-2.2.10
2.2.2
[修正] 電子メールは単要素認証メカニズムとしても多要素認証メカニズムとしても使用されない。
3
v5.0.be-2.2.2
2.2.3
[修正, 2.2.10 へ分割, 2.5.5 をカバー] クレデンシャルのリセットや、ユーザ名や電子メールアドレスの変更など、認証情報の更新された後に、ユーザに通知されている。
3
v5.0.be-2.2.3
2.2.4
[修正, 2.2.9 へ分割, 2.2.7, 2.3.2 からマージ] フィッシング攻撃に対するなりすまし耐性 (WebAuthn など) を提供し、ユーザによるアクション (FIDO ハードウェアキーのボタン押下など) を要求することで認証の意図を検証する、ハードウェア支援の認証メカニズムがサポートされている。
3
v5.0.be-2.2.4
2.2.8
[追加] エラーメッセージ、HTTP レスポンスコード、またはさまざまなレスポンスタイムなどに基づくことによって、失敗した認証チャレンジから有効なユーザーを推定することはできない。登録とパスワード忘れ機能にもこの保護が必要である。
3
v5.0.be-2.2.8
認証要素にはパスワード、ソフトトークン、ハードウェアトークン、生体デバイスなどを含みます。これらのメカニズムのライフサイクルを安全に処理することは、アプリケーションのセキュリティにとって重要であり、このセクションはこれに関連する要件を含みます。
2.5.8
[修正, 2.3.1 から移動] システムで生成される初期パスワードやアクティベーションコードは安全にランダムに生成され、既存のパスワードポリシーに従い、短期間または初期使用後に失効している。これらの初期シークレットが長期パスワードになることは許可されない。
1
v5.0.be-2.5.8
2.5.2
[文法] パスワードのヒントや知識ベースの認証 (いわゆる「秘密の質問」) が存在しない。
1
v5.0.be-2.5.2
2.5.6
[修正] 忘れたパスワードをリセットするための安全なプロセスが実装されており、有効になっている多要素認証メカニズムをバイパスしない。
2
v5.0.be-2.5.6
2.5.7
[文法, レベル L2 > L1] OTP またはその他の多要素認証要素が失われた場合、登録時と同じレベルで同一性証明の証拠が実行される。
2
v5.0.be-2.5.7
2.5.9
[修正, 2.3.3 から移動] 期限切れになる認証メカニズムの更新指示は、古い認証メカニズムの期限が切れる前に実行できるように、十分な時間をとって送信され、必要に応じて自動リマインダを設定している。
3
v5.0.be-2.5.9
2.5.10
[追加] 管理ユーザはユーザのパスワードリセット処理を開始できるが、ユーザのパスワードを変更したり選択することはできない。これによりユーザのパスワードを管理ユーザに知られる状況を防いでいる。
3
v5.0.be-2.5.10
このセクションではさまざまな多要素認証方式に関連する一般的なガイダンスを提供します。
メカニズムには以下のものがあります。
ルックアップシークレット
時間ベースのワンタイムパスワード (TOTP)
経路外メカニズム
ルックアップシークレットはトランザクション認証番号 (TAN) 、ソーシャルメディアリカバリーコードなどの、事前に生成されたシークレットコードのリスト、またはランダム値のセットを含むグリッドです。このタイプの認証メカニズムは、コードがランダムであり、どこかに保存しておく必要があるため、「所有物認証 (something you have)」とみなされます。
時間ベースのワンタイムパスワード (Time-based, One-time Password, TOTP) は継続的に変化する疑似ランダムワンタイムチャレンジを表示する物理トークンまたはソフトトークンです。このタイプの認証メカニズムは「所有物認証 (something you have)」とみなされます。多要素トークンは単要素 TOTP と似ていますが、有効な PIN コード、生体認証ロック解除、USB 挿入または NFC ペアリングまたは追加の値 (トランザクション署名計算機など) を入力して最終 OTP を作成する必要があります。
経路外メカニズムの詳細については、以降のセクションで説明します。
2.6.1
[修正, 2.8.4 からマージ, 2.7.3 から分割, 2.2.6 をカバー] ルックアップシークレット、経路外認証リクエストまたはコード、時間ベースのワンタイムパスワード (TOTP) は一度のみ使用できる。
2
v5.0.be-2.6.1
2.6.2
[修正, 2.6.4 へ分割] アプリケーションのバックエンドに保存される際、112 ビット未満のエントロピー (19 個のランダムな英数字または 34 個のランダムな数字) を持つルックアップシークレットは、32 ビットのランダムソルトを組み込んだ承認済みのパスワードストレージハッシュアルゴリズムでハッシュされる。シークレットが 112 ビット以上のエントロピーを持つ場合は、標準的なハッシュ関数を使用できる。
2
v5.0.be-2.6.2
2.6.3
[修正, 2.8.3 からマージ, 2.7.6 から分割] ルックアップシークレット、経路外認証コード、時間ベースのワンタイムパスワードのシードは、予測可能な値を避けるために暗号論的に安全な疑似乱数生成器 (Cryptographically Secure Pseudorandom Number Generator, CSPRNG) を使用して生成されている。
2
v5.0.be-2.6.3
2.6.4
[追加, 2.6.2, 2.7.6 から分割] ルックアップシークレットと経路外認証コードは最低 20 ビットのエントロピー (通常 4 個のランダムな英数字または 6 個のランダムな数字で十分です) を持っている。
2
v5.0.be-2.6.4
2.6.5
[修正, 2.7.2 から移動, 2.8.1 からマージ] 経路外認証リクエスト、コード、トークン、および時間ベースのワンタイムパスワード (TOTP) は定められた有効期間を持っている。経路外では、これは 10 分にすべきであり、TOTP では、これはできる限り短く、通常は 30 秒とすべきである。
2
v5.0.be-2.6.5
2.6.6
[修正, 2.8.6 から移動, レベル L2 > L3] あらゆる認証要素 (物理デバイスを含む) は盗難やその他の紛失の場合に無効化できる。
3
v5.0.be-2.6.6
2.6.7
[修正, 2.8.7 から移動, レベル L2 > L3] 生体認証メカニズムは所有物認証 (something you have) または知識認証 (something you know) のいずれかと一緒に、二次的要素としてのみ使用されている。
3
v5.0.be-2.6.7
2.6.8
[追加] 時間ベースの OTP は、信頼できない時間やクライアントが提供する時間ではなく、信頼できるサービスからの時間ソースに基づいてチェックされている。
3
v5.0.be-2.6.8
これは一般的に認証サーバが安全なセカンダリチャネルを介して物理デバイスと通信します。たとえばモバイルデバイスへのプッシュ通知や、SMS 経由でユーザに送信されるワンタイムパスワード (OTP) などがあります。このタイプの認証メカニズムは「所有物認証 (something you have)」とみなされます。
2.7.1
[修正] 公衆交換電話網 (PSTN) を使用して電話または SMS 経由でワンタイムパスワード (OTP) を配信する認証メカニズムは、より強力な代替手段 (プッシュ通知など) も提供され、サービスがそのセキュリティリスクに関する情報をユーザに提供する場合にのみ提供される。L3 アプリケーションでは、電話と SMS はオプションとして利用してはいけない。
2
v5.0.be-2.7.1
2.7.3
[修正, 2.6.1 へ分割] 経路外認証リクエスト、コード、またはトークンはそれらが生成された元の認証リクエストに対してのみ使用でき、それ以前やそれ以降のものに対しては使用できない。
2
v5.0.be-2.7.3
2.7.7
[追加] コードベースの経路外認証メカニズムはレート制限または少なくとも64ビットのエントロピーを持つコードのいすれかを使用して、ブルートフォース攻撃から保護されている。
2
v5.0.be-2.7.7
2.7.8
[追加] プッシュ通知が多要素認証に使用される場合、レート制限や番号照合を使用して、プッシュ爆撃攻撃を防いでいる。
3
v5.0.be-2.7.8
暗号化認証メカニズムはスマートカードまたは FIDO キーを含み、ユーザは認証を完了するために暗号化デバイスをコンピュータに接続するかペアリングする必要があります。認証サーバはチャレンジナンスを暗号化デバイスまたはソフトウェアに送信し、デバイスまたはソフトウェアはセキュアに保存された暗号鍵に基づいてレスポンスを計算します。このセクションの要件はこれらのメカニズムに対する実装固有のガイダンスを提供し、暗号化アルゴリズムに関するガイダンスは「暗号化」の章でカバーされています。
共有鍵や秘密鍵が暗号化認証に使用される場合、「構成」の章の「シークレット管理」セクションに記載されているように、これらは他のシステムシークレットと同じメカニズムを使用して保存すべきです。
2.9.1
[修正, 14.8.1 へ分割, レベル L2 > L3] 暗号化認証アサーションを検証するために使用される証明書は、変更から保護される方法で保存されている。
3
v5.0.be-2.9.1
2.9.2
[レベル L2 > L3] チャレンジナンスは少なくとも 64 ビットの長さがあり、統計的に一意か、暗号化デバイスの有効期間を通じて一意となっている。
3
v5.0.be-2.9.2
アイデンティティプロバイダ (Identity Provider, IdP) はユーザに統合されたアイデンティティを提供します。ユーザは、Azure AD、Okta、Ping Identity、Google を使用するエンタープライズアイデンティティ、Facebook、Twitter、Google、WeChat を使用するコンシューマアイデンティティなど、複数の IdP で複数のアイデンティティを持つことがよくあります。これらは一般的な代替手段のほんの一例です。このリストはこれらの企業やサービスを推奨するものではなく、多くのユーザが多くの確立されたアイデンティティを持っているという現実を考慮するよう、開発者に促すものです。組織は IdP のアイデンティティ証明の強さのリスクプロファイルに従って、既存のユーザアイデンティティとの統合を検討する必要があります。たとえば、政府機関が機密性の高いシステムのログインとしてソーシャルメディアアイデンティティを受け入れることは考えにくく、それは偽のアイデンティティを作成したり捨てることが簡単だからです。一方、モバイルゲーム会社はアクティブなプレイヤーベースを拡大するために、主要なソーシャルメディアプラットフォームと統合する必要があるかもしれません。
外部アイデンティティプロバイダを安全に使用するには、アイデンティティスプーフィングや偽造されたアサーションを防止するための慎重な構成と検証が必要です。このセクションではこれらのリスクに対処するための要件を示します。
2.11.1
[追加] アプリケーションが複数のアイデンティティプロバイダ (IdP) をサポートしている場合、サポートされている別のアイデンティティプロバイダを介して (たとえば同じユーザ識別子を使用して) ユーザのアイデンティティを偽装できない。通常、アプリケーションは (名前空間として機能する) IdP ID と IdP 内のユーザ ID の組み合わせを使用して、ユーザを登録および識別する必要がある。
2
v5.0.be-2.11.1
2.11.2
[追加] 認証アサーション (JWT や SAML アサーションなど) のデジタル署名の存在と完全性は常に検証され、署名されていないアサーションや無効な署名を持つアサーションは拒否される。
2
v5.0.be-2.11.2
2.11.3
[追加] SAML アサーションは一意に処理され、有効期間内に一度だけ使用され、リプレイ攻撃を防いでいる。
2
v5.0.be-2.11.3
詳しくは以下の情報を参照してください。
NIST SP 800-63 は電子メールを認証メカニズムとして としていることに注意してください。
このセクションの要件は の , , , などのさまざまなセクションに関連しています。
このセクションの要件は主に の または に関連しています。
このセクションの要件は主に の , , , , , に関連しています。
電子メールや VOIP などの安全でない経路外認証メカニズムは許可されていません。PSTN および SMS 認証は現在 NIST により と考えられており、廃止対象であり、プッシュ通知などを推奨しています。電話または SMS の経路外認証を使用する必要がある場合には、NIST SP 800-63B を参照してください。
このセクションの要件は主に の に関連しています。