7

サーバー上のどこかにではなく、暗号化された Cookie にセッション データを保存するように切り替えることを考えています。これにより、各リクエストで使用される帯域幅が増えますが、データベース サーバーの負荷とストレージ スペースが余分に節約されます。

とにかく、RIJNDAEL 256 を使用して Cookie の内容を暗号化する予定です。

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

使用すると、次のようなものが生成されます（表示用にエンコードされたbase64）

print base64_encode(encrypt('text', 'key'));

7s6RyMaYd4yAibXZJ3C8EuBtB4F0qfJ31xu1tXm8Xvw=

1 人のユーザーの Cookie が危険にさらされることは心配していませんが、攻撃者は私がデータに署名するために何を使用しているかを知っているため、攻撃者が を発見し、任意のユーザーの任意のセッションkeyを構築できるのではないかと心配しています。

使用されたパラメータに関連して推定クラッキング時間を検証する方法はありますか? または、使用されるテキストまたはキーのサイズに関連する時間の標準的な尺度はありますか?

RIJNDAEL で安全に使用するには、キー自体が 256 ビットを超える必要があると誰かが言っているのを聞きました。キーを渡さないように、暗号化されたテキストの長さを特定の長さにする必要があるかどうかも疑問に思っています。

通常、データは約 200 文字になります。

a:3{s:7:"user_id";i:345;s:5:"token";s:32:"0c4a14547ad221a5d877c2509b887ee6";s:4:"lang";s:2:"en";}

それでこれは安全ですか？

4

5 に答える 5

17

はい、Rijndael(AES) は安全ですが、実装は安全とは言えません。実装には 2 つの未解決の問題があります。ECB モードと IV の使用は、すべてのメッセージに使用される静的変数です。 IV は常に Cryptographic Nonce でなければなりません。あなたのコードは明らかに CWE-329 に違反しています。

ECB モードは使用しないでください。CBC モードを使用する必要があります。その理由は次のとおりです。

オリジナル：

代替テキスト

ECB モードで暗号化:

代替テキスト

CBC モードを使用して暗号化:

代替テキスト

于 2010-10-31T04:09:38.727 に答える
3

ECB の使用は避けてください。暗号化されたものに関する情報を明らかにすることができます。同じ平文を持つ 2 つのブロックは、同じ暗号文を持ちます。CBC はこれを回避しますが、IV を生成または保存する必要があります。

キーと IV を単純に保存することは避けてください。暗号的に強力な乱数ジェネレーターを使用して 256 ビットのマスター キーを生成し、それをアプリケーションの安全な場所に保存します。これを使用して、暗号化に使用するセッション キーを生成します。IV は、セッション キーから取得できます。セッション キーを生成するときは、セッション キーの範囲を狭めるために使用できるすべての利用可能なデータを含めます。(たとえば、スコープに Cookie、リモート ホスト アドレス、暗号化されたデータと共に保存されたランダムな通知、および/または暗号化されたデータ内にない場合はユーザー ID を含めます)

データの使用方法によっては、MAC を含める必要がある場合があります。ECB と CBC は、暗号文の変更を検出するように設計されていないため、そのような変更は平文のゴミになります。暗号化されたデータに HMAC を含めて、それを正統と見なす前に認証できるようにすることをお勧めします。セッション HMAC キーは、セッション暗号化キーから派生する必要があります。または、PCBC モードを使用することもできます。PCBC は暗号文の変更を検出するために作成されましたが、その機能はパディングのサイズによって制限され、魔法は暗号化されたデータに依存しており、すべての暗号 API がオプションとしてそれを持っているわけではありません。

MAC を含めるところまで行ったら、リプレイ攻撃に対する対策を講じることを検討する必要があります。セッションの範囲内で誰かが古いデータを再送信できる場合はいつでも、リプレイ アタックの可能性があります。ユーザーに問題を起こさずにセッション キーの使用をできるだけ狭くすることは、リプレイ攻撃を阻止する 1 つの方法です。もう 1 つの方法は、暗号化されたデータに日付と時刻を含めて、データが有効であると見なされる期間を作成することです。

要約すると、キーを保護することは氷山の一角にすぎません。

于 2010-10-30T22:04:31.497 に答える
3

長い鍵を使えば、その鍵はかなり安全だったと思います。気になる点は次のとおりです。

データ ストレージをクライアントにオフロードしています。クライアントを決して信頼しないでください。これは、これを行うことができないという意味ではなく、Cookie 内のデータを信頼できないものとして扱う (それに基づいてユーザーに表示する「テーマ」よりも深刻な決定を下さない) か、提供する必要があるということです。データを検証する方法。

データを検証する方法の例を次に示します。

  • ソルトを含める（同じセッションデータを持つ人々が同じCookieを取得しないようにするため）および
  • チェックサム (Cookie を 1 ビットでも変更すると役に立たなくなるため)。
于 2010-10-31T02:22:22.620 に答える
2

Rijndael は AES に改名されました。はい、安全に使用できます。

とはいえ、クッキーに何を入れるかは慎重に検討する必要があります。システムのストレージの方法で何が利用できるかによって異なりますが、単純に乱数 (たとえば 64 ビットの数値) を選択して、それを Cookie に保存することができます。サーバー側のシステムでは、その番号が誰に関連付けられているか、およびその他の詳細を記録します。これにより、暗号化が完全に回避されます。他の詳細を使用して、最初に送信したブラウザーから Cookie が返されたかどうかを検証します (検証できる範囲で)。

または、セッションごとに異なる暗号化キーを使用して、どのキーがどのセッションで使用されたかを追跡することもできます。

固定キーを使用した単純な暗号化を使用する場合でも、暗号化するデータに乱数を含めることを検討してください。これにより、定義上、乱数を知ることができないため、既知の平文攻撃を使用してクラックすることが難しくなります.

于 2010-10-30T19:46:04.423 に答える
0

キーがランダムに選択される場合、AES-128 で十分であり、より長いキーを使用する必要はありません。

ただし、他にも問題があります。1 つ目は、ECB を使用しないことです。ECB では、平文の特定の 128 ビット ブロックは、キーが同じ場合、常に同じ 128 ビット暗号文にマップされます。これは、敵対者が、対応する暗号文を知っているさまざまなブロックを挿入して、暗号文を外科的に変更できることを意味します。たとえば、2 人の異なるユーザーのデータを混在させることができます。他のモードでは、たとえばCBCは問題ありません。暗号文は、アルゴリズムの実行ごとに異なるIV（初期化ベクトル）にも依存します。このように、同じ平文が毎回異なる方法で暗号化され、敵は何の利点も得ることができません。また、IV を暗号文とともにどこかに保存する必要があります。保護する必要はありません。同じ IV を再利用する可能性が無視できなくなるたびに、キーも変更する必要があります。

2 つ目の問題は、メッセージ認証コードも追加する必要があることです。そうしないと、偽造された Cookie と適切な Cookie を区別できなくなります。

于 2010-10-30T22:05:54.803 に答える