Соли бесполезны для безопасности, если злоумышленник знает их?

Скажем, у меня есть таблица пользователей, настроенная так:

CREATE TABLE `users` (
    `id` INTEGER PRIMARY KEY,
    `name` TEXT,
    `hashed_password` TEXT,
    `salt` TEXT
)

Когда пользователь создается, генерируется произвольно генерируемая соль и сохраняется в базе данных вместе с результатами чего-то вроде get_hash(salt + plaintext_password).

Мне интересно, может ли злоумышленник получить эти данные, смогут ли они использовать его для взлома паролей пользователей? Если да, то каким способом это можно предотвратить?

Ответ 1

Нет, они не бесполезны.

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

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

Ответ 2

В файл UNIX/etc/passwd был добавлен (или, по крайней мере, популярный) солонка, который был доступен для чтения в мире. Обычно считается, что соль, а также зашифрованный пароль известны крекеру. Целью соли является замедление процесса взлома (поскольку тот же пароль не будет отображаться на одну и ту же зашифрованную строку); это не секрет сам по себе.

Ответ 3

Зная соль, можно сделать атаку грубой силы, но это не делает ее бесполезной. Соль не позволяет злоумышленнику использовать уже сгенерированный радужный стол (который вы можете найти в Интернете).

Лучший способ предотвратить грубое форсирование - просто использовать длинные сложные пароли.

Ответ 4

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

Ответ 5

Нет, это не бесполезно.

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

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

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

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

Ответ 6

Это должно дать вам представление о том, как это работает.

Предположим, вы хотите зашифровать слово "секрет". После того, как он зашифрован, скажем, теперь это выглядит как 00110010.

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

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

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

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

Ответ 7

Предполагая, что атака грубой силы алгоритмов MD5, SHA1, SHA256 с GPU имеет пропускную способность более 1 миллиарда попыток в секунду и SHA512 около 300 М/с. Если вы используете один из этих алгоритмов, это замедлит хакера, который использовал таблицу радуги (менее вероятно), но это не замедлит хакера, который использовал атаку грубой силы (более вероятно). Это окончательно не защитит вас, это просто добавит немного защиты от устаревшего стола радуги (для этого алго). Немного лучше, чем ничего.

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

Взгляните на это статья и подытожить:

Если вы пользователь:

Убедитесь, что все ваши пароли имеют 12 символов и более, в идеале - намного больше. Я рекомендую принимать пропущенные фразы, которые не только намного легче запомнить, чем пароли (если не тип), но и смехотворно защищают от грубой форсировки исключительно из-за их длины.

Если вы разработчик:

Используйте bcrypt или PBKDF2 исключительно для хэширования всего, что вам нужно для обеспечения безопасности. Эти новые хеши были специально разработаны, чтобы их было сложно реализовать на графических процессорах. Не используйте другую форму хэша. Почти любая другая популярная схема хэширования уязвима для грубой форсировки массивами товарных графических процессоров, которые только быстрее и более параллельны и легче программируются на каждый год.

Отправленный Джеффом Этвудом