SQL

А у вас в базе хеш-функции солёные?

СВ
Саша Волк
76 331
Хеширование пароля – это один из тех предметов, которые очень просты по сути, но все еще много людей понимают его неверно. С помощью этой статьи я надеюсь объяснить вам не только, как правильно делать хеширование, но и почему оно должно быть сделано подобным образом.
Общая схема процесса регистрации аккаунта и аутентификации в системе учетных записей, основанной на хешировании, выглядит следующим образом:

Пользователь создает учетную запись;
Вычисляется хеш-код от пароля и сохраняется в базе данных. Нет никакого смысла в пароле, записанном в обычном текстовом (незашифрованном) формате на жесткий диск;
Когда пользователь пытается войти в систему, хеш-код, вычисленный от пароля, который он ввел, сравнивается с хеш-кодом реального пароля (извлеченным из базы данных);
Если хеш-коды совпадают, пользователю предоставляется доступ. Если нет – пользователю сообщается, что он ввел неверные данные для входа в учетную запись;
Шаги 3 и 4 повторяются каждый раз, когда кто-либо пытается войти в свой аккаунт.
На шаге 4 никогда не сообщайте пользователю, что именно не так: имя пользователя или пароль. Всегда отображайте только общее сообщение, например, «Неверное имя пользователя или пароль». Это не позволит злоумышленникам вычислить верные имена пользователей без знания их паролей.
Добавление соли.... да вы и сами знаете))))))))))

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

Если пароль каждого пользователя хешируется с помощью разной соли, атака с использованием обратной таблицы поиска также не будет работать.
Gia Gio
Gia Gio
9 266
Лучший ответ
Александр Дурняков А вот вопрос-то ты не прочитал.
Естественно