Почему мы используем «соль» для защиты наших паролей?

Question

я читал этот учебник , и я столкнулся со следующим обсуждением о шифровании.В конце написано:

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

Но, по моему мнению, хакер, у которого есть и encrypted_password, и salt, мог бы выполнить трюк с "радугой" точно так же, как если бы мы использовали salt.

Итак, где яя не прав?

Спасибо!

$ rails console
>> require 'digest'
>> def secure_hash(string)
>>   Digest::SHA2.hexdigest(string)
>> end
=> nil
>> password = "secret"
=> "secret"
>> encrypted_password = secure_hash(password)
=> "2bb80d537b1da3e38bd30361aa855686bde0eacd7162fef6a25fe97bf527a25b"
>> submitted_password = "secret"
=> "secret"
>> encrypted_password == secure_hash(submitted_password)
=> true

Здесь мы определили функцию secure_hash, которая использует криптографическую хеш-функцию SHA2, часть семейства хеш-функций SHA, который мы включаем в Ruby через библиотеку дайджеста. 7 Не важно точно знать, как работают эти хэш-функции;для наших целей важно, чтобы они были односторонними: нет вычисляемого способа обнаружить, что

2bb80d537b1da3e38bd30361aa855686bde0eacd7162fef6a25fe97bf527a25b - это SHA2 * хэш * 10 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * если что о чем вы не думаете *, если вы думаете, 10 *однако, у нас все еще есть проблема: если злоумышленник когда-нибудь овладеет хешированными паролями, у него все равно будет шанс обнаружить оригиналы.Например, он мог догадаться, что мы использовали SHA2, и поэтому написал программу для сравнения заданного хэша с хешированными значениями потенциальных паролей:

>> hash = "2bb80d537b1da3e38bd30361aa855686bde0eacd7162fef6a25fe97bf527a25b"
>> secure_hash("secede") == hash
=> false
>> secure_hash("second") == hash
=> false
>> secure_hash("secret") == hash
=> true

Таким образом, у нашего злоумышленника есть совпадение - плохие новости для любых пользователей.с паролем "секрет".Этот метод известен как радужная атака.

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

>> Time.now.utc
=> Fri Jan 29 18:11:27 UTC 2010
>> password = "secret"
=> "secret"
>> salt = secure_hash("#{Time.now.utc}--#{password}")
=> "d1a3eb8c9aab32ec19cfda810d2ab351873b5dca4e16e7f57b3c1932113314c8"
>> encrypted_password = secure_hash("#{salt}--#{password}")
=> "69a98a49b7fd103058639be84fb88c19c998c8ad3639cfc5deb458018561c847"

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

Answer 1

Радужные таблицы дорогие для вычисления.Без соли вы можете создать радужную таблицу один раз, которую можно будет использовать повторно, поскольку пароль «пароль» всегда будет приводить к одному и тому же хешу (md5 = 5f4dcc3b5aa765d61d8327deb882cf99, sha1 = 5baa61e4c9b93f3f0682250b6cf8331b7ee68f8, поэтому можно легко определить базу данных *).1001 *

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

Answer 2

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

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

Answer 3

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

Так, например, если у вас есть пароль, состоящий из 10 символов (все цифры), у вас есть 10 ^ 10 возможностей. Если вы разрешите строчные и прописные буквы алфавита, это может составить до 62 ^ 10 возможных, всего 8,39 * 10 ^ 17 перестановок; и это только для 10-символьных паролей, вы также должны учитывать любую длину ниже этой и выше, в зависимости от длины пароля, которую вы разрешаете.

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

Answer 4

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

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