Может ли кто-нибудь помочь мне понять, как работает соление?
До сих пор я понимаю следующее:
Как мы храним соль или знаем, что это такое, когда пользователь входит в систему? Сохраняем ли мы его в своей области? Если мы этого не сделаем, как приложение выяснит, что такое соль? И если мы его сохраним, разве это не победит целую цель?
Соль сочетается с паролем перед хешированием. значения пароля и солевой прозрачности конкатенируются, а результирующая строка хешируется. это гарантирует, что даже если у двух человек будет одинаковый пароль, у вас будут разные хэши. (также делает атаки, известные как словарные атаки с использованием радужных таблиц, намного сложнее).
Затем соль сохраняется в исходном/прозрачном формате вместе с хеш-результатом. Затем, когда вы захотите проверить пароль, вы снова выполните оригинальный процесс. Объедините соль из записи с паролем, который пользователь предоставил, хэш-результат, сравните хэш.
Вы, наверное, уже это знаете. но важно помнить. соль должна генерироваться случайным образом каждый раз. Для каждого защищенного хэша он должен быть другим. Часто RNG используется для получения соли.
Итак, например:
пароль пользователя: "mypassword"
случайная соль: "abcdefg12345"
result-cleartext: "mypassword: abcdefg12345" (как вы их сочетаете, зависит от вас, если вы используете один и тот же формат комбинации каждый раз).
хэш в результате открытого текста: "somestandardlengthhashbasedonal algorithmm"
В вашей базе данных теперь вы будете хранить хеш и соль. Я видел это двумя способами:
метод 1:
поле1 - соль = "abcdefg12345"
field2 - password_hash = "somestandardlengthhashbasedonalgorithm"
метод 2:
field1 - password_hash = "abcdefg12345: somestandardlengthhashbasedonalgorithm"
В любом случае вам нужно загрузить хеш соли и пароля из своей базы данных и повторить хеш для сравнения
salt <- random
hash <- hash(password + salt)
store hash:salt
Далее
input password
look up hash:salt
hash(password+salt)
compare with stored hash
Получил?
Как мы храним соль или знаем, что это такое, когда пользователь входит в систему? Сохраняем ли мы его в своей области?
Да.
И если мы его сохраним, разве это не победит целую цель?
Нет. Цель соли - не секретность, а просто предотвращение того, чтобы злоумышленник амортизировал стоимость вычислений радужных таблиц по всем сайтам в мире (не солевым) или всем пользователям вашего сайта (единственная соль, используемая для всех пользователей).
Согласно практической криптографии (Neils Ferguson и Bruce Schneier), вы должны использовать соленые, растянутые хеши для максимальной безопасности.
x[0] := 0
x[i] := h(x[i-1] || p || s) for i = 1, ..., r
K := x[r]
where
h is the hash (SHA-1, SHA-256, etc.)
K is the generated hashed password
p is the plaintext password
r is the number of rounds
s is the randomly generated salt
|| is the concatenation operator
Значение соли - это случайное число, которое хранится с зашифрованным паролем. Он не должен оставаться секретным.
Растяжение - это шаг выполнения хэша несколько раз, чтобы сделать его сложнее вычислить для злоумышленника, чтобы проверить множество перестановок паролей. r следует выбирать так, чтобы вычисление занимало около 200-1000 мс на компьютере пользователя. r, возможно, потребуется увеличить, поскольку компьютеры становятся быстрее.
Это хорошее описание того, как хранить пароли - какие соли, какое шифрование использовать и т.д.
http://www.codinghorror.com/blog/2007/09/youre-probably-storing-passwords-incorrectly.html
Если вы используете хорошо известный алгоритм хэширования, у кого-то может быть список многих возможных паролей, уже хэшированных с использованием этого алгоритма, и сравнить элементы из этого списка с хэшированным паролем, который они хотят взломать (словарная атака).
Если вы "солите" все пароли перед их хэшированием, эти словари бесполезны, потому что их нужно будет создать, используя соль.