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

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

Согласно голой безопасности, 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. Требуется указать коэффициент стоимости / трудозатрат. Фактор работы замедляет общий процесс, и, следовательно, время, необходимое для создания хеш-таблицы, увеличится в несколько раз.

Рекомендации :
https://nakedsecurity.sophos.com/2013/11/20/serious-security-how-to-store-your-users-passwords-safely/

Эта статья предоставлена Сакет Кумар . Если вам нравится GeeksforGeeks, и вы хотели бы внести свой вклад, вы также можете написать статью с помощью provide.geeksforgeeks.org или отправить ее по электронной почте на deposit@geeksforgeeks.org. Посмотрите, как ваша статья появляется на главной странице GeeksforGeeks, и помогите другим гикам.

Пожалуйста, напишите комментарии, если вы обнаружите что-то неправильное, или вы хотите поделиться дополнительной информацией по теме, обсужденной выше.