Как хешировать и солить пароли - PullRequest
7 голосов
/ 02 января 2011

Я понимаю, что эта тема иногда поднималась, но я пока не совсем уверена в этой теме.

Что мне интересно, как вы солите хеш и работаете с соленым хешем??Если пароль зашифрован случайно сгенерированной солью, как мы можем проверить его, когда пользователь пытается аутентифицироваться?Нужно ли нам хранить сгенерированный хеш в нашей базе данных?

Есть ли какой-либо конкретный способ, которым желательно генерировать соль?Какой метод шифрования предпочтительнее использовать?Из того, что я слышал, с sha256 все в порядке.

Было бы идеей, чтобы хэш "пересолился" при аутентификации пользователя?И, наконец, есть ли существенное повышение безопасности, чтобы перефразировать его несколько раз?

Спасибо!

Ответы [ 5 ]

7 голосов
/ 02 января 2011

Ответ: не делай этого сам. Однострочник, который будет делать все, что вам нужно в PHP, - это использовать bcrypt.

Прочтите это, это легко понять и объяснить все, что вы просили: http://codahale.com/how-to-safely-store-a-password/

bcrypt сам по себе учитывает хэширование и может быть настроен так, чтобы быть настолько «сложным», насколько это необходимо для поддержания целостности паролей ваших пользователей в случае взлома.

О, и мы не "зашифровываем" пароли, мы их хешируем.

2 голосов
/ 02 января 2011

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

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

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

1 голос
/ 02 января 2011

Что мне интересно, как вы солите хеш и работаете с соленым хешем?Если пароль зашифрован случайно сгенерированной солью, как мы можем проверить его, когда пользователь пытается аутентифицироваться?Нужно ли нам хранить сгенерированный хеш в нашей базе данных?

Да.Сначала вы генерируете соль, затем генерируете хеш из пароля плюс соли и сохраняете и хеш, и соль вместе.

Есть ли какой-либо конкретный способ, которым желательно генерировать соль?

Я сомневаюсь, что есть консенсус по поводу того, что предпочтительнее.Я использую / dev / random.например,

$salt = '$2a$12$' 
    . strtr(substr(base64_encode(shell_exec(
        'dd if=/dev/random bs=16 count=1 2>/dev/null'
        )), 0, 22), '+', '.')
    . '$';
$hash = crypt($input, $salt);

Какой метод шифрования предпочтительнее использовать?Из того, что я слышал, с sha256 все в порядке.

См. Ответ Computer Guru, т.е. используйте bcrypt, как в примере выше.См. Справочную страницу PHP на crypt().Если bcrypt отсутствует в вашей системе, один из способов получить его - патч Suhosin .

Было бы неплохо, чтобы хэш был "повторно засолен", когдапользователь аутентифицируется?

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

И, наконец, является ли это существенным повышением безопасности дляПерефразировать это пару раз?

Этот вопрос принадлежит миру криптографического дизайна.Я рекомендую оставить это экспертам.Другими словами: забудьте об этом - просто используйте лучшие обычные практики.

1 голос
/ 02 января 2011

То, что вы обычно делаете, выглядит примерно так:

salted = HASH(password . key); // DON'T DO IT LIKE THIS 

Где ключ - «соль» - секретный ключ, хранящийся в файлах конфигурации.Таким образом, для взлома пароля вам понадобятся и секретный ключ, и БД, поэтому их лучше хранить в разных местах.

Поскольку схема, которую я показал, недостаточно сильна, лучше использоватьHMAC для этой цели, а не рукописное соление.Такая операция так же проста, как хеш, и PHP поддерживает это.

salted = hash_hmac('sha1',password,key); // <-- this is ok

См. Это: http://php.net/manual/en/function.sha1.php

0 голосов
/ 02 января 2011

Три простых правила. Хорошо, пять:

  1. Самая важная вещь, , если вы хотите, чтобы хранение вашего пароля было безопасным: разрешите надежные паролинапример, не менее 8 символов с различными буквами, цифрами и даже знаками препинания
  2. Разрешить пользователям использовать только надежные пароли.Сделайте процедуру, чтобы проверить длину и диапазон символов и отказаться от слабых паролей.Даже найдите себе базу данных Джона Потрошителя и проверьте ее.
  3. Пытайте пользователей злобно, избивайте их, пока они не выберут хорошие длинные и достаточно случайные пароли.Пароли!Не соль, о которой все рады говорить часами, но сам пароль должен быть достаточно случайным!
  4. Соли ваши пароли и храните эту соль вместе с информацией о пользователе.Вы можете использовать электронную почту и имя пользователя как идеальную соль, не нужно придумывать что-то необычное случайное.
  5. Определенный алгоритм не так важен, вы также можете использовать MD5.В реальном мире очень мало людей, которые потрудились бы взломать пользовательскую базу данных ваших знаменитых форумов сайта Общества любителей рыбалки и бакалеи.
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...