Использование случайной соли в шифровании пароля?

Question

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

1. Генерация случайной соли для пользователя.
2. Добавление соли к его паролю.
3. Используйте что-то вродеSHA-2 для хеширования результата.
4. Сохранение соли и хешированного пароля в базе данных.

Как работает этот метод при получении пароля пользователя и проверке входа в систему?В одном ответе говорится, что пользовательская соль должна быть извлечена, добавлена ​​к введенному паролю, хеширована, а затем сравнена с сохраненным хешем, но не вызывает ли это некоторых проблем?А именно:

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

Answer 1

Соль никогда не должна подвергаться риску вне службы - ваш инстинкт справедлив, что это будет подвергать соли и представлять риск.

Любое взаимодействие между вашим клиентом и сервером должно происходить через соединение SSL - илипо крайней мере, используя какое-то шифрование взаимодействия.

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

Answer 2

Вы должны использовать случайную соль, потому что целью ее использования является защита от некоторых типов атак, таких как атака по словарю, атака грубой силой и атака радуги. таким образом, очень важно генерировать случайную соль для каждого пароля и сохранять хешированный пароль и соль в пользовательской таблице или прикрепленной к профилю пользователя. Если вы хотите проверить пароль пользователя, достаточно хешировать введенный пароль с сохраненной солью и сравнить с сохраненным значением хеша. Я не верю, что @cherouvim советует, потому что кажется, что он не заботится о вышеупомянутых атаках. Для получения дополнительной информации я предлагаю удивительную, простую и понятную статью Defuse Security

Удачи.

Answer 3

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

+ 1 к тому, что ruslik сказал о соли.Это предотвращает атаки словаря / радуги.Радужная таблица для среднего пароля + несколько байтов случайных двоичных данных были бы астрономически огромными.

Answer 4

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

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

РЕДАКТИРОВАТЬ: к тому, что Беван сказал о связи: обычно схема «номер один раз» (NONCE) используется для передачи паролей по незащищенным каналам. Сервер выдает клиенту случайную строку, которая ранее никогда не использовалась, он добавляет ее к простому паролю, вычисляет хеш и отправляет ее. Это защищает вас от подслушивающих атак.

Answer 5

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

Answer 6

Хеширование паролей защищает от ясно видимых паролей, а их защита от словарных атак. Что касается защиты паролей во время транспортировки, я бы рекомендовал SSL / TLS.