Должен ли я хранить соль вместе с хешированным паролем в базе данных?

Question

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

substr(str_shuffle(str_repeat('ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789',5)),0,10);

Он случайным образом генерирует некоторые символы в виде соли, но потом я подумал: как бы я начал проверять логины?Нужно ли удалять соль или хранить в базе данных?

Answer 1

Вы не должны использовать MD5 для хеширования пароля.См. Как безопасно хранить пароли моих пользователей?

Чтобы ответить на ваш оригинальный вопрос, соль хранится вместе с паролем HASHED в базе данных.Соль не считается секретной, если обнаружен хешированный пароль.Его цель - не дать злоумышленникам использовать радужные столы.

Answer 2

Сохранить в базе данных.В противном случае вы не сможете сравнить пароль, предоставленный пользователем, с хэшированным.

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

Answer 3

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

Представьте, что вы сохраняете пароли. Один из ваших пользователей выбирает слово «киви» в качестве пароля. Поскольку хранить пароли в виде простого текста глупо, вы не хотите этого делать. Вы хотите хешировать пароль.

Но эти противные хакеры создали огромные базы данных хеш-таблиц. (Отметьте это один выход!)

Итак, как нам помешать хакерам? Посолив ввод пользователя! Соль - это случайная строка (или набор битов, правильно), которая криптографически объединяется с вводом пользователя для получения более безопасного хэша.

Например, если хешируемая строка по-прежнему "kiwi", а наша соль - "5m3d", простой солевой механизм может объединить их в "kiwi5m3d". У хакеров, вероятно, есть «kiwi» в их базе данных, но, вероятно, нет «kiwi5m3d». Хорошая система соления, вероятно, будет выполнять гораздо более сложную функцию, чем эта.

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

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

В случае шифрования справочные таблицы все еще возможны, но данные, которые должны быть зашифрованы, как правило, достаточно разнообразны, чтобы их невозможно было реализовать. Таким образом, это становится игрой в «угадай пароль». Легко угадать «киви» и трудно угадать «киви5m3d».

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

Куда ты идешь отсюда? Во-первых, не используйте MD5. Я дал вам ссылку на базу данных поиска MD5 выше. Функция все чаще считается слабой. Класс алгоритмов ша - лучший выбор.

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

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

Answer 4

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

• Для каждого экземпляра пароля создается случайная соль достаточной длины.
• Случайная соль хранится вдоль хешированного значения; он вам понадобится, чтобы подтвердить пароль позже.
• Процесс хеширования пароля должен быть (настраиваемо) медленным, с множеством ( много ) вложенных вызовов любой хеш-функции, используемой внутри.
• Предпочтительно, чтобы внутренняя хеш-функция использовала операции, которые эффективны на ПК, но медленны на параллельной архитектуре (GPU).

Такая вещь существует, она называется bcrypt , и вы можете получить ее в PHP с помощью переносимой среды хеширования паролей PHP .

Answer 5

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

Пример:

$password = "banana";
$salt = "a12dsfg33B1cD2eF3G"; # Can be any assortment of characters
$password = md5($salt.$password);

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