Это плохая идея, чтобы отправить хэш пароля вместо нехэшированного пароля?

Question

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

Это кажется безопасным и простым. Почему это не популярный способ отправить пароль? Я что-то пропустил?

Другими словами: почему лучше потерять хэш, а не хэш-пароль? (у большинства из нас паролей ко многим сайтам мало)

Answer 1

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

Answer 2

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

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

Answer 3

Тогда я просто прослушиваю хеш и захожу с этим?

Если вы беспокоитесь о безопасности, вы должны использовать SSL. Тогда вы можете просто отправить пароль как есть.

Кроме того, SSL доказывает, что сервер, на который они входят, - это не тот, кто выдает себя за вас.

Answer 4

Вы делаете свою работу более сложной, чем она есть.Просто отправьте пароль в виде обычного текста, хеш никак не улучшит безопасность.(См. Ответы других)

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

Answer 5

Обратите внимание, что если вы только хешируете пароль, хеш будет точно таким же каждый время.

Вы должны использовать механизм вызова / ответа, аналогичный APOP в протоколе POP3

Answer 6

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

Answer 7

См. Perl / Javascript MD5 Secure User Authentication для реализации и обсуждения.