Как сохранить пароль в базе данных?

Большинство веб приложений требуют от своих пользователей аутентификации, запрашивая имя пользователя и пароль. Они сравнивают предоставленные пользователем учетные данные с данными, хранящимися в их базе данных для брута, и, если учетные данные совпадают, пользователю предоставляется доступ. Звучит хорошо! Но что произойдет, если база данных, в которой веб-сайт хранит ваши пароли, будет взломана?
В этой статье рассматриваются различные методы хранения паролей в базе данных.
 

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

Ну, многие должны задаваться вопросом, что, если база данных подвергается хакерской атаке, что можно сделать? Хакер имеет доступ ко всей информации. НЕПРАВИЛЬНО!! Существует много способов, с помощью которых процесс извлечения пароля из базы данных может быть затруднен для хакера. Даже в этом случае разработчики склонны игнорировать основные рекомендации и хранить пароли в виде простого текста. Более 30% веб-сайтов хранят ваши пароли в виде простого текста (включая некоторые известные сайты). Если веб-сайт хранит ваш пароль в виде простого текста, то независимо от того, какой пароль вы выберете, вы не в безопасности!
 

Хранение паролей в виде простого текста в базе данных является грехом.


Можно также подумать, что если не текст, то мы должны зашифровать пароль и затем сохранить. Это тоже ужасная идея. Функции шифрования обеспечивают однозначное отображение между входом и выходом, и они всегда обратимы. Если хакер получит ключ, он сможет расшифровать пароли. Лучшим способом было бы использовать одностороннюю криптографическую хеш-функцию. Хэш-функция обеспечивает отображение «один-один» между входом и выходом, и практически невозможно инвертировать выход. Хорошая криптографическая хеш-функция имеет меньшее количество коллизий (т. Е. Для разных входных значений функции сложно получить один и тот же выход). Столкновения невозможно полностью избежать из-за принципа «голубиных отверстий». Для хэширования паролей мы можем предположить, что хеш-функция будет генерировать уникальный вывод, т. Е. Для двух разных паролей мы не получим одинаковое хеш-значение.
 

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

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

Хакеры - умные ребята, и как только они узнали, что разработчики хранят хешированные пароли, они предварительно вычислили хеш большого количества слов (из списка популярных слов или словарных слов). Они создали таблицу слов и соответствующие им хеши. Этот стол известен как Радужный Стол, и он легко доступен онлайн. Они могут использовать эту таблицу для обратного поиска действительного пароля путем сравнения хэшей, полученных из базы данных. Следовательно, очень важно иметь надежный пароль, так как вероятность появления вашего пароля в списке слов становится меньше.
 

Простое хранение хеша пароля больше не поможет. Мощности обработки резко возросли с появлением графических процессоров и CUDA, библиотек OpenCL. Быстрый графический процессор может генерировать миллионы хешей MD5 / SHA1 за одну секунду. Следовательно, хакер может легко сгенерировать большое количество хэшей, используя различные возможные комбинации, и может сравнить его с хешами, хранящимися в базе данных, чтобы извлечь действительный пароль.
Даже хешированные пароли не защищены! Удивлены?

 

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

Например :
Если ваш пароль - abc, а соль -! ZaP0 # 8, результат hashFunction (‘abc! ZaP0 # 8’) будет сохранен в базе данных вместо hashFunction (‘abc’).
Следовательно, атаки радужных таблиц теперь не будут эффективными, так как вероятность того, что радужная таблица содержит хэш «abc! ZaP0 # 8», является скудной (поскольку обычно радужные таблицы создаются из общих слов, словарных слов и т. Д.). Соль не хранится в базе данных и присутствует только в файле конфигурации приложения, который недоступен для внешнего мира. Получить доступ к исходным файлам сложнее, чем получить доступ к базе данных.
 

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

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

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

Вышеупомянутый подход довольно хорош, чтобы замедлить хакера. Однако рекомендуется использовать алгоритмы, такие как bcrypt и scrypt вместо MD5 / SHA1. Bcrypt - это алгоритм хеширования, основанный на Blowfish. Требуется указать фактор стоимости / работы. Фактор работы замедляет общий процесс и, следовательно, время, необходимое для создания хэш-таблицы, увеличится в несколько раз.