1

基本的に、私が望んでいるのは、技術的に推測できるログインCookieの代わりに使用することです（これに対抗する方法はありますが、脅威を完全に排除しないのはなぜですか）。

私が考えているのは、ユーザーがCookieを使用せずに、/ login / email@example.com/myPasswordなどのURLをたどることによって自動ログインできるようにする、公共のコンピューターでの使用禁止の警告が大きいシステムです。

私が聞きたいのは、そのようなシステムをわざわざ作成する必要があるのか​​、それともさらにセキュリティ上の欠陥を作るのかということです。一方では、たとえばIPまたはユーザーエージェントが一致しない場合、Cookieベースのパスワードを再度要求するだけで済みます。他方では、Cookie名を保存する必要がないため、DBスペースを大幅に節約できます。。

4

2 に答える 2

4

あなたのアプローチでは、ユーザーのパスワードが公開されています。ブラウザーの履歴、サーバー ログ、ネットワーク スニッフィング ツールなどです。ユーザーのパスワードを URL に含めないでください。いいえ、それは良い考えではありません。

于 2012-06-26T08:28:38.200 に答える
2

私はSimeonに同意しますが、いくつかの追加事項を指摘したいだけです:

  • Cookieはハイジャックされる可能性がありますが、SSL のようなものは、妥当な範囲でこれを防ぐのに適しています。
  • SSL を使用している場合、両方のアプローチ (ユーザーと Cookie) が盗聴者から隠されます。
  • Simeon が指摘しているように、要求された URL は、たまたま Cookie よりも多くの場所に保存されているため、偶発的な侵害や意図的な侵害が発生する可能性が高くなります。
  • ただし、もう少し重要なことは、Cookie はランダムに生成された文字列であり、あなたのサイトとあなたのサイトだけに固有のものであり、平文のパスワードははるかに価値があるということです. あなたのサイトへの平文のパスワードは、他の何百ものサイトで使用されているパスワードと同じかもしれません。つまり、侵害された Cookie は、1 つのサイトに最大の影響を及ぼします。一方、侵害されたパスワードは、より広範な影響を与える可能性があります。
  • お察しのとおり、PHP セッション ID は通常のパスワードよりもはるかに長くなっています。通常、PHP は 27 ～ 40 文字のセッション ID を生成します。これは、平均的なパスワードの 4 倍以上のサイズです。さらに、パスワードは、(改変された) 辞書攻撃などによって、検索空間全体に対するブルート フォース検索よりもわずかな時間で発見できることがよくあります。つまり、平文のパスワードを推測することは、Cookie の内容を推測するよりもはるかに簡単です。Cookie のセキュリティが心配な場合は、長さを増やし、サーバー側のロジックを含めて、同じ /24 内のクライアントからの Cookie のみを受け入れるようにします。アドレス空間。それでも心配な場合は、より頻繁にユーザーに再認証を強制してください。
于 2012-06-26T08:44:22.933 に答える