プロンプトとコンテキスト
低リスクなSaaSにおいて、ユーザーがメールアドレスを入力し、ワンタイムログインリンクを受信できるようにしたいと考えています。リクエスト、配信、検証、セッション確立、失効、および監査のフローを設計してください。侵害されたメールボックス、転送されたリンク、メールのプリフェッチ、リプレイ、レート制限の悪用、および高リスクなアクションを考慮してください。
面接官がテストしていること
- 予測不可能で短命な使い捨てトークンを使用しているか。
- アカウント列挙、ログへの漏洩、およびブルートフォース検証を防いでいるか。
- 利便性と保証レベルおよびフィッシング耐性を区別できているか。
- セッション、失効、通知、監査、およびフォールバックが網羅されているか。
回答前の明確化のための質問
ビジネスリスク、確認済みメールの状態、マルチデバイスの挙動、リンクの有効期間、メールプロバイダー、MFA、および高リスクな操作を確認します。決済、権限変更、機密データには、メール単体を高保証要素とするのではなく、フィッシング耐性のある認証または追加認証が必要です。
30秒の回答フレームワーク
高エントロピーのランダムトークンを生成し、そのハッシュ、用途、ユーザー、有効期限、および消費状態のみを保存します。既存のアドレスと未知のアドレスの両方に対して同じレスポンスを返し、リクエストをレート制限します。HTTPS経由で検証し、トークンをアトミックに消費してから、短命なセッションを作成してその識別子をローテーションします。1回限りの使用を許可し、失敗や異常なデバイスを監査し、必要に応じて失効させます。マジックリンクのセキュリティはメールボックスおよびブラウザチャネルのリスクを継承するため、自動的にフィッシング耐性を持つわけではなく、すべてのNIST保証レベルに適しているわけでもありません。
ステップバイステップの詳細解説
1. 生成と保存
暗号学的に安全なランダム値をワンタイムURLパラメータとして使用し、平文ではなくそのハッシュを保存します。用途、ユーザー、作成日時と有効期限、消費日時、およびリクエストコンテキストを記録します。一定時間（constant-time）でハッシュを比較し、試行回数を制限します。
2. リクエストと検証
列挙を防ぐため、すべてのメールアドレスに対して同じメッセージ、応答タイミングの枠組み、およびステータスを返します。IP、アドレス、デバイス、およびグローバルバジェットごとにレート制限を行い、メール送信クォータを設定します。検証時は、トランザクションまたはアトミックな条件付き更新でトークンを消費済みにマークし、同時に発生した2回のクリックによるリプレイを防止する必要があります。
3. セッションとリスク制御
消費後は、セッション識別子をローテーションし、セキュアCookieを設定し、デバイスと位置情報をユーザーに通知します。メールのプリフェッチャーやスキャナーが先にリンクにアクセスする可能性があるため、中間確認ページと明示的なユーザーアクションを使用します。リンクを長期間有効な特権クレデンシャルに変えるのではなく、機密性の高い操作には再認証、MFA、またはWebAuthnを要求します。
質の高い回答例
私はマジックリンクを、低リスクなアクセスのための便利な要素であり、普遍的なフィッシング耐性を持つ認証方式ではないと定義します。リクエスト後、サービスはCSPRNGを使用し、ハッシュ、用途、有効期限、消費状態のみを保存し、すべてのアドレスに対して同じ結果を返します。検証側はHTTPS経由でハッシュを検索し、アトミックに消費済みにマークし、セッションIDをローテーションし、セキュアCookieを設定し、監査イベントを記録します。リンクは短命で失効可能であり、そのURLはログやアナリティクスから除外する必要があります。プリフェッチに対処するため、確認ページを表示して意図的なクリックを要求します。転送や複数デバイスについては、1回のみの消費を許可するかどうか、およびアカウント所有者にどのように通知するかを定義します。決済や権限変更にはMFAまたはWebAuthnを使用します。テストではリプレイ、同時クリック、列挙、レート制限、メール漏洩、異常なデバイス、および失効をカバーします。
よくある間違い
- トークンをデータベースやログに平文で保存すること。
- アトミックな消費に失敗し、同時リプレイを許してしまうこと。
- 未知のアドレスに対して異なるエラーを返し、列挙を可能にしてしまうこと。
- マジックリンクを本質的にフィッシング耐性がある、またはハードウェアキーと同等であると呼ぶこと。
- 期限切れのリンクを長寿命のセッションと交換したり、通知や失効を省略したりすること。
フォローアップの質問と回答
メールクライアントのプリフェッチについてはどうしますか？
GETアクセス時にログインを完了させないでください。確認ページを表示し、明示的なユーザーアクションの後にのみトークンを消費し、プリフェッチのテレメトリと実際のクリックを区別します。
トークンの有効期間はどれくらいにすべきですか？
リスクとメール遅延の許容範囲から短いウィンドウを選択し、リプレイ率や未使用率を監視します。有効期限が切れた後は、古いトークンを延長するのではなく、新しいトークンを発行します。
なぜ管理者や決済の承認に使用しないのですか？
メールボックスチャネルは転送、乗っ取り、またはフィッシングの可能性があり、NISTは一部のメール確認の用途を高保証認証とは区別しています。高リスクなアクションには、フィッシング耐性のある認証、トランザクションバインディング、および独立した通知が必要です。