Соление паролей 101

Question

Может кто-нибудь помочь мне понять, как работает соление?

Пока я понимаю следующее:

1. Подтвердить пароль
2. Генерация случайной строки
3. Хэшируйте пароль и случайную строку и объединяйте их, затем сохраняйте в поле пароля ...

Как мы храним соль, или знаем, что это, когда пользователь входит в систему? Храним ли мы его в своем поле? Если нет, как приложение определяет, что такое соль? И если мы сохраняем это, разве это не разрушает всю цель?

Answer 1

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

Затем соль сохраняется в оригинальном / чистом формате вместе с результатом хеширования. Затем, когда вы захотите подтвердить пароль, вы снова выполните исходный процесс. Объедините соль из записи с паролем, предоставленным пользователем, хэшируйте результат, сравните хеш.

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

Так ... например:
пароль пользователя: "mypassword"
случайная соль: "abcdefg12345"
result-cleartext: "mypassword: abcdefg12345" (как вы их комбинируете, зависит от вас. Пока вы каждый раз используете один и тот же формат комбинации). хэшируйте результирующий открытый текст: «некоторый стандартный алгоритм на основе хэша»

Теперь в вашей базе данных вы должны хранить хеш и соль Я видел это двумя способами:

метод 1:
field1 - salt = "abcdefg12345"
field2 - password_hash = "некоторый стандартный алгоритм на основе хэша"

метод 2:
field1 - password_hash = "abcdefg12345: некоторый стандартный алгоритм на основе хэша"

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

Answer 2

salt <- random
hash <- hash(password + salt)
store hash:salt

Позже

input password
look up hash:salt
hash(password+salt)
compare with stored hash

Понял?

Answer 3

Как мы храним соль, или знаем, что это, когда пользователь входит в систему? Храним ли мы его в своем поле?

Да.

А если мы его сохраним, разве это не победит всю цель?

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

Answer 4

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

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 может потребоваться увеличить, поскольку компьютеры работают быстрее.

Answer 5

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