Безопаснее ли удваивать хеш-пароли с солью? (немного сложнее)
В этом случае каждый хочет аутентифицировать пользователя через http/s.
В процессе регистрации сервер генерирует соль. Эта соль отправляется пользователю. Затем он приступает к хешированию своего пароля с солью через js и отправляет его на сервер. Там хэш снова засоляется той же солью, а дважды хешированный и засоленный пароль записывается в БД с солью открытого текста.
Если кто-то пытается аутентифицироваться, он отправляет свое имя пользователя, получает соль и хэширует пароль. Это отправляется на сервер, который снова его хеширует, и если сохраненный хеш, и это тот же самый, пользователь аутентифицируется.
Мне было интересно, что из-за недавней ошибки с кровотечением было бы неплохо никогда не раскрывать настоящий пароль. Но я читал, что двойное хеширование может увеличить риск коллизий.
Это то, как я представлял, что это самый безопасный способ, или я что-то неправильно понимаю?
2 ответа
"В процессе регистрации сервер генерирует соль. Эта соль отправляется пользователю. Он…" Я должен остановить вас прямо сейчас.
В принципе, нет ничего плохого в хешировании на стороне клиента, если вы понимаете, что это не повышает безопасность вашей системы. Однако хэширование / переваривание означает, что полученные пароли всегда имеют очень специфическую форму, независимо от формы фактического пароля, выбранного пользователем, и это означает, что вы (как владелец сервера) теоретически не знаете пароль пользователя, который отправив это вам.
Это небезопасно, потому что вы - и любой слушающий - можете взять этот хешированный пароль и взломать его (потому что вы ничем не отличаетесь от злоумышленника в этом отношении). Тем не менее, это добавляет уровень доверия: "Я должен изо всех сил, чтобы выяснить, какой у вас пароль".
Принимая это во внимание, соление на клиенте бесполезно, и если вы получаете соль с сервера, это ложное чувство безопасности: если вы отправляете соль с сервера клиенту, все, что может видеть пользователь Пароль на стороне клиента также может видеть соль на стороне клиента. Вы могли бы также написать соленую ценность как <h1> заголовок на странице, там нет никакой безопасности, и вы просто тратите время на засолку процессора.
Теперь вы все еще хотите правильно хэшировать на сервере с солью, но нет никакого смысла в том, чтобы клиент делал какие-либо засолки. Просто дайте им дайджест / хеш-код на стороне клиента (например, библиотеку SHA256) и оставьте все как есть. Затем на сервере вы получаете пароль, проверяете его на соответствие тому, что вы знаете о том, как должны выглядеть хешированные пароли (правильная длина? Нет символов вне пространства хеширования? И т. Д.), А затем вы хэшируете этот ввод своей солью и сохраняете это / используйте это для проверки вашей пользовательской базы данных.
Мне было интересно, из-за недавней ошибки кровотечения было бы неплохо никогда не раскрывать реальный пароль.
Я вижу, откуда ты, но ты не думал об этом все время. Если вы хэшируете пароль клиентской стороны и отправляете хеш на сервер, то этот хеш по сути является паролем пользователя. Если злоумышленник завладеет этим хешем, который клиент отправил на сервер, будь то с помощью heartbleeding, MITM-атак или иным образом, все, что нужно сделать злоумышленнику, это отправить этот хешированный пароль на ваш сервер (без повторного хеширования на стороне клиента очевидно) для того, чтобы войти в систему. Хеширование на стороне клиента ничего не дает.
Но я читал, что двойное хеширование может увеличить риск коллизий.
Теоретически да. Если пароль длиннее полученного хэша, энтропия ввода гарантированно будет уменьшена. Даже если входные данные короче результирующего хэша, есть вероятность, что энтропия несколько уменьшится. Хэширование этих данных уменьшенной энтропии снова уменьшает энтропию (теоретически). На практике это вряд ли будет иметь значение.