Я должен хешировать пароль прежде, чем отправить его в сторону сервера?

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

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

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

Неиспользование https является нарушением OWASP Top 10: A9-Insufficient Transport Layer Protection

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

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

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

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

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

, Если бы взломщик получил доступ к базе данных, возможно, через копию резервного копирования, то Вы хотели бы удостовериться, что нельзя было войти в систему только с тем знанием. Если бы, например, Вы снабдили хеш, посоливший именем для входа в систему как hash(login_name+password), и Вы передали тот же самый хеш от клиента для прямого сравнения, то взломщик мог выбрать пользователя наугад, отправьте хеш, считанный из базы данных, и войдите в систему как тот пользователь, не зная пароля, увеличив объем нарушения. В этом случае отправка пароля в простом тексте была бы более безопасной, потому что взломщик должен будет знать простой текст для входа в систему, даже имея копию базы данных. Это - то, где реализация является ключевой. , Отправляете ли Вы незашифрованный пароль или клиентский хеш того пароля, необходимо хешировать то значение в серверной стороне и сравнить тот хеш с хешем, сохраненным в пользовательской записи.

Понятия для учета:

• Вы "солите" хеш путем смешивания в некотором уникальном для объема значении к хешу, обычно уникальному для строки. Его цель состоит в том, чтобы гарантировать уникальность хешей друг от друга, даже если значения простого текста, которые они представляют, будут тем же, таким образом, у двух пользователей с тем же паролем все еще были бы различные хеши. Является ненужным рассматривать соль как секрет.
• При аутентификации, всегда хешируйте на серверной стороне безотносительно значения, которое Вы передаете от клиента как пароль (даже если это уже хешируется), и сравните его с предварительно хешированным значением, сохраненным на базе данных. Это может требовать хранить дважды хешированную версию старого пароля.
• при создании хеша полагайте, что добавление соли server/cluster-unique к хешу, а также уникальной для строки соли охраняет против соответствия любым предварительно вычисленным хешам в таблицах поиска.

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

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

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

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

Использовать дайджест HTTP - он защищает пароль даже через http (но лучше всего использовать дайджест http по 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-дайджест rfc: http://www.faqs.org/rfcs/rfc2617

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

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

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