4

セッションハッシュに使用する適切なアルゴリズムを選択する場合、サイズは重要ですか。

最近この記事を読みましたが、ワールプールを使用してセッションIDのハッシュを作成することを提案しました。Whirlpoolは128文字のハッシュ文字列を生成しますが、これは大きすぎますか？

計画は、セッションハッシュをデータベースに保存することです。64文字のフィールド（sha256）、96文字のフィールド（sha384）、または128文字のフィールド（ワールプール）を使用することには、大きな違いがありますか？ワールプールについてなされた最初の議論の1つは、速度と他のアルゴリズムでしたが、速度の結果を見ると、sha384はそれほど悪くはありません。

ハッシュを切り捨てて128文字より小さくするオプションがあります。

必要に応じてアルゴリズムを変更できるように、元のコードスニペットを変更しました。

更新：文字列がハッシュされることについていくつかの議論があったので、コードを含めました。


function generateUniqueId($maxLength = null) {
    $entropy = '';

    // try ssl first
    if (function_exists('openssl_random_pseudo_bytes')) {
        $entropy = openssl_random_pseudo_bytes(64, $strong);
        // skip ssl since it wasn't using the strong algo
        if($strong !== true) {
            $entropy = '';
        }
    }

    // add some basic mt_rand/uniqid combo
    $entropy .= uniqid(mt_rand(), true);

    // try to read from the windows RNG
    if (class_exists('COM')) {
        try {
            $com = new COM('CAPICOM.Utilities.1');
            $entropy .= base64_decode($com->GetRandom(64, 0));
        } catch (Exception $ex) {
        }
    }

    // try to read from the unix RNG
    if (is_readable('/dev/urandom')) {
        $h = fopen('/dev/urandom', 'rb');
        $entropy .= fread($h, 64);
        fclose($h);
    }

    // create hash
    $hash = hash('whirlpool', $entropy);
    // truncate hash if max length imposed
    if ($maxLength) {
        return substr($hash, 0, $maxLength);
    }
    return $hash;
}
4

4 に答える 4

3

ハッシュの作成にかかる時間は重要ではありません。データベースに適切なインデックスが付けられている限り、ストレージの方法も大きな要因にはなりません。

ただし、ハッシュはクライアントの要求とと​​もに毎回、頻繁にCookieとして送信する必要があります。大きなCookieは、各リクエストに少し時間を追加する可能性があります。詳細については、 Yahoo！のページパフォーマンスのベストプラクティスを参照してください。小さいCookie、つまり小さいハッシュには利点があります。

全体として、大きなハッシュ関数はおそらく正当化されません。スコープが限られているため、古き良きmd5とsha1は、セッショントークンの背後にあるソースとしてはおそらく問題ありません。

于 2010-06-22T00:44:54.873 に答える
2

はい、サイズが重要です。

短すぎると、衝突の危険があります。また、攻撃者がブルートフォース攻撃によって他の誰かのセッションを見つけることを実用的にします。

長すぎることはそれほど重要ではありませんが、セッションIDのすべてのバイトは、リクエストごとにブラウザーからサーバーに転送される必要があるため、本当に最適化する場合は、長すぎるIDは必要ない場合があります。

ただし、ハッシュアルゴリズムのすべてのビットを使用する必要はありません。ただし、Whirlpoolのようなものを使用することを妨げるものはなく、最初の128ビット（16進数で32文字）のみを使用します。実際には、128ビットも長さの適切な下限です。

しかし、エリクソンが指摘しているように、ハッシュを使用するのは少し奇妙です。少なくとも使用しているIDの長さと同じくらいのエントロピーが入力にない限り、ハッシュへの入力を推測する攻撃に対して脆弱です。

于 2010-06-22T09:56:00.803 に答える
1

記事を読み込もうとするとタイムアウトになりますが、セッション識別子としてハッシュを使用する正当な理由は考えられません。セッション識別子は予測できないものにする必要があります。記事のタイトルを考えると、著者はその原則を認めているようです。次に、暗号化乱数ジェネレーターを使用してセッションIDを生成してみませんか？

ハッシュは入力を受け取り、その入力が予測可能である場合、ハッシュも予測可能であり、それは悪いことです。

于 2010-06-22T00:51:29.627 に答える
0

SHA1またはMD5はおそらくあなたのニーズに十分です。実際には、衝突の可能性は非常に小さいため、発生することはほとんどありません。

ただし、最終的には、必要なセキュリティレベルによって異なります。また、ハッシュが長いほど計算コストが高くなり、より多くのストレージスペースが必要になることにも注意してください。

于 2010-06-22T00:42:34.263 に答える