GUIDは、Webアプリケーションのセッションキーの作成によく使用されます。私はいつもこの練習の安全性について疑問に思っていました。GUIDは、マシンからの情報と時間、およびその他のいくつかの要因に基づいて生成されるため、将来登場する可能性のあるGUIDを推測するのはどれほど困難です。生成されているGUIDの適切なデータセットを取得するために、1000または10000の新しいセッションを開始したとします。これにより、別のセッションで使用される可能性のあるGUIDを簡単に生成できるようになりますか。特定のGUIDを推測する必要はありませんが、特定の期間に生成される可能性のあるGUIDを試し続けるだけです。
6 に答える
ウィキペディア(元のソース)からのいくつかのものがあります:
MACアドレスと時刻を含むV1GUIDは、3番目の数字グループの最初の位置にある数字「1」で識別できます(例:{2f1e4fc0-81fd-11da-9156-00036a0f876a})。
私の理解では、彼らは実際にそれを隠していません。
V4 GUIDは、疑似乱数である後者のアルゴリズムを使用します。これらの同じ位置に「4」があります(例:{38a52be4-9352-453e-af97-5c3b448652f0})。より具体的には、「data3」ビットパターンは、最初のケースでは0001xxxxxxxxxxxxになり、2番目のケースでは0100xxxxxxxxxxxxになります。WinAPI GUIDジェネレーターの暗号解読は、V4 GUIDのシーケンスが疑似ランダムであるため、初期状態が与えられると、関数 UuidCreate1によって返される次の250000GUIDまでを予測できることを示しています。これが、GUIDを暗号化で、たとえばランダムキーとして使用してはならない理由です。
GUID は一意であることが保証されており、それだけです。ランダムまたは推測が困難であるとは限りません。
質問に答えるには、少なくとも V1 GUID 生成アルゴリズムについては、アルゴリズム、MAC アドレス、および作成時間を知っていれば、実際に生成された GUID のセットを生成できる可能性があります。また、V1 GUID の場合の MAC アドレスは、同じマシンのサンプル GUID から決定できます。
ウィキペディアからの追加情報:
新しい GUID を生成するための OSF 固有のアルゴリズムは、広く批判されてきました。これらの (V1) GUID では、ユーザーのネットワーク カードの MAC アドレスが、GUID 数字の最後のグループのベースとして使用されます。つまり、たとえば、ドキュメントを作成したコンピューターまで追跡できます。このプライバシー ホールは、Melissa ワームの作成者を特定する際に使用されました。他の桁のほとんどは、GUID を生成する際の時間に基づいています。
.NET WebアプリケーションはGuid.NewGuid()を呼び出してGUIDを作成し、GUIDはスタックの数フレーム深いCoCreateGuid() COM関数を呼び出すことになります。
MSDNライブラリから:
CoCreateGuid関数は、RPC関数UuidCreateを呼び出します。この関数は、グローバルに一意の128ビット整数であるGUIDを作成します。分散環境で永続的な識別子として使用する絶対的に一意の番号が必要な場合は、CoCreateGuid関数を使用します。非常に確実に、この関数は一意の値を返します。同じシステムまたは他のシステムで他の呼び出しはありません。 (ネットワーク化されているかどうかに関係なく)、同じ値を返す必要があります。
そして、 UuidCreateのページをチェックすると:
UuidCreate関数は、生成さ れたコンピューターのイーサネット/トークンリングアドレスまで追跡できないUUIDを生成します。また、同じコンピューターで作成された他のUUIDに関連付けることもできません 。
最後の文はあなたの質問への答えです。つまり、Microsoftの実装にバグがない限り、推測するのはかなり難しいと思います。
誰かがGUIDの継続的なストリームでサーバーを攻撃し続けると、他の何よりもサービス拒否攻撃になります。
誰かがGUIDを推測する可能性はほとんどありません。
依存します。GUIDが適切に設定されている場合、たとえば、塩漬けの安全なハッシュを使用していて、ビットが十分にある場合は困難です。GUIDが短く、明白な場合は弱くなります。
サーバーの負荷が発生する可能性があるため、とにかく誰かが10000の新しいセッションを作成するのを阻止するための措置を講じることをお勧めします。