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