Хэш сессии имеет значение? - PullRequest
4 голосов
/ 22 июня 2010

Имеет ли значение размер при выборе правильного алгоритма для использования в хеше сеанса.

Я недавно прочитал эту статью , и она предложила использовать Whirlpool для создания хэша для идентификатора сеанса.Whirlpool генерирует хэш-строку длиной 128 символов, это слишком велико?

Планируется сохранить хэш сессии в БД.Есть ли большая разница между использованием 64-символьного поля (sha256), 96-символьного поля (sha384) или 128-символьного поля (джакузи)?Одним из первоначальных аргументов в пользу водоворота была скорость по сравнению с другими алгоритмами, но, глядя на результаты скорости, 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 ]

3 голосов
/ 22 июня 2010

Время, необходимое для создания хэша, не имеет значения, и, пока ваша база данных правильно проиндексирована, метод хранения также не должен быть основным фактором.

Однако, хэш должен передаваться сзапрос клиента каждый раз, часто в виде куки.Большие куки могут добавить небольшое количество дополнительного времени к каждому запросу.См. рекомендации по производительности страницы Yahoo! для получения дополнительной информации.Меньшие куки, то есть меньший хэш, имеют свои преимущества.

В целом, большие хэш-функции, вероятно, не оправданы.Из-за ограниченной области видимости старые добрые md5 и sha1, вероятно, подойдут в качестве источника для токена сеанса.

2 голосов
/ 22 июня 2010

Да, размер имеет значение.

Если оно слишком короткое, вы рискуете столкнуться. Вы также делаете так, чтобы злоумышленник мог найти чей-то сеанс с помощью атаки грубой силы.

Быть слишком длинным значит меньше, но каждый байт идентификатора сеанса должен передаваться из браузера на сервер при каждом запросе, поэтому, если вы действительно оптимизируете вещи, вам может не понадобиться слишком длинный идентификатор.

Вам не нужно использовать все биты алгоритма хеширования - ничто не мешает вам использовать что-то вроде Whirlpool, а затем брать только первые 128 бит (32 символа в шестнадцатеричном формате). Практически говоря, 128 бит - это тоже хорошая нижняя граница длины.

Однако, как указывает Эриксон, использование хэша немного странно. Если у вас не меньше энтропии, чем длина входящего идентификатора, который вы используете, вы уязвимы для атак, которые предполагают ввод вашего хэша.

1 голос
/ 22 июня 2010

Статья истекает, когда я пытаюсь ее прочитать, но я не могу придумать вескую причину использовать хэш в качестве идентификатора сеанса Идентификаторы сеанса должны быть непредсказуемыми; учитывая название статьи, похоже, что авторы признают этот принцип. Тогда почему бы не использовать криптографический генератор случайных чисел для создания идентификаторов сеансов?

Хеш принимает входные данные, и если этот ввод предсказуемый, то же самое относится и к хешу, и это плохо.

0 голосов
/ 22 июня 2010

SHA1 или MD5, вероятно, достаточно для ваших нужд.На практике вероятность столкновения настолько мала, что его, скорее всего, никогда не произойдет.

В конечном счете, все зависит от необходимого уровня безопасности.Также имейте в виду, что более длинные хэши более дороги для вычисления и требуют больше места для хранения.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...