Как засолить секрет перед хранением в БД, в чем слабости?

Question

Я слышал о людях, использующих этот подход, и хотел бы знать, каковы последствия. Я просто знаю это плохая идея!

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

Как хеш ослабляется в этом контексте, если обычный текст только что засолен сам по себе?

Пример:

plainText = input();
saltedText = plainText + plainText;
hashedText = hash(saltedText);
db.store(hashedText);

И будет ли следующий подход иметь те же слабости или любые другие слабости?

plainText = input();
saltedText = hash(plainText) + plainText;
hashedText = hash(saltedText);
db.store(hashedText);

Answer 1

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

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

Answer 2

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

Вы должны использовать различную соль каждый раз, когда хешируете строку:

plainText = input();
salt = getRandomSalt();
hashedText = hash(salt + plainText);
db.store(salt, hashedText);

Answer 3

Другие объяснили проблемы с вашей реализацией.

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

Например, AccountID, имя пользователя или адрес электронной почты могут быть использованы как солевой источник. Очевидно, что вы не должны использовать источник прямо как соль, вместо этого используйте функцию вывода ключа, такую ​​как PBKDF2.

Помните, что если основной источник соли изменится, пароль необходимо будет перефразировать. Это может быть реализовано путем запроса у пользователя пароля перед изменением ключевой информации (подтвердите пользователя, а затем используйте предоставленный пароль для перефразировки с помощью источника).