アカウント アクセス用メールの到着が遅れると、ユーザーはさらに複数のメールをリクエストすることがよくあります。これにより、重複したメッセージが作成され、有効期限が混乱し、キューに余分な負荷がかかる可能性があります。 DNSのせいにしたり、すべてのトークンの有効期間を延長したりする前に、リクエストから使用に至るまでのプロセスを診断します。
編集されたイベント タイムラインを構築する
内部相関識別子を使用して、リクエストの受け入れ、トークンの作成、ジョブのキューへの登録、プロバイダの受け入れ、受信者の応答、およびトークンの引き換えまたは拒否を結合します。トークン、リセット URL、または OTP をルーチン ログに記録しないでください。トラブルシューティングに必要なメッセージ サンプルへのアクセスが厳しく制限された、識別子と理由カテゴリを記録します。
SMTP受け入れは、サーバーがその段階で責任を受け入れたことを意味します。受信箱の配置や人間がメッセージを読むことを示すものではありません。サポート ツールでもその区別を維持します。 RFC 5321.
OWASP ロギング ガイダンス ルーチン ログからシークレットを除外しながら相関関係をサポートします。
認証をアプリケーションの有効性から分離する
最終的な制御メッセージを検査して、意図された送信者の ID と信頼できる受信者の認証結果を確認します。ベンダー構成が古いと、ニュースレターが機能していてもこのルートが壊れる可能性があります。逆に、メール認証に合格しても、期限切れまたはすでに使用されているアプリケーション トークンを有効にすることはできません。
OWASP では、適切な有効期限、安全なストレージ、アカウントの列挙や過剰なリクエストに対する保護を備えた安全に生成された使い捨てトークンまたはコードを推奨します。パスワード リセット ガイダンスは、リセット フローのセキュリティ ベースラインを提供するものであり、電子メール配信の遅延について約束するものではありません。 OWASP パスワードを忘れた場合のガイダンス.
他の認証用途に電子メールで配信されるコードには、独自のセキュリティ評価が必要です。電子メールの所有をフィッシング耐性のある認証として説明しないでください。また、パスワード リセットの推奨によってすべての OTP 導入が承認されると想定しないでください。 NIST 、デジタル ID 要件の中で、帯域外認証手段としての電子メールを禁止していますが、アドレス確認コードと回復コードはその禁止から区別しています。 NIST SP 800-63B-4 セクション 3.1.3 および3.1.3.1.
有効性の予算を調整する
仮想のタイムラインでは、トークンの作成が09:00:00に、有効期限が09:05:00に設定されます。プロバイダーの受け入れは09:00:10に発生し、レシーバーの受け入れは09:04:40に発生し、例示的なユーザー アクションは09:05:20に発生します。受信機の受信時間はわずか 20 秒です。アクションは有効期限が切れてから 20 秒後に発生します。
トークンは有効期限切れ以降は無効であるという宣言されたポリシーの下では、299 秒目に提示された有効な未使用のトークンは依然としてこの 5 分間の時間枠内にありますが、300 秒または 301 秒目の提示ではこの時間枠内には収まりません。すでに引き換えられたトークンは、時間が残っているという理由だけで再利用可能になってはなりません。これらは、作成されたポリシーに基づいて期待される結果であり、実行されたトークン チェックや推奨されるユニバーサル ライフタイムではありません。
実用的な問題は、作成から受信者が受け入れられるまでの 280 秒がどこにいったのかということです。 10 秒目の時点でプロバイダーが受け入れられたということは、次の 270 秒間が完全に 1 つのプロバイダー内で費やされたことを証明するものではありません。責任を割り当てる前に、キューと応答の証拠を入手してください。受信トレイの可視性は不明のままです。実際のトークン、運用アカウント、配信はテストされませんでした。
失敗したステージを修復する
アプリケーションのキューに入るのが遅すぎる場合は、アカウント アクセスのワークロードを優先し、回避可能なバッチ遅延を削除します。プロバイダーが一時的なエラーを報告した場合は、完全な応答とサポートされている再試行処理を検査してください。新しいリクエストによってトークンが無効になった場合は、認証されていないリクエスト者にアカウントが存在するかどうかを公開せずに、その動作を理解できるようにします。
レート制限を使用し、一般的な要求応答をクリアして、クリックの繰り返しがメールの洪水になるのを防ぎます。再試行をアプリケーションのトークン ポリシーと調整します。古いメッセージをやみくもに再送信すると、すでに無効になったトークンが配信される可能性がありますが、無制限に新しいトークンを発行すると悪用のリスクが高まる可能性があります。
シークレットを記録せずに検証する
関連する宛先全体で承認済みの管理アカウントをテストし、ステージの待ち時間、有効期限の結果、重複処理を記録します。有効期限、トークンの生成、またはアカウントの回復に対する変更にはセキュリティのレビューが必要です。有効期間を延長することは、キューを修正することに代わるものではありません。
段階別の原因、範囲を絞った修復、および測定されたカスタマー ジャーニーによってインシデントを解決します。残りの可視性のギャップを明示的に保ちます。サポートは、顧客がメッセージを読んだと主張したり、資格情報を公開したりせずに、「受信者が受け入れ、有効期限が切れた」ことを説明できる必要があります。
失敗段階からオーナーを選択する
キューの遅延はアプリケーションまたは送信側オペレーターに属します。明示的な受信拒否は経路調査に属します。期限切れまたはすでに使用されている結果は、トークン ポリシーおよびアプリケーションの状態に属します。編集された相関レコードを 1 つ保持し、関連する所有者に承認された再テストを定義してもらいます。