Обычный текстовый пароль по HTTPS

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

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

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

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

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

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

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

Сделаем некоторые заметки к предыдущим ответам.

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

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

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

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

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

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

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

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

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

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

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

В примере @CodeDog есть проблемы ..

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

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

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

физический уровень -> компьютерный уровень -> клиентский уровень -> сетевой уровень -> серверный уровень

Для сети не имеет значения, есть ли у вас хэш на стороне клиента, потому что уровень https / ssl будет шифровать простой пароль. Как отмечают другие, хеширование клиента избыточно, если TLS безопасен.