Должен ли я хэш-пароль перед отправкой его на сервер?

Ответ 1

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

ОП никогда не упоминал об отправке пароля в незашифрованном виде по протоколу HTTP - только по протоколу HTTPS, однако многие, похоже, по какой-то причине отвечают на вопрос об отправке пароля по протоколу HTTP. Это говорит:

Я считаю, что пароли никогда не должны храниться (не говоря уже о передаче) в виде простого текста. Это означает, что не хранится на диске или даже в памяти.

Люди, которые отвечают здесь, похоже, думают, что HTTPS - это серебряная пуля, а это не так. Однако это, безусловно, очень помогает, и его следует использовать в любом сеансе аутентификации.

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

Итак, у нас есть ключ. Теперь нам нужно очистить любой след пароля на клиентском устройстве.

Затем нам нужно получить этот ключ для ваших систем. Вы никогда не должны передавать ключ или пароль "в открытом виде". Даже не по HTTPS. HTTPS не непробиваем. На самом деле, многие организации могут стать доверенными MITM - не с точки зрения атаки, а с целью проверки трафика для реализации своих собственных политик безопасности. Это ослабляет HTTPS, и это не единственный способ, которым это происходит (например, перенаправление на атаки HTTP MITM). Никогда не думайте, что это безопасно.

Чтобы обойти это, мы хешируем ключ с одноразовым разом. Этот одноразовый номер уникален для каждой отправки ключа в ваши системы - даже для одного и того же удостоверения в течение одного сеанса, если вам нужно отправить его несколько раз. Вы можете отменить этот одноразовый номер, как только он поступит в ваши собственные системы, чтобы восстановить ключ аутентификации и аутентифицировать запрос.

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

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

TL; DR:

Используйте HTTPS. Надежно хешируйте пароли, необратимо, с уникальной солью за пароль. Сделайте это на клиенте - не передавайте свой действительный пароль. Передача оригинального пароля пользователя на ваши серверы никогда не бывает "OK" или "Fine". Очистите все следы оригинального пароля. Используйте одноразовый номер независимо от HTTP/HTTPS. Это гораздо более безопасно на многих уровнях. (Ответ на ОП).

Ответ 2

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

Ответ 3

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

Весь смысл хэширования паролей заключается в том, чтобы добавить дополнительный уровень безопасности. Если злоумышленник может получить хеш и соль из базы данных с помощью SQL-инъекции или небезопасной резервной копии, он должен найти простой текст, перебрав его. John The Ripper обычно используется для взлома соленых хэшей.

Неиспользование https является нарушением OWASP Top 10: A9-Недостаточная защита транспортного уровня

РЕДАКТИРОВАТЬ: Если в вашей реализации вы вычисляете sha256(client_salt+plain_text_password) а затем вычисляете еще один хэш на стороне сервера sha256(server_salt+client_hash) то это не является серьезной уязвимостью. Тем не менее, он все еще подвержен перехвату и повторному запросу. Таким образом, это все еще явное нарушение WASP A9. Тем не менее, это все еще использует дайджест сообщения в качестве уровня безопасности.

Самая близкая вещь, которую я видел к замене https на стороне клиента, - это диффи-хеллман в обмене ключами в javascript. Однако это предотвращает активные атаки MITM и, таким образом, до тех пор является техническим нарушением OWASP A9. Авторы кода согласны с тем, что это не полная замена HTTPS, однако это лучше, чем ничего и лучше, чем система хеширования на стороне клиента.

Ответ 4

Отправка хэша по проводу полностью поражает цель хэша, потому что злоумышленник может просто отправить хэш и забыть о пароле. В двух словах, система, которая аутентифицирует использование хэша в открытом тексте, широко открыта и может скомпрометировать не более, чем сетевое обнюхивание.

Ответ 5

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

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

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

Мой подход к проблеме в создаваемом сокетном веб-приложением, который я создаю, заключается в том, что при подключении к клиенту сервер генерирует соль (случайную строку, которая должна быть добавлена ​​до хэширования), и сохраняет ее в переменной сокетов, затем она передает этот хэш клиенту. Клиент берет пароль пользователей, хэширует его, добавляет соль с сервера и хэширует все это, прежде чем передавать его на сервер. Затем он отправляется на сервер, который сравнивает этот хеш с хешем (хэш в базе данных + +). Насколько я знаю, это хороший подход, но, честно говоря, я не много читал по этой теме, и если я ошибаюсь во всем, что мне хотелось бы исправить:)

Ответ 6

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

Тем не менее, базовое обфускация пароля на стороне клиента (не хеш), переданная по HTTPS, имеет некоторое значение. Если я не ошибаюсь, эта техника фактически используется некоторыми банками. Цель этой методики - не защищать пароль от обнюхивания по проводу. Скорее, это, чтобы остановить использование пароля для немых шпионских инструментов и плагинов браузера, которые просто захватывают каждый запрос HTTPS GET/POST, который они видят. Я видел файл журнала, захваченный с вредоносного веб-сайта, который составлял 400 МБ случайных транзакций GET/POST, захваченных с пользовательских сеансов. Вы можете себе представить, что веб-сайты, которые использовали только HTTPS, отображались с открытым текстом паролей в журнале, но веб-сайты с очень простой обфускацией (ROT13) также отображались с паролями, которые не сразу используются.

Ответ 7

Использовать HTTP-дайджест - он защищает пароль даже через http (но лучшее использование будет http digest через https)

Википедия:

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

Ссылка: http://en.wikipedia.org/wiki/Digest_access_authentication

Если вы хотите увидеть использование "реальной жизни", вы можете посмотреть на phpMyID - поставщик php openid, который использует аутентификацию электронной почты http http://siege.org/phpmyid.php

.. или вы можете начать с образцов php auth в http://php.net/manual/en/features.http-auth.php

Http digest rfc: http://www.faqs.org/rfcs/rfc2617

Из моих тестов все современные браузеры поддерживают его...

Ответ 8

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

Сделайте оба

Сделайте так:

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

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

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

Я просто хочу подчеркнуть здесь, что если вы решите хешировать ключ перед отъездом со своих клиентов, этого недостаточно - бэкэнд-хэширование, imo, гораздо важнее, и вот почему: если кто-то перехватывает трафик от вашего клиента, то они будут видеть содержимое поля password. Является ли это хешем или простым текстом, это не имеет значения - они могут скопировать его дословно для олицетворения авторизованного клиента. (Если вы не выполните шаги, описанные в @user3299591, и я рекомендую вам это сделать). С другой стороны, хеширование столбца БД является необходимостью, а вовсе не сложной задачей.

Ответ 9

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

Ответ 10

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

Используя HTTPS, вы запрещаете хакеру получать пароль из одного источника, поскольку HTTPS использует два канала, оба зашифрованные.

Ответ 11

Разве SSL/TLS не заменяет nonce? Я не вижу добавленной ценности, поскольку SSL/TLS также защищает от Replay Attacks.

Ref. https://en.wikipedia.org/wiki/Cryptographic_nonce