開発者ツール · UUID ジェネレーター
ランダムな UUID はパスワード リセットまたはセッション トークンとして安全ですか?
· なぜそれが重要なのか
uuid 暗号化 ブラウザ API
CSPRNG の v4 UUID には大量のエントロピーが含まれていますが、なぜセキュリティレビュー担当者は依然として UUID トークンに眉をひそめるのでしょうか?この投稿では、エントロピーの問題と設計の問題を分離します。
行の UUID を使用するリセット リンク — 一般的なショートカットと、それが安全でない可能性がある 2 つのまったく異なる理由
一般的なショートカット: ユーザーの UUID 行識別子をパスワード リセット トークンとして使用します。テーブルには uuid 列があります。それはユニークです。 (v4 の場合) 推測するのは困難です。 URL は /reset? token=550e8400-e29b-41d4-a716-446655440000 です。セキュリティレビュー担当者は、UUID が弱いからではなく、独立しているはずの 2 つの懸念事項を結合しているため、すぐにそれを拒否します。行 UUID は安定しており、通常は (URL、API、ログで) 公開されます。リセット トークンは 1 回のみ使用でき、秘密である必要があります。行 UUID をトークンとして再利用するということは、ユーザーの ID とリセットされた資格情報が同じ値であり、資格情報が期限切れになるのではなく永久に存続することを意味します。ユーザーの ID を知っている攻撃者はリセットを実行できる可能性があります。 5 年前にリセット リンクをコピー＆ペーストしたユーザーは、引き続きそのリンクを使用できます。これらは設計上の欠陥であり、エントロピー上の欠陥ではありません。
エントロピー チェック: 122 ランダム ビット — CSPRNG で生成された v4 がブルート フォースで推測できない理由
ランダム性チェックは必要ですが、十分ではありません。バージョン 4 は、4 つのバージョン ビットと 2 つのバリアント ビットを予約し、実装が他のフィールドをランダムに埋める場合、128 - 4 - 2 = 122 のランダムな位置を残します。この導出では、有効期限、保管、または承認については何も述べられていません。ジェネレーター チェックでは、これらのフィールドが Math.random またはタイムスタンプではなく CSPRNG から取得されたかどうかが尋ねられます。 ToolAcre はそのジェネレーター境界を満たします。設計チェックはアプリケーション固有のままです。リセットされた認証情報には、別個のライフサイクル、一方向の保存表現、正常に使用された後の無効化、およびサービスのリスク ポリシーから選択された有効期限が必要です。ユーザーの永久レコード ID を再利用すると、ID が安全に生成された場合でも分離が失敗します。
ジェネレーター チェック: UUID トークンが実際に失敗する場所 — Math.random ベースの生成、v1 タイムスタンプと MAC アドレス、および予測可能なシード
成功した例: 3 つのチェックに失敗し、その後合格するパスワード リセット スキーム。エントロピー チェックに失敗します。サーバーは、v4 UUID としてパックされた Math.random() 経由でリセット トークンを発行します。攻撃者は 3 つのトークンを観察し、4 つ目のトークンを予測します。ジェネレーターのチェックに失敗します。サーバーは、値に作成タイムスタンプと MAC アドレスを含む v1 UUID をリセット トークンとして使用します。攻撃者はタイムスタンプを読み取り、いつリセットが発行されたかを学習し、検索ウィンドウを狭めます。エントロピー チェックには合格しますが、設計チェックには失敗します。サーバーは crypto.getRandomValues の v4 UUID を使用しますが、それをデータベースにプレーン テキストで保存し、有効期限を設定しません。データベースに侵入した攻撃者はリセット トークンを読み取り、それを使用して数週間後にアカウントをリセットします。 3 つのチェックは独立しています。 3 つすべてに合格する必要があります。
設計チェック: 識別子と資格情報 — レコードの主キーをシークレットとして再利用することで、独立してローテーションする必要がある 2 つのものが結合される理由
エントロピーとジェネレーターのチェックには合格するが、設計チェックに失敗する (ハッシュなし、有効期限なし、使用ごとの無効化なし) リセット トークン スキームは依然として脆弱です。トークンのサーバー側の処理: ユーザーがパスワードのリセットを要求すると、crypto.getRandomValues から新しいランダム トークン (行 UUID ではない) が生成されます。提示された値ではなく一方向の表現を保存し、ポリシー固有の有効期限を設定し、正常に使用された後にレコードを無効にします。ユーザーがリンクをクリックすると、電子メールでユーザーを検索し、保存されているハッシュを取得し、提供されたトークンとハッシュを比較して有効期限を確認し、トークンが有効でまだ期限切れになっていない場合にのみリセットを実行します。トークンをすぐに無効にし（削除するか、使用済みとしてマークし）、再利用できないようにします。生のトークンをログに記録しないでください。ユーザー ID とアクションのみをログに記録します。
サーバー側でトークンを処理する — ハッシュを保存し、有効期限を設定し、使用時に無効化し、生の値をログに記録しない
トークンは、ハッシュ化されない限り、エラー メッセージやデータベースに表示されることはありません。完全な認証設計は UUID 記事の範囲を超えていますが、122 ビットのランダム トークンは本質的にアクセス トークンではないという原則は当てはまります。ランダム性は簡単な部分です。 ToolAcre ジェネレーターは、CSPRNG ベースの UUID を提供します。難しい部分は設計です。保存前のハッシュ化、有効期限の設定、使用時の無効化、一時的な秘密としての永久 ID の再利用の防止、誰がいつ何にアクセスしたかの監査などです。トークンのエントロピーのみに基づいてリセットリンク スキームを承認するセキュリティレビュー担当者は、残りの分析をスキップします。 CSPRNG でサポートされた UUID が、ハッシュ化、有効期限、無効化を行わずにパスワードをリセットするリンクとして十分であると考えている開発者は、脅威を過小評価しています。ランダム性は推測を防ぎます。この設計により、リプレイ、期限切れ、誤用が防止されます。
作業例 — 各チェックに対するリセットリンクスキームをレビューし、弱い部分を書き直す
ToolAcre ジェネレーターはランダム性の部分を適切に実行します。アプリケーションは設計部分を正しく行う必要があります。独自のリセットリンク コードを 3 つのチェックすべてに対してテストします。Math.random ではなく、CSPRNG (crypto.getRandomValues、crypto.randomUUID、または暗号化ライブラリ) を使用しているかどうか。トークンには有効期限がありますか?トークンは保存前にハッシュされますか?トークンは使用後に無効になりますか?コードはユーザーの永久 ID を一時トークンとして再利用することを避けていますか?これらすべてに「はい」と答えた場合、リセット リンクの設計は適切です。 ToolAcre ジェネレーターは CSPRNG 部分です。残りはアプリケーション コードであり、注意深く確認する必要があります。 3 つのセキュリティ層を理解すると、サードパーティの UUID ライブラリとフレームワークを監査するのに役立ちます。ライブラリを評価するときは、弱いランダム ソースではなく、CSPRNG (エントロピー チェック) を使用していることを確認してください。どのソースを使用するか、およびその理由が文書化されていることを確認してください (ジェネレーター チェック)。
これでカバーされないもの — トークンのエントロピーと同じくらい重要な、完全な認証設計、MFA、およびレート制限
サンプル コードとドキュメントで、ハッシュ、有効期限、無効化などの設計原則が強調されていることを確認してください (設計チェック)。 3 つのチェックすべてに合格するライブラリはまれです。ほとんどはエントロピーのみに焦点を当てています。 ToolAcre ジェネレーターは、crypto.getRandomValues を使用してエントロピーとジェネレーター チェックを渡します。デザインチェックはあなたの責任です。ライブラリは有効期限要件やハッシュ戦略を知ることができません。壊れたリセットリンク システムをデバッグすると、通常、3 つの障害のうち 1 つが明らかになります。機能しなくなったリセット リンクを受信したとユーザーが報告した場合、考えられる問題は有効期限です。トークンは発行されましたが、ユーザーがリンクをクリックする前に期限切れになりました。トークンが複数回再利用されると、無効化が解除されます。エラー メッセージまたはデバッグ出力にトークンが表示される場合、ロギングによってトークンが漏洩します。リセット リンクが、あるユーザーに対しては機能するが、別のユーザーに対しては機能しない場合は、データベース レプリケーションの遅延や、有効期限の計算にタイムゾーンの問題が発生している可能性があります。正当なリセット要求がランダムに失敗した場合、CSPRNG が壊れている可能性があります (まれですが)。
要点: ランダム性は簡単な部分です。ToolAcre ジェネレーターは CSPRNG でサポートされた UUID を提供します。残りは設計規律です
ログ記録から開始します。リセットリンクの生成と検証のための詳細な監査ログを有効にしてから、問題を再現してフローをトレースします。 ToolAcre ジェネレーターは、最初の 2 つのチェックに合格することを保証します。リセットリンクの問題のトラブルシューティングは、ほとんどの場合、設計カテゴリに分類されます。実稼働リセットリンク システムのベスト プラクティスには、リセット要求ごとに新しいランダム トークンを生成し、古いトークンを再利用しないことが含まれます。アカウントおよび作成メタデータとともに一方向表現を保存し、サービスの文書化されたリスク ポリシーから有効期限を選択します。検証が成功した後、すぐにトークンを無効にします。リセット要求と監査の成功をログに記録します。ブルートフォース攻撃を防ぐためにレート制限を実装します。リセット リンクは、SMS や暗号化されていないチャネルではなく、電子メールのみで送信してください。パスワードのリセット試行をユーザーに通知します (これにより、ユーザーは不正なリセットを検出できます)。 ToolAcre ジェネレーターはランダム性を提供します。これらのプラクティスに従うことで、セキュリティが確保されます。