В чем преимущество засолки хэша пароля?

Question

Я только что прочитал много, много статей на SO о хешировании паролей с солью, но я просто не могу найти ответ на конкретный запрос / путаницу, которую я имею.

Допустим, я только что сделал этот метод для добавленияпароль и соль для БД:

• Создание случайной соли
• Хэширование пароля пользователя + соли вместе
• Сохранение вывода хеш-кода в качестве пароля в столбце 'пароль '
• Сохранить случайную соль в столбце' соль '

Если это правильно, что произойдет, когда злоумышленник получит доступ к моей БД?Конечно, если они могут прочитать значение соли для этого хешированного пароля, они могут определить, что такое хешированный пароль без соли, а затем использовать радужную таблицу?Или это хорошая идея, чтобы зашифровать значение соли тоже с помощью чего-то, что является обратимым?

Если значение соли хранится в виде простого текста, я просто не вижу смысла в этом.Пожалуйста, просветите меня?

Answer 1

Если злоумышленник доберется до базы данных, тогда все ставки сняты, но до соли ...

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

Итак ...

1. Сделайте соль Случайно , а;
2. Соль большая

Теперь, если предполагается, что злоумышленник имеет базу данных, возникает другая проблема: скорость атаки не ограничена, и именно поэтому схема хэширования пароля, такая как bcrypt или несколько раундов ценно. Он может снизить скорость атаки с сотен миллионов хешей в секунду (MD / SHA и друзья были сделаны , чтобы быть быстрыми), скажем, до нескольких сотен в секунду ( на том же оборудовании) ... Также рассмотрим подход HMAC, который также включает в себя секрет сервера (что делает его эффективным паролем + соль + секрет).

(я бы просто использовал существующую систему, которая уже решает все эти проблемы, и многое другое: -)

Удачного кодирования.

Answer 2

Правильные шаги, которые вы обрисовали в общих чертах.

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

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

Answer 3

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

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

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