GUIDはワンタイムトークンに対して安全ですか？
多くのサイトでは、パスワードのリセット、購読解除要求、その他の形式の一意の識別にGUIDを使用しています。
生成が簡単で、ユニークで、シーケンシャルではなく、ランダムに見えるため、おそらく魅力的です。
しかし、これらの目的のために十分安全ですか？
GUIDを指定すると、（私の知る限り）暗号的に安全であることが意図されていないため、後続のGUIDを予測できる可能性があるようです...
注意：
- 私はではなくbase64でエンコードされたgobbledygookのランダムなblobを使用するサイトについて話しています。
- 私は生のGUIDを使用しているように見えるこのようなサイトについて話している：
http://example.com/forgotPassword/?id=b4684ce3-ca5b-477f-8f4d-e05884a83d3c
彼らはあなたが説明した目的のために十分安全ですか？私の意見では、一般的にはい。それらは、セキュリティが重要な懸念事項であるアプリケーションで十分に安全ですか？いいえ。これらは非ランダムアルゴリズムを使用して生成されているため、暗号的にランダムでも安全でもありません。
したがって、購読解除または購読の検証機能の場合、セキュリティの問題は実際には発生しません。一方、オンラインバンキングアプリケーションのユーザーを識別するには（または、おそらくIDが重要なサイトのパスワードリセット機能でさえ）、GUIDは明らかに不十分です。
詳細については、RFC 4122のGUID（またはUniversally Unique Identifiers）の セクション6（セキュリティに関する考慮事項） を確認してください。
ID仕様 は、UUIDを生成するための方法であるいくつかの「バージョン」を詳しく説明しています。ほとんどは、現在の日付などを使用して一意性（UUIDの主要なポイント）を保証することを目的としています。これは効率的ですが、生成されたUUIDはuniqueですが、predictableでもあるため、一部のセキュリティ用途には不十分です。 。
"バージョン4" UUID生成方法（セクション4.4） は、ただし、暗号学的に強力な乱数ジェネレータを使用することになっています。 128ビットのうち6ビットは従来の値に固定されているため（つまり、バージョン4のUUIDであることを示すため）、RNGから122ビットが残ります。
If基になるRNGは安全です（例：Linux/MacOS/* BSDシステムでは_/dev/urandom_、またはCryptGenRandom() on Windows）その後、生成された多くのUUIDが与えられた場合、攻撃者は2より大きい成功確率で次のUUIDを予測することができないはずです-122核ミサイルの発射コードを含め、ほとんどの目的には十分に小さい。
122個のランダムビットは、高い確率で一意性を保証します。多くのバージョン4のUUIDを生成して蓄積すると、約2の後で最初の衝突が発生する可能性があります。61 UUID-それは約20億の十億です;その数のUUIDを格納するだけでは、3,000万テラバイトを超える量が使用されます。 「唯一」と考えるなら1012 そのようなUUID（1000億、16テラバイトを超えて保存可能）、これらの中に2つの同じUUIDが存在するリスクは約9.4 * 10です。-14つまり、宝くじで数百万ドルを獲得するよりも約70万分の1の確率が低くなります。
したがって、UUIDはセキュリティの目的で適切ですif（かつ、その場合のみ）安全なRNGで生成された「バージョン4」のUUID 。
Windows 2000以降では安全です。脆弱性とリスクは、GUIDの生成方法によって異なります。Windows2000以降では、暗号化されたセキュリティで保護されたバージョン4のGUIDを使用しています。
詳細については このMSDNリンク およびこの スタックオーバーフローの質問 を参照してください。 （コメントのJordan Riegerに感謝）
共通の開発言語を使用している場合、適切な暗号化関数を使用して一意の乱数のワンショットジェネレーターを作成することはそれほど難しくありません（Googleを使用するだけで、最も一般的な言語のサンプルとして利用できる10行のコードについて話しています） ）そのため、単純な新しいGUIDを使用すると、基本的に開発者の観点からは怠惰になります。
説明したシナリオでは、パスワードを忘れた場合の関数に渡されたGuidにいくつかの基本的な機能がある場合、「十分に安全」です。
1）これは実際にはユーザーIDとは関係のないワンショット値であるため、いったんパスワードがリセットされると、もう使用できません。
2）有効期間が定義されています（次の30分程度でパスワードをリセットできます）。
同じGuidを使用している場合は、パスワードを複数回リセットするか、パスワードのリセットを要求しなかったユーザーのGUIDとリセットパスワードを推測するか、Avidがコメントで説明しているように、何らかの方法でパスワードをリセットするためのアクセス権を取得してくださいリプレイアタッチすると、アプリケーションの設計に問題があり、Guidの使用の有無は実際の問題ではありません。
非常に機密性の高い情報を扱っていない場合は、おそらくguidが機能しますが、適切な方法で最初に物事を作成し、適切な暗号APIを使用して安全なランダム文字列を生成しないのはなぜですか？
マッシモよろしく
偽の「GUID」。これはnot任意のGUID=生成アルゴリズムによって生成されますが、代わりに暗号的に安全なPRNGによって生成される単に128ビット（16バイト）です。また、従来のGUID hex-with-hyphensエンコーディングを使用して表されているだけで、ワンタイムトークンに対してほとんど安全です。
ただし、128ビットトークンの場合、衝突の存在は約2 ^ -64であるため、誕生日の問題が発生します。
衝突の存在が約2 ^ -128または2 ^ -256である256ビットまたは512ビットトークンを使用する方が良い。