Безопасный хэш и соль для паролей PHP - PullRequest
Новая
       229

Безопасный хэш и соль для паролей PHP

1119 голосов
/ 31 декабря 2008

В настоящее время говорят, что MD5 частично небезопасен. Учитывая это, я хотел бы знать, какой механизм использовать для защиты паролем.

Этот вопрос, Является ли «двойное хеширование» паролем менее безопасным, чем одноразовое хеширование? предполагает, что хэширование несколько раз может быть хорошей идеей, тогда как Как реализовать защиту паролем для отдельных файлов? предлагает использовать соль.

Я использую PHP. Я хочу безопасную и быструю систему шифрования паролей. Хэширование пароля в миллион раз может быть безопаснее, но и медленнее. Как добиться хорошего баланса между скоростью и безопасностью? Кроме того, я бы предпочел, чтобы результат имел постоянное количество символов.

  1. Механизм хеширования должен быть доступен на PHP
  2. Должно быть безопасно
  3. Может использоваться соль (в этом случае все соли одинаково хороши? Есть ли способ получить хорошие соли?)

Кроме того, мне следует хранить два поля в базе данных (например, одно с использованием MD5, а другое с использованием SHA)? Будет ли это сделать это безопаснее или небезопаснее?

В случае, если я не был достаточно ясен, я хочу знать, какую функцию (ы) хеширования использовать и как выбрать хорошую соль для обеспечения безопасного и быстрого механизма защиты паролем.

Похожие вопросы, которые не совсем охватывают мой вопрос:

В чем разница между SHA и MD5 в PHP
Простое шифрование пароля
Безопасные методы хранения ключей, паролей для asp.net
Как бы вы внедрили соленые пароли в Tomcat 5.5

Ответы [ 14 ]

7 голосов
/ 31 декабря 2008

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

6 голосов
/ 31 декабря 2008

Я обычно использую SHA1 и соль с идентификатором пользователя (или другой информацией, специфичной для пользователя), а иногда я дополнительно использую постоянную соль (поэтому у меня есть 2 части к соли).

SHA1 теперь также считается несколько скомпрометированным, но в гораздо меньшей степени, чем MD5. Используя соль (любую соль), вы предотвращаете использование универсального радужного стола для атаки на ваши хеши (некоторые люди даже добились успеха, используя Google как своего рода радужную таблицу, выполнив поиск хеша ). Злоумышленник может сгенерировать радужную таблицу, используя вашу соль, поэтому вы должны добавить соль, специфичную для пользователя. Таким образом, им придется создавать радужную таблицу для каждой записи в вашей системе, а не только для всей вашей системы! При таком типе посола даже MD5 достаточно безопасен.

4 голосов
/ 31 декабря 2008

SHA1 и соли должно хватить (в зависимости, естественно, от того, что вы кодируете что-то для Fort Knox или систему входа в список покупок) в обозримом будущем. Если SHA1 недостаточно хорош для вас, используйте SHA256 .

Идея соли состоит в том, чтобы вывести из равновесия результаты хеширования. Например, известно, что MD5-хэш пустой строки равен d41d8cd98f00b204e9800998ecf8427e. Итак, если кто-то с достаточно хорошей памятью увидит этот хэш и узнает, что это хэш пустой строки. Но если строка соленая (скажем, со строкой «MY_PERSONAL_SALT»), хеш для «пустой строки» (т. Е. «MY_PERSONAL_SALT») становится aeac2612626724592271634fb14d3ea6, следовательно, для обратного отслеживания неочевиден. То, что я пытаюсь сказать, что лучше использовать любую соль, чем не делать этого. Поэтому не так уж важно знать какую соль использовать.

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

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

0 голосов
/ 08 октября 2015

ки в фиты нам нужна соль соль должна быть уникальной так что давайте его сгенерируем 

   /**
     * Generating string
     * @param $size
     * @return string
     */
    function Uniwur_string($size){
        $text = md5(uniqid(rand(), TRUE));
        RETURN substr($text, 0, $size);
    }

также нам нужен хеш Я использую sha512 это лучший и это в php 

   /**
     * Hashing string
     * @param $string
     * @return string
     */
    function hash($string){
        return hash('sha512', $string);
    }

так что теперь мы можем использовать эти функции для генерации безопасного пароля 

// generating unique password
$password = Uniwur_string(20); // or you can add manual password
// generating 32 character salt
$salt = Uniwur_string(32);
// now we can manipulate this informations

// hashin salt for safe
$hash_salt = hash($salt);
// hashing password
$hash_psw = hash($password.$hash_salt);

теперь нам нужно сохранить в базе данных нашу переменную $ hash_psw и переменную $ salt

и для авторизации мы будем использовать те же шаги ...

это лучший способ защитить пароли наших клиентов ...

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

Страница:
...