Хеширование паролей: как обеспечить безопасность базы данных.

  • Home
  • Хеширование паролей: как обеспечить безопасность базы данных.
Хеширование паролей: как обеспечить безопасность базы данных.

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

Рабочий процесс веб-сайтов, использующих хеширование, обычно выглядит следующим образом:

  1. Пользователь создаёт учётную запись.
  2. Пароль хешируется и сохраняется в базе данных.
  3. Когда пользователь пытается войти в систему, хеш введённого пароля сравнивается с хешем, хранящимся в базе данных.
  4. Если хеши совпадают, пользователь может получить доступ к учётной записи.
  5. В противном случае отправляется общее сообщение об ошибке, например, «Введены неверные учётные данные», чтобы хакеры не смогли отследить ошибку до имени пользователя или пароля.
hash("привет") = 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824  hash("привет") =3937f988aeb57b6fd75b9c71bf17b9658ec97823ba b613df438389b0c896b724  хеш («Дэнни») =668e2b73ac556a2f051304702da290160b29bad3392ddcc72074fefbee80c55a

ПРИМЕЧАНИЕ.Для хеширования пароля можно использовать только безопасные или криптографические хеш-функции (SHA256, SHA512, RipeMD, WHIRLPOOL и т. д.).

К сожалению, простое криптографическое хеширование паролей не обеспечивает безопасности.

Взлом хеш-функции

Самый простой способ расшифровать хеш-функцию — это просто угадать пароль, хешировать его и сравнить с хешем настоящего пароля, который вы пытаетесь угадать. 

Выбор перебирает все возможные комбинации символов.Хотя в конечном итоге возможно 100% взломать любой заданный пароль, этот метод сложен в использовании из-за высокой вычислительной стоимости.Взлом некоторых паролей, даже довольно коротких, может занять (буквально) тысячи лет методом полного перебора.

Попытка aaa: не удалось Попытка aab: не удалось Попытка aac: не удалось
...
Попытка acb: не удалось Попытка acc: успешно!

Атаки по словарю используют файл, содержащий часто используемые слова, фразы или пароли, которые, вероятно, являются используемым паролем.Существуют даже базы данных, содержащие около 100 000 (или около того) наиболее часто используемых паролей.В ходе атаки эти пароли хэшируются и сравниваются с хэшем взломанного пароля.Этот метод, безусловно, быстрее, чем атака полным перебором.

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

В следующем разделе мы рассмотрим «соль», которая делает невозможным стопроцентное использование этих методов взлома.

Соль

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

хеш("hello") = 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824
хеш("hello" + "jHjdbJShdiodb") = 6f7f167a978166ee23b32c9531ce5dc23ae8fc26e412045858d938d11470831f

Если пароль пользователя — qwerty, мы получим следующий хеш: d8578edf8458ce06fbc5bb76a58c5ca4.Если злоумышленник получит доступ к нашей базе данных, для подбора паролей он может воспользоваться готовыми сервисами, у которых уже есть значения, выдающие этот хеш, или подобрать их самостоятельно.

Для защиты от уже готовых хеш-таблиц со значениями можно использовать статическую соль:

       $password = md5($password . "MyUniqueSault");

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

 $sault = GenerateRandomString();       $password = md5($password . $sault);

Теперь, помимо хеша логина/пароля, в базе данных необходимо хранить значение сгенерированной соли для каждого пользователя.Рассмотрим пример: у нас есть два пользователя: user1 и user2.Оба используют пароль qwerty. Но первый сгенерировал соль zxcv , а второй asdf.В результате у пользователей с одинаковым паролем будут разные хэши: 1d8f3272b013387bbebcbedb4758586d и a192862aa3bf46dffb57b12bdcc4c199.Что это даёт: теперь невозможно будет сгенерировать одну хэш-таблицу для нахождения значения hex, динамическую соль придётся генерировать заново.

Что следует и чего не следует использовать для соли

Не рекомендуется:

  • Использовать одну и ту же соль для каждого хеша пароля
  • Использовать короткие соли
  • Использовать странные двойные хеши (например, hash(hash(hash(‘mypass’)))) в соли

Рекомендуется:

  • Генерация случайных солей с помощью криптографически стойкого генератора псевдослучайных чисел (CSPRNG)
  • Генерация новой случайной уникальной соли для КАЖДОГО хеша пароля
  • Генерация ДЛИННЫХ солей

Добавить комментарий