56

この質問はかなり人気があるので、更新すると便利だと思いました。

この質問に対する AviDの正しい答えを強調させてください。

暗号化が必要なデータを Cookie に保存しないでください。代わりに、適切なサイズ (128 ビット/16 バイト) のランダム キーを Cookie に格納し、Cookie のキーによって識別される、サーバー上で安全に保ちたい情報を格納します。


Cookie を暗号化するための「最適な」暗号化アルゴリズムに関する情報を探しています。

次の要件があります。


  • データの暗号化と復号化は、（ほぼ）すべてのリクエストに対して高速である必要があります

  • 小さなデータセット、通常は約 100 文字以下の文字列で動作します。

  • 安全でなければなりませんが、銀行取引を保護しているわけではありません

  • SHA1などが出ないように、情報を解読できる必要があります。

ここで、Blowfish が高速で安全であることを読み、AES が高速で安全であることを読みました。ふぐの方がブロックサイズが小さい。

どちらのアルゴリズムも十分以上のセキュリティを提供すると思いますか? したがって、速度が決定的な要因になります。しかし、それらのアルゴリズムが小さな文字列に適しているかどうか、また Cookie の暗号化により適したアルゴリズムがあるかどうかはわかりません。

私の質問は、
Cookie データの暗号化に最適な暗号化アルゴリズムは何ですか?

更新
より正確に言うと、2 つの Cookie を暗号化する必要があります。1 つはセッション情報を含み、もう 1 つは「remeber me」情報を含みます。

プラットフォームは、VPS 上の Linux 上の apache モジュールとしての PHP です。

更新 2 Cookie に情報を保存することは安全ではないというcletus
に同意します。

ただし、「remeber me」機能を実装する必要があります。これについて受け入れられている方法は、Cookie を設定することです。クライアントがこの Cookie を提示すると、有効なユーザー名とパスワードの組み合わせを提示したかのように (ほぼ) 同等の権利でシステムにアクセスできます。

したがって、少なくとも Cookie 内のすべてのデータを暗号化して、a
)悪意のあるユーザーが内容を読み取れないようにする必要があります
。b)悪意のあるユーザーが独自の Cookie を作成したり、改ざんしたりできないようにします。

(Cookie からのすべてのデータは、何かを行う前にサニタイズされ、有効性がチェックされますが、それは別の話です)

セッション Cookie には、sessionId/timestamp だけが含まれています。おそらく暗号化なしで使用できますが、暗号化しても問題はないと思いますか? (計算時間以外)。

データを Cookie に保存する必要がある場合、それを暗号化する最善の方法は何でしょうか?

更新 3
この質問への回答により、選択したアプローチを再考することができました。実際、暗号化を必要とせずに同じことができます。データを暗号化する代わりに、コンテキストがなければ意味がなく、推測できないデータのみを送信する必要があります。

しかし、私は途方に暮れています:
暗号化により、BigBadWorld™ にデータを送信できるようになり、それでも (かなり) 誰もそれを読み取ったり、改ざんしたりできないことを確信できると思いました
...暗号化のポイント？

しかし、以下の反応は次の方向に進んでいます。セキュリティを達成するために暗号化を信頼しないでください。

私は何が欠けていますか??

4

13 に答える 13

9

セキュリティ警告: これら 2 つの機能は安全ではありません。彼らはECB モードを使用しており、暗号文の認証に失敗しています。より良い方法については、この回答を参照してください。

このメソッドを PHP スクリプトで使用したいと考えている人向けです。これは、256 ビットの Rijndael (AES ではない) を使用した実際の例です。

function encrypt($text, $salt) 
{ 
    return trim(base64_encode(mcrypt_encrypt(MCRYPT_RIJNDAEL_256, $salt, $text, MCRYPT_MODE_ECB, mcrypt_create_iv(mcrypt_get_iv_size(MCRYPT_RIJNDAEL_256, MCRYPT_MODE_ECB), MCRYPT_RAND)))); 
} 

function decrypt($text, $salt) 
{ 
    return trim(mcrypt_decrypt(MCRYPT_RIJNDAEL_256, $salt, base64_decode($text), MCRYPT_MODE_ECB, mcrypt_create_iv(mcrypt_get_iv_size(MCRYPT_RIJNDAEL_256, MCRYPT_MODE_ECB), MCRYPT_RAND))); 
}

次に、Cookieを保存します

setcookie("PHPSESSION", encrypt('thecookiedata', 'longsecretsalt'));

そして次のページを読む：

$data = decrypt($_COOKIE['PHPSESSION'], 'longsecretsalt');
于 2010-10-25T15:46:30.973 に答える
4

AES を EAX モードで使用することで、目的を安全に達成できます。暗号文は平文より大きくなります。これは安全な暗号化では正常です。

もちろん、攻撃者は暗号文から平文の長さを知っていますが、それ以外は特定できないはずです。

AES キーをランダムに生成します。

必ず暗号化ごとに新しいナンスを使用し、「関連付けられたデータ」フィールドを使用して、ある目的のために暗号化したものが別の目的であると表示されないようにします (そのため、ユーザー名や Cookie 名などが入る可能性があります)。そこの）

セキュリティを達成するために暗号化を信頼しないでください。

さらに、「暗号化の専門家でなければ、間違いを犯しやすいことを過小評価するでしょう」. たとえば、AFAICT は、このスレッドの他の誰もチェーン モードやメッセージの整合性について議論していません。これは、2 つの一般的な初心者の間違いをカバーしています。

于 2009-09-23T12:32:09.480 に答える
1

Cookie を暗号化する理由を教えてください。

私が見ているように、クライアントに鍵を与えるか、与えないかの 2 つのケースがあります。

クライアントにキーを提供しない場合、なぜデータを提供するのでしょうか? 弱い暗号化を破って奇妙なゲームをプレイしている場合を除き（明示的にそうではありません）、データをサーバーに保存することもできます。

クライアントにキーを渡す場合、そもそもなぜそれを暗号化するのでしょうか? キーの通信を暗号化しない場合、Cookie の暗号化は意味がありません。MITM は Cookie を見て、必要な Cookie を送信できます。クライアントへの暗号化されたチャネルを使用する場合、保存されたデータを暗号化するために余分なオーバーヘッドが発生するのはなぜですか?

クライアントのマシンの他のユーザーが Cookie を読み取るのが心配な場合は、あきらめて、ブラウザが適切な許可ビットを設定していると仮定してください :)

于 2009-03-03T14:20:44.217 に答える
1

Cookie を暗号化した場合、サーバーはそれを読み取るために (同じキーを確認するために) デコードする必要があります。したがって、暗号化された Cookie は無意味です。 . まったく暗号化されていないのと同じくらい安全ではありません。

誰かがあなたの Cookie を盗むという本当の問題は、サーバーとクライアントの間の接続にあると思います。ホストが提供する SSL 接続を使用します。

Cookie については、データベース内のユーザーごとに長いランダム ID を作成し (ログオンするたびに変更する)、それを Cookie またはセッションとして設定する必要があります。キーを含む Cookie は php で確認でき、それがデータベース内のアカウントまたはテーブルと等しい場合は、通常どおり Web ページにデータをダンプします。

于 2009-10-12T14:43:26.513 に答える
0

さらに、私は を試しましたがmcrypt_encrypt、1 つのことを心に留めておいてください。もしそうならbase64_encode(mcrypt_encrypt(...))。

その後base64_decode 、暗号化されたデータを実行して出力します ( echo)。あなたはおそらく何も見えずにうんざりしているでしょう。ただし、そうする場合 mcrypt_decrypt( ... base64_decode($value) )。元のデータが表示されます。

于 2011-03-14T18:09:15.637 に答える
0

ユーザー名とパスワードに関して暗号化されていても、データを「譲渡」するのは良くないと思います...それを盗聴できるJSはたくさんあります...ユーザーDBテーブルにフィールドcookie_authなどを作成することをお勧めします.. .

最初のログイン後、収集: 現在: ブラウザ、IP、いくつかの独自のソルト キー、およびホスト名変数 ...

ハッシュを作成してそのフィールドに保存します... Cookieを設定します... Cookieが「応答」すると、これらすべてを保存されたハッシュと比較して完了します...

誰かがクッキーを「盗んだ」としても、それを使用することはできません:-)

お役に立てれば ：-）

fehavision.to

于 2010-01-18T17:43:54.233 に答える