Хм, я думаю, вы просто упускаете некоторые основные понятия, связанные с тем, как работает хеширование. Позвольте мне попытаться объяснить вкратце. Я собираюсь начать с простого и подробно изложить свой ответ позже, поэтому, пожалуйста, прочитайте все это, информация в начале не будет безопасной.
То, что вы хотите использовать для хранения пароля, - это функция, известная как «односторонний хэш». Это означает, что для любого входа, который вы используете для функции, один и тот же вход всегда будет давать одинаковый результат. Тем не менее, нет математического процесса , который позволил бы вам взять эту строку результата и выяснить, какой был исходный ввод.
Давайте возьмем MD5 в качестве примера функции хеширования. Если я запускаю MD5 в строке «пароль», я всегда получу результат «5f4dcc3b5aa765d61d8327deb882cf99». Однако, если вы просто дадите кому-то эту строку результата («5f4d ...»), то для них невозможно применить какой-либо математический процесс для «реверсирования» функции и выяснить, что она пришла из «пароля». *
Это означает, что когда пользователь впервые устанавливает свой пароль, вы применяете к нему функцию хеширования и сохраняете результат. Таким образом, вместо хранения «пароля», вы сохраняете «5f4dcc3b5aa765d61d8327deb882cf99». Затем, когда этот пользователь пытается войти в систему, вы берете все, что они ввели в поле пароля в форме входа, и применяете ту же функцию хеширования. Если вы получите тот же результат, что и данные, хранящиеся в базе данных, они должны были ввести тот же пароль, который они первоначально выбрали, даже если вы не знаете, каким на самом деле был этот оригинальный пароль.
Теперь, несмотря на то, что невозможно «обратить» хеш-функцию, тот факт, что один и тот же ввод всегда дает один и тот же вывод, означает, что кто-то может просто создать большую базу данных пар ввода-вывода и использовать ее для эффективного обращения хэши. Это называется "радужным столом". Многие из них доступны в Интернете, поэтому небезопасно использовать простое хеширование, на случай, если ваша база данных будет взломана. То есть, хотя математически невозможно * взять "5f4dcc3b5aa765d61d8327deb882cf99" и выяснить, что он был получен при запуске MD5 по "паролю", это очень легко определить на практике. Все, что вам нужно сделать, это запустить каждое слово в словаре через MD5 и сохранить результаты, и вы можете легко перевернуть простые пароли.
Вот тут и начинается "засоление". Если вы генерируете случайную строку "солт" для каждого пользователя и присоединяете ее к своему паролю, это эффективно разрушает радужные таблицы. Например, предположим, что тот же самый пользователь выше регистрируется со своим паролем как «пароль». Мы генерируем случайную 8-символьную соль для присоединения к паролю перед его хэшированием. Допустим, это "A4BR82QX". Теперь вместо хеширования «пароль» мы хешируем «A4BR82QXpassword». Это дает результат "87a4ba071c8bcb5efe457e6c4e6c4490", поэтому мы сохраняем его в базе данных вместе со строкой соли. Затем, когда этот пользователь пытается войти в систему, вместо того, чтобы напрямую хэшировать и сравнивать пароль, который он ввел в форму входа, мы берем то, что они ввели, снова ставим перед ним «A4BR82QX» и хешируем это. Как и раньше, если он совпадает с сохраненным хешем, мы знаем, что они ввели правильный пароль.
По сути, вы сделали так, чтобы предварительно созданные радужные таблицы были бесполезны для попыток взлома паролей в вашей базе данных. Поскольку соль случайна, и у каждого пользователя свой (в общем) свой, злоумышленнику придется заново генерировать свои радужные таблицы для каждого отдельного пользователя . Это намного сложнее.
Однако есть еще одна проблема: генерация хэшей MD5 быстрая . Несмотря на то, что для такой посолки требуется повторное создание радужных таблиц, из-за того, насколько быстрым является MD5, некоторые прилично завершенные радужные таблицы могут создаваться очень быстро. Поэтому, если они просто хотят взломать ценную учетную запись на вашем сайте, для них не составляет особого труда потратить некоторое время на создание радужных таблиц, чтобы попытаться отменить этот пароль. Если исходный пароль ценной учетной записи сам по себе не был достаточно безопасным, он все равно будет найден очень быстро, даже с засолкой.
Итак, следующий шаг - найти медленную хеш-функцию и использовать ее вместо быстрой, такой как MD5. Заставить ваш сайт потратить пару секунд, чтобы проверить логин, это совсем не проблема. Но когда кто-то пытается создать радужные таблицы для взлома пароля, каждая запись занимает несколько секунд, что является абсолютным убийцей. Я написал здесь достаточно, поэтому я просто закончу ссылками на эту статью, в которой много подробностей о выборе хорошей, медленной функции хеширования: Достаточно с радужными таблицами: что нужно знать о безопасности Схемы паролей .
Это был довольно масштабный ответ, если что-то из этого неясно, пожалуйста, дайте мне знать в комментарии, и я отредактирую для уточнения.