Простой текстовый пароль через HTTPS

Question

В настоящее время я работаю над провайдером PHP OpenID, который будет работать по протоколу HTTPS (следовательно, с шифрованием SSL).
Это неправильно для меня, чтобы передать пароль в виде простого текста? HTTPS в теории не может быть перехвачен, поэтому я не вижу ничего плохого. Или это небезопасно на каком-то уровне, и я не вижу этого?

Answer 1

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

Answer 2

Вам все еще нужно убедиться, что вы отправляете его с помощью запроса POST, а не GET. Если вы отправите его с помощью запроса GET, он может быть сохранен в виде открытого текста в журналах истории браузера пользователя или в журналах доступа веб-сервера.

Answer 3

Если HTTP отключен, и вы только используете HTTPS, тогда вы все равно не будете передавать пароль в виде простого текста.

Answer 4

Хеш-сторона клиента. Зачем? Позвольте мне рассказать вам о небольшом эксперименте. Подойдите к компьютеру в столовой компании. Откройте браузер для входа на сайт компании (https). Нажмите F12, щелкните вкладку сети, отключите сохранение журнала, сверните консоль, но оставьте веб-страницу открытой для входа в систему. Сядьте и пообедайте. Наблюдайте, как сотрудник после того, как сотрудник входит в систему на веб-сайте компании, и когда хороший маленький работник выходит из системы, когда закончите. Завершите обед, сядьте за компьютер, откройте вкладку сети и просмотрите каждое имя пользователя и пароль в виде простого текста в форме bodys.

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

Но, эй, продолжайте думать, все, что вам нужно, это SSL. Плохие парни будут любить тебя за это.

Answer 5

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

Answer 6

Давайте сделаем несколько заметок к предыдущим ответам.

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

Во-вторых, обмен криптографическими ключами также не идеален. MITM может теоретически (учитывая, что на клиенте установлен корневой сертификат) изменять криптографические ключи и изменять его собственными ключами:

Исходное соединение (не считая tls) с теоретического сервера, который обменивается ключами:

Клиентские открытые ключи запроса> сервер хранит личные ключи, генерирует открытые ключи для клиента> сервер отправляет открытые ключи клиенту

Теперь в теоретическом атласе MITM:

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

В этом смысл доверенного сертификата CA в TLS, и именно таким образом вы получаете сообщение от браузера, если сертификат недействителен.

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

Однако вы можете реализовать 2FA, чтобы люди никогда не пытались войти с одним и тем же паролем. Остерегайтесь атак воспроизведения, хотя.

Я плохо разбираюсь в криптографии, поправьте меня, если я ошибаюсь.