2009-09-09 9 views
7

私のWebアプリケーションはSSL上でしか動作せず、ユーザ名とパスワードで正常にログインした後、各ユーザに対して時間制限されたクッキーを設定します。このシステムの最大の弱点は、既存のユーザーのCookieを侵害することです。そして、2つはセッションID GUIDを推測します。Windows 2003で生成されたGUIDはセッションIDとして安全に使用できますか?

私は最初の弱点のメカニズムを知っていますが、攻撃者が設定したアカウントにログインして取得したGUIDに基づいてセッションID GUIDを推測する可能性について心配する必要があるのでしょうか?アップ?この場合のWebサーバーはWindows 2003で、GUIDは.NET 3.5で生成されています。

答えて

6

GUIDは暗号で保護されたものではなく、一意のものです。フォーマットのかなり多くは予測可能です - 48ビットのMACアドレス、タイムスタンプは、それがどのように生成されているかを知っていれば多少予測可能で、タイムスタンプの衝突に対処するにはもう少しビットです。技術的に洗練された攻撃者は、GUIDをリバースエンジニアリングする可能性が非常に高いです。

安全なセッションキーには、実際にはcryptographically secure PRNGが必要です。

+0

GUID作成アルゴリズムが変更されました。彼らはもはやMACアドレスを使用しません。それらはちょうど128Bitの擬似乱数です。そして彼らには多くのセキュリティ上の問題があります。 –

+0

.net 3.5 guidsにはタイムスタンプではないMACアドレスもありません。 –

+1

ベンダーによって.net 3.5のGUIDが暗号で保護されていると記載されていますか? – ConcernedOfTunbridgeWells

0

.Net 3.5 GUIDは事実上推測することができません。 GUIDの数は膨大である - 宇宙の砂の上に砂粒があるよりも多くのGUIDがあるなど、ユニークであることが厳密に保証されているわけではありません(SQL NEWIDは一意であることが保証されています)。

あなた自身でこれをテストし、数億を生成してから重複を見つける(あなたは何も見つけられません)。

+1

GUIDは擬似乱数ですが、コンピュータは真のランダム値を生成できません。私は彼らが推測するのは簡単だと論じる。次のすべてのGUIDを計算できるという説明を詳しく説明できますか? (例またはソース) –

関連する問題