V6: 認証
管理目標
認証とは個人またはデバイスの真正性を確立または確認するプロセスです。これには個人またはデバイスに関する主張を検証し、なりすましへの耐性を確保し、パスワードのリカバリや傍受を防止することが含まれます。
NIST SP 800-63 は世界中の組織にとって価値のある最新のエビデンスベースの標準ですが、特に米国の機関および米国の機関とやり取りする組織に関連します。
この章の要件の多くは標準 (NIST SP 800-63B "Digital Identity Guidelines - Authentication and Lifecycle Management") の二番目のセクションに基づいていますが、この章では一般的な脅威と頻繁に悪用される認証の弱点に焦点を当てており、標準のすべてのポイントを包括的に網羅するものではありません。NIST SP 800-63 への完全な準拠が必要な場合は、NIST SP 800-63 を参照してください。
さらに、NIST SP 800-63 の用語は時として異なることがあり、この章ではより一般的に理解されている用語を使用することで、わかりやすさを向上します。
より高度なアプリケーションに共通する機能の一つは、さまざまなリスク要因に基づいて、必要な認証ステージを適応する機能です。これらのメカニズムも認可の決定に考慮される必要があるため、この機能は「認可」の章でカバーします。
V6.1 認証ドキュメント
このセクションはアプリケーションについて保持すべき認証ドキュメントの詳細を規定する要件を含みます。これは関連する認証コントロールをどのように構成すべきかを実装して評価する上で非常に重要です。
6.1.1
アプリケーションドキュメントでは、レート制限、自動化防止、適用応答などのコントロールが、クレデンシャルスタッフィングやパスワードブルートフォースなどの攻撃から防御するためにどのように使用されるかを定義している。このドキュメントでは、これらのコントロールがどのように構成されるかを明確にし、悪意のあるアカウントロックアウトを防ぐ必要がある。
1
6.1.2
コンテキスト固有の単語のリストが文書化されており、パスワードでの使用を防いでいる。このリストには、組織名、製品名、システム識別子、プロジェクトコード名、部門名、ロール名などの配列を含むことがある。
2
6.1.3
アプリケーションに複数の認証経路がある場合、それらすべてに一貫して適用される必要があるセキュリティ制御と認証強度がともに文書化されている。
2
V6.2 パスワードセキュリティ
NIST SP 800-63 により「記憶された秘密 (Memorized Secrets)」と呼ばれるパスワードには、パスワード、パスフレーズ、PIN、ロック解除パターン、および正しい子猫や他の画像要素の選択があります。それらは一般に「知識認証 (something you know)」とみなされ、多くの場合に単要素認証メカニズムとして使用されます。
そのため、このセクションはパスワードが安全に作成され処理されるようにするための要件を含みます。要件のほとんどはそのレベルで最も重要であるため L1 となっています。L2 以降では、多要素認証メカニズムが必要となり、パスワードはその要素の一つとなることがあります。
このセクションの要件は主に NIST のガイダンス の § 5.1.1.2 に関連しています。
6.2.1
ユーザが設定するパスワードの長さは少なくとも 8 文字であるが、最低限 15 文字にすることを強く推奨している。
1
6.2.2
ユーザは自身のパスワードを変更できる。
1
6.2.3
パスワード変更機能にはユーザの現在のパスワードと新しいパスワードが必要とされる。
1
6.2.4
アカウント登録またはパスワード変更時に送信されるパスワードは、アプリケーションのパスワードポリシー (最小長など) に合致する、少なくとも上位 3000 件の利用可能な一連のパスワードと照合されている。
1
6.2.5
パスワードはどのような構成でも使用でき、許可される文字の種類を制限するルールはない。大文字、小文字、数字、特殊文字の最低数についての要求を設けてはいけない。
1
6.2.6
パスワード入力フィールドは type=password を使用して、そのエントリをマスクしている。アプリケーションはユーザがマスクしたパスワード全体または最後に入力したパスワードの文字を一時的に閲覧できるようにしている。
1
6.2.7
「貼り付け」機能、ブラウザのパスワードヘルパー、および外部のパスワードマネージャが許可されている。
1
6.2.8
アプリケーションは切り捨てや大文字小文字の変換などの修正をなにも加えずに、ユーザーから受け取ったパスワードを正確に検証している。
1
6.2.9
64 文字以上のパスワードが許可されている。
2
6.2.10
ユーザのパスワードは侵害されたことが判明するか、ユーザーが変更するまで有効のままである。アプリケーションは定期的なクレデンシャルの変更を要求してはいけない。
2
6.2.11
コンテキスト固有の単語の文書化されたリストを使用して、推測されやすいパスワードが作成されることを防いでいる。
2
6.2.12
アカウント登録またはパスワード変更時に送信されるパスワードは一連の侵害されたパスワードと照合されている。
2
V6.3 一般的な認証セキュリティ
このセクションでは、認証メカニズムのセキュリティに関する一般的な要件と、レベルごとの期待事項について説明します。L2 アプリケーションでは多要素認証 (MFA) の使用を強制する必要があります。L3 アプリケーションでは、認証済みの高信頼実行環境 (TEE) で実行される、ハードウェアベースの認証を使用する必要があります。これには、デバイスにバインドされたパスキー、eIDAS Level of Assurance (LoA) High 準拠のオーセンティケータ、NIST Authenticator Assurance Level 3 (AAL3) 保証のオーセンティケータ、または同等のメカニズムを含みます。
これは MFA に関する比較的積極的なスタンスですが、ユーザを保護するためにこれに関する基準を引き上げることが極めて重要であり、これらの要件を緩和しようとする場合には、このトピックに関する NIST のガイダンスとリサーチを考慮に入れて、認証に関するリスクをどのように軽減するかについての明確な計画を伴う必要があります。
リリース時点において、NIST SP 800-63 は電子メールを認証メカニズムとして 受け入れられない (not acceptable) としていることに注意してください (アーカイブされたコピー)。
このセクションの要件は NIST のガイダンス の § 4.2.1, § 4.3.1, § 5.2.2, § 6.1.2 などのさまざまなセクションに関連しています。
6.3.1
クレデンシャルスタッフィングやパスワードブルートフォースなどの攻撃を防ぐためのコントロールは、アプリケーションのセキュリティドキュメントに従って実装されている。
1
6.3.2
デフォルトユーザーアカウント ("root", "admin", "sa" など) がアプリケーションに存在しないか、無効になっている。
1
6.3.3
アプリケーションにアクセスするには、多要素認証メカニズム、または単要素認証のメカニズムの組み合わせのいずれかを使用する必要がある。L3 では、ユーザによるアクション (FIDO ハードウェアキーやスマートフォンのボタン押下など) を要求することで認証の意図を検証しつつ、フィッシング攻撃に対する侵害やなりすましへの耐性を提供しているハードウェアベースの認証メカニズムが要素の一つである必要がある。この要件における考慮事項のいずれかを緩和するには、十分に文書化された根拠と包括的な緩和策を必要とする。
2
6.3.4
アプリケーションに複数の認証経路がある場合、文書化されていない経路がなく、セキュリティ制御と認証強度が一貫して適用されている。
2
6.3.5
不審な認証試行 (成功または失敗) があった場合にユーザに通知されている。これには、通常とは異なる場所やクライアントからの認証試行、部分的に成功した認証 (多要素のうち一つのみ)、長期間使用されなかった後の認証試行、複数回失敗した後に成功した認証などがある。
3
6.3.6
電子メールは単要素認証メカニズムとしても多要素認証メカニズムとしても使用されない。
3
6.3.7
クレデンシャルのリセットや、ユーザ名や電子メールアドレスの変更など、認証情報の更新された後に、ユーザに通知されている。
3
6.3.8
エラーメッセージ、HTTP レスポンスコード、またはさまざまなレスポンスタイムなどに基づくことによって、失敗した認証チャレンジから有効なユーザーを推定することはできない。登録とパスワード忘れ機能にもこの保護が必要である。
3
V6.4 認証要素のライフサイクルとリカバリ
認証要素にはパスワード、ソフトトークン、ハードウェアトークン、生体認証デバイスなどを含みます。これらのメカニズムのライフサイクルを安全に処理することは、アプリケーションのセキュリティにとって重要であり、このセクションはこれに関連する要件を含みます。
このセクションの要件は主に NIST のガイダンス の § 5.1.1.2 または § 6.1.2.3 に関連しています。
6.4.1
システムで生成される初期パスワードやアクティベーションコードは安全にランダムに生成され、既存のパスワードポリシーに従い、短期間または初期使用後に失効している。これらの初期シークレットが長期パスワードになることは許可されない。
1
6.4.2
パスワードのヒントや知識ベースの認証 (いわゆる「秘密の質問」) が存在しない。
1
6.4.3
忘れたパスワードをリセットするための安全なプロセスが実装されており、有効になっている多要素認証メカニズムをバイパスしない。
2
6.4.4
多要素認証要素が失われた場合、登録時と同じレベルで同一性証明の証拠が実行される。
2
6.4.5
期限切れになる認証メカニズムの更新指示は、古い認証メカニズムの期限が切れる前に実行できるように、十分な時間をとって送信され、必要に応じて自動リマインダを設定している。
3
6.4.6
管理ユーザはユーザのパスワードリセット処理を開始できるが、ユーザのパスワードを変更したり選択することはできない。これによりユーザのパスワードを管理ユーザに知られる状況を防いでいる。
3
V6.5 一般的な多要素認証要件
このセクションではさまざまな多要素認証方式に関連する一般的なガイダンスを提供します。
メカニズムには以下のものがあります。
ルックアップシークレット
時間ベースのワンタイムパスワード (TOTP)
経路外メカニズム
ルックアップシークレットはトランザクション認証番号 (TAN) 、ソーシャルメディアリカバリーコードなどの、事前に生成されたシークレットコードのリスト、またはランダム値のセットを含むグリッドです。このタイプの認証メカニズムは、コードが意図的に記憶しにくいものであり、どこかに保存しておく必要があるため、「所有物認証 (something you have)」とみなされます。
時間ベースのワンタイムパスワード (Time-based, One-time Password, TOTP) は継続的に変化する疑似ランダムワンタイムチャレンジを表示する物理トークンまたはソフトトークンです。このタイプの認証メカニズムは「所有物認証 (something you have)」とみなされます。多要素トークンは単要素 TOTP と似ていますが、有効な PIN コード、生体認証ロック解除、USB 挿入または NFC ペアリングまたは追加の値 (トランザクション署名計算機など) を入力して最終ワンタイムパスワード (OTP) を作成する必要があります。
経路外メカニズムの詳細については、次のセクションで説明します。
このセクションの要件は主に NIST のガイダンス の § 5.1.2, § 5.1.3, § 5.1.4.2, § 5.1.5.2, § 5.2.1, § 5.2.3 に関連しています。
6.5.1
ルックアップシークレット、経路外認証リクエストまたはコード、時間ベースのワンタイムパスワード (TOTP) は一度のみ正常に使用できる。
2
6.5.2
アプリケーションのバックエンドに保存される際、112 ビット未満のエントロピー (19 個のランダムな英数字または 34 個のランダムな数字) を持つルックアップシークレットは、32 ビットのランダムソルトを組み込んだ承認済みのパスワードストレージハッシュアルゴリズムでハッシュされる。シークレットが 112 ビット以上のエントロピーを持つ場合は、標準的なハッシュ関数を使用できる。
2
6.5.3
ルックアップシークレット、経路外認証コード、時間ベースのワンタイムパスワードのシードは、予測可能な値を避けるために暗号論的に安全な疑似乱数生成器 (Cryptographically Secure Pseudorandom Number Generator, CSPRNG) を使用して生成されている。
2
6.5.4
ルックアップシークレットと経路外認証コードは最低 20 ビットのエントロピー (通常 4 個のランダムな英数字または 6 個のランダムな数字で十分です) を持っている。
2
6.5.5
経路外認証リクエスト、コード、トークン、および時間ベースのワンタイムパスワード (TOTP) は定められた有効期間を持っている。経路外リクエストでは最大有効時間を 10 分にする必要があり、TOTP では最大有効時間を 30 秒とする必要がある。
2
6.5.6
あらゆる認証要素 (物理デバイスを含む) は盗難やその他の紛失の場合に無効化できる。
3
6.5.7
生体認証メカニズムは所有物認証 (something you have) または知識認証 (something you know) のいずれかと一緒に、二次的要素としてのみ使用されている。
3
6.5.8
時間ベースのワンタイムパスワード (TOTP) は、信頼できない時間やクライアントが提供する時間ではなく、信頼できるサービスからの時間ソースに基づいてチェックされている。
3
V6.6 経路外認証メカニズム
通常、これは認証サーバが安全なセカンダリチャネルを介して物理デバイスと通信します。たとえば、モバイルデバイスへのプッシュ通知などがあります。このタイプの認証メカニズムは「所有物認証 (something you have)」とみなされます。
電子メールや VOIP などの安全でない経路外認証メカニズムは許可されていません。PSTN および SMS 認証は現在 NIST により 「制限された」認証メカニズム ("restricted" authentication mechanism) と考えられており、廃止すべきであり、時間ベースのワンタイムパスワード (TOTP)、暗号メカニズム、または同様のものを優先します。NIST SP 800-63B § 5.1.3.3 では、電話または SMS の経路外認証を絶対にサポートする必要がある場合、デバイス交換、SIM 変更、番号ポーティング、その他の異常な動作のリスクに対処することを推奨しています。この ASVS セクションではこれを要件として義務付けているわけではありませんが、機密性の高い L2 アプリや L3 アプリに対してこれらの予防措置を講じないことは、重大な危険信号とみなす必要があります。
また、NIST は最近 プッシュ通知の使用を推奨しない というガイダンスも提供していることに注意してください。この ASVS セクションではプッシュ通知の使用を推奨していませんが、「プッシュ爆撃」のリスクを認識しておくことが重要です。
6.6.1
公衆交換電話網 (PSTN) を使用して電話または SMS 経由でワンタイムパスワード (OTP) を配信する認証メカニズムは、電話番号が事前に検証され、より強力な代替手段 (時間ベースのワンタイムパスワードなど) も提供され、サービスがそのセキュリティリスクに関する情報をユーザに提供する場合にのみ提供される。L3 アプリケーションでは、電話と SMS はオプションとして利用してはいけない。
2
6.6.2
経路外認証リクエスト、コード、またはトークンはそれらが生成された元の認証リクエストにバインドされており、それ以前やそれ以降のものに対しては使用できない。
2
6.6.3
コードベースの経路外認証メカニズムはレート制限を使用して、ブルートフォース攻撃から保護されている。また、少なくとも64ビットのエントロピーを持つコードの使用も検討する。
2
6.6.4
プッシュ通知が多要素認証に使用される場合、レート制限を使用して、プッシュ爆撃攻撃を防いでいる。また、番号照合もこのリスクを緩和できることがある。
3
V6.7 暗号認証メカニズム
暗号認証メカニズムはスマートカードまたは FIDO キーを含み、ユーザは認証を完了するために暗号デバイスをコンピュータに接続するかペアリングする必要があります。認証サーバはチャレンジナンスを暗号デバイスまたはソフトウェアに送信し、デバイスまたはソフトウェアは安全に保存された暗号鍵に基づいてレスポンスを計算します。このセクションの要件はこれらのメカニズムに対する実装固有のガイダンスを提供します。暗号化アルゴリズムに関するガイダンスは「暗号化」の章でカバーされています。
共有鍵や秘密鍵が暗号認証に使用される場合、「構成」の章の「シークレット管理」セクションに記載されているように、これらは他のシステムシークレットと同じメカニズムを使用して保存すべきです。
このセクションの要件は主に NIST のガイダンス の § 5.1.7.2 に関連しています。
6.7.1
暗号認証アサーションを検証するために使用される証明書は、変更から保護される方法で保存されている。
3
6.7.2
チャレンジナンスは少なくとも 64 ビットの長さがあり、統計的に一意か、暗号デバイスの有効期間を通じて一意となっている。
3
V6.8 アイデンティティプロバイダによる認証
アイデンティティプロバイダ (Identity Provider, IdP) はユーザに統合されたアイデンティティを提供します。ユーザは、Azure AD、Okta、Ping Identity、Google を使用するエンタープライズアイデンティティや、Facebook、Twitter、Google、WeChat を使用するコンシューマアイデンティティなど、複数の IdP で複数のアイデンティティを持つことがよくあります。これらは一般的な代替手段のほんの一例です。このリストはこれらの企業やサービスを推奨するものではなく、多くのユーザが多くの確立されたアイデンティティを持っているという現実を考慮するよう、開発者に促すものです。組織は IdP のアイデンティティ証明の強さのリスクプロファイルに従って、既存のユーザアイデンティティとの統合を検討する必要があります。たとえば、政府機関が機密性の高いシステムのログインとしてソーシャルメディアアイデンティティを受け入れることは考えにくく、それは偽のアイデンティティを作成したり捨てることが簡単だからです。一方、モバイルゲーム会社はアクティブなプレイヤーベースを拡大するために、主要なソーシャルメディアプラットフォームと統合する必要があるかもしれません。
外部アイデンティティプロバイダを安全に使用するには、アイデンティティスプーフィングや偽造されたアサーションを防止するための慎重な構成と検証が必要です。このセクションではこれらのリスクに対処するための要件を示します。
6.8.1
アプリケーションが複数のアイデンティティプロバイダ (IdP) をサポートしている場合、サポートされている別のアイデンティティプロバイダを介して (たとえば同じユーザ識別子を使用して) ユーザのアイデンティティを偽装できない。標準的な緩和策としてはアプリケーションが (名前空間として機能する) IdP ID と IdP 内のユーザ ID の組み合わせを使用して、ユーザを登録および識別することである。
2
6.8.2
認証アサーション (JWT や SAML アサーションなど) のデジタル署名の存在と完全性は常に検証され、署名されていないアサーションや無効な署名を持つアサーションは拒否される。
2
6.8.3
SAML アサーションは一意に処理され、有効期間内に一度だけ使用され、リプレイ攻撃を防いでいる。
2
6.8.4
アプリケーションが別のアイデンティティプロバイダ (IdP) を使用し、特定の機能に対して特定の認証強度、認証方法、認証日時を期待する場合、アプリケーションは IdP から返される情報を使用してこれを検証している。たとえば、OIDC を使用する場合、これは 'acr', 'amr', 'auth_time' (存在する場合) などの ID トークンクレームを検証することで実現できる。IdP がこの情報を提供しない場合、アプリケーションは最低限の強度の認証メカニズム (たとえば、ユーザ名とパスワードを使用した単要素認証) が使用されたと想定する、文書化されたフォールバックアプローチを備えている必要がある。
2
参考情報
詳しくは以下の情報を参照してください。
Last updated
Was this helpful?