- PVSM.RU - https://www.pvsm.ru -
Сегодня посмотрим, как лучше всего хранить пароли в базе данных и как известные платформы решают эту задачу.
Когда встал вопрос хранения паролей, конечно, первой идеей было просто записывать их в открытом виде в соответствующей табличке в базе данных. И все бы ничего, если бы доступ к ней действительно напрямую клиенты получить не могли. Но, к сожалению, в различных веб-приложениях по-прежнему иногда работает такая известная всем SQL-инъекция, не говоря уже о других потенциальных уязвимостях. В вопросах безопасности вообще принято предполагать худшее и готовить план действий и защиту даже на такой случай. Будем считать, что злоумышленник нашел в веб-приложении лазейку, тем или иным способом радостно выгружает себе таблицу с именами и паролями пользователей и дальше уже распоряжается ими, как ему вздумается. В общем случае его дальнейшие действия могут быть следующими:
Идея сразу оказывается не такой хорошей. Что делать? Здорово было бы хранить пароли в зашифрованном виде. Тогда, даже если их извлекут, восстановить не смогут или, по крайней мере, потратят на это слишком много времени. Здесь выбор встает между двумя ветками развития: шифровать пароли или хэшировать. Разработчики остановились на втором, и, в принципе, понятно, почему. Сравним наших претендентов по разным характеристикам:
Таким образом, со счетом 3:1 побеждает хэширование. Но можно ли на этом остановиться?
Ответ: нет.
Итак, злоумышленник заполучил нашу таблицу с именами пользователей и паролей. Пароли теперь захэшированы, но это нашего атакующего не останавливает, и он всерьез намерен их восстановить. Его возможные действия:
В самом общем случае злоумышленнику придется брутить пароли. И тут его успех будет зависеть в том числе от быстроты вычисления хэш-функции. Сравнение по времени работы хэшей можно посмотреть здесь [2]. Например, реализованные на Java хэш-функции на 64-битной Windows 10 с 1 core Intel i7 2.60GHz и 16GB RAM были запущены по миллиону раз для вычисления хэша длины в 36 символов. Они показали следующие результаты:
MD5 – 627 мс
SHA-1 – 604 мс
SHA-256 – 739 мс
SHA-512 – 1056 мс
А ведь сегодня брутфорс можно распараллелить и выполнить в разы быстрее на GPU (а также на APU, DSP и FPGA). Однако помимо выбора более долгого алгоритма и более длинного выходного результата можно сделать кое-что еще.
Чтобы помешать нарушителю воспользоваться готовыми радужными таблицами, существует техника хэширования пароля несколько раз. То есть вычисляем хэш от хэша от хэша от хэша… и так n раз (надо, правда, сильно с этим не увлекаться, потому что при обычной проверке пароля пользователя серверу тоже придется это проделывать). Теперь так просто по радужной таблице он пароль не найдет, да и время на брутфорс заметно увеличится. Но ничто не остановит злоумышленника от того, чтобы сгенерировать радужную таблицу по словарю паролей, зная алгоритм хэширования. Тем более, для самых популярных комбинаций этого метода такие таблицы уже сгенерированы:
"
Для того, чтобы и это он не смог сделать, пароли сегодня хэшируются с добавлением соли.
Соль – это дополнительная случайная строка, которая приписывается к паролю и хэшируется вместе с ним. Из полученного таким образом хэша по радужной таблице пароль уже не восстановишь. Зная соль и выходной хэш, злоумышленник обречен на брутфорс и никакие заранее вычисленные таблицы ему, скорее всего, не помогут.
Таксономия соления паролей:
1. По принципу соления:
2. По методу хранения соли:
Будем считать, что индивидуальные соли пользователей хранятся в базе, глобальная соль в конфиге. Злоумышленник получил доступ к базе, и ему известны все хэши и соответствующие им соли (глобальная соль хранится не в базе, и ее он не знает). Итого, если объединить все способы, то для того, чтобы получить пароли в открытом виде, как было в первых системах, он, будучи крайне целеустремленным, столкнется со следующими препятствиями:
До версий 3.х пароли просто хэшировались с помощью MD5. Сейчас используется библиотека phpass. По умолчанию к паролю спереди приписывается соль и полученная строка хэшируется MD5 2^8 раз.
До версии 1.0.12 использовался просто MD5. Используется библиотека phpass, по умолчанию bcrypt с солью и 2^10 повторениями.
До версии 6 md5 без соли. Используется библиотека phpass. По умолчанию соленый sha512 с 2^16 повторениями.
Использует соленый Blowfish c 2^10 повторениями.
Использует HMACSHA256 с солью. Использует вторую, глобальную соль, задаваемую в конфиге.
Автор: Acribia
Источник [3]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/cms/281849
Ссылки в тексте:
[1] здесь: https://cmd5.ru/
[2] здесь: http://bench.cr.yp.to/ebash.html
[3] Источник: https://habr.com/post/413157/?utm_campaign=413157
Нажмите здесь для печати.