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


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

11 77

11 ответов:

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

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

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

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

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

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

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

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

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

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

TL; DR:

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

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

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

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

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

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

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

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

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

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

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

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

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

Википедия:

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

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

Если вы хотите увидеть" реальное " использование, вы можете посмотреть на phpMyID-провайдер PHP openid, который использует HTTP digest authentication 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

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

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

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

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

Сделайте и то и другое

Делайте и то и другое, потому что:

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

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

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

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

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

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

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

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

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