Соляные пароли 101
Может ли кто-нибудь помочь мне понять, как работает соление?
Насколько я понимаю следующее:
- Проверить пароль
- Создать случайную строку
- Хэшируйте пароль и случайную строку и объединяйте их, затем сохраняйте их в поле пароля ...
Как мы можем хранить соль или узнать, что это такое, когда пользователь входит в систему? Храним ли мы его в своем поле? Если нет, как приложение определяет, что такое соль? И если мы его сохраним, разве это не победит всю цель?
5 ответов
Соль объединяется с паролем перед хешированием. значения пароля и очистки соли объединяются, а результирующая строка хэшируется. это гарантирует, что даже если у двух людей будет один и тот же пароль, у вас будут разные результирующие хэши. (также значительно усложняет атаки, известные как атаки по словарю с использованием радужных таблиц).
Затем соль сохраняется в исходном/чистом формате вместе с результатом хеширования. Затем позже, когда вы захотите проверить пароль, вы снова выполните исходный процесс. Объедините соль из записи с паролем, который предоставил пользователь, хешируйте результат, сравните хэш.
Вы, наверное, уже это знаете. но важно помнить. соль должна генерироваться случайным образом каждый раз. Он должен быть разным для каждого защищенного хэша. Часто ГСЧ используется для генерации соли.
Так... например:
пароль пользователя: "мой пароль"
случайная соль: "abcdefg12345"
результирующий открытый текст: "mypassword:abcdefg12345" (как вы их комбинируете, зависит от вас, если вы каждый раз используете один и тот же формат комбинации).
хешируйте полученный открытый текст: "somestandardlengthhashbasedonalgorithm"
Теперь в вашей базе данных вы должны хранить хеш и соль.Я видел это двумя способами:
метод 1:
field1 - соль = "abcdefg12345"
field2 - password_hash = "somestandardlengthhashbasedonalgorithm"
метод 2:
field1 - password_hash = "abcdefg12345:somestandardlengthhashbasedonalgorithm"
В любом случае вы должны загрузить соль и хэш пароля из своей базы данных и повторить хеш для сравнения
Согласно Практическая криптография (Нилс Фергюсон и Брюс Шнайер), вы должны использовать соленые растянутые хэши для максимальной безопасности.
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 может потребоваться увеличить, поскольку компьютеры становятся быстрее.
Если вы используете хорошо известный алгоритм хеширования, у кого-то может быть список из множества возможных паролей, уже хешированных с помощью этого алгоритма, и сравнить элементы из этого списка с хешированным паролем, который они хочу взломать (словарная атака).
Если вы «засолите» все пароли перед их хешированием, эти словари бесполезны, потому что они должны быть созданы с использованием вашей соли.
salt <- random
hash <- hash(password + salt)
store hash:salt
Позже
input password
look up hash:salt
hash(password+salt)
compare with stored hash
Понятно?
Как мы храним соль или знаем, что это такое, когда пользователь входит? Храним ли мы его в его собственном поле?
Да.
А если мы сохраним его, не сведет ли это на нет всю цель?
Нет. Цель соли не в том, чтобы быть секретной, а просто в том, чтобы злоумышленник не амортизировал стоимость вычисления радужных таблиц для всех сайтов в мире (не соль) или всех пользователей на вашем сайте (единая соль, используемая для всех пользователей).