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


93

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

Ответы:


129

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


20
Незначительная придирка: некоторые формы входа в систему используют JavaScript для хеширования пароля вместо отправки его в виде обычного текста.
Thorarin

5
@Thorarin, если они действительно хешируют его, это означает, что сервер хранит пароль в виде обычного текста, поэтому он может хешировать с той же солью для проверки. Крик! Лучше отправлять пароль в виде текста, обернутого ssl, поскольку в этом случае серверу не нужно хранить пароль в виде обычного текста.
DGM

11
@DGM: двойное хеширование также возможно, поэтому пароли в виде простого текста не являются обязательными.
Thorarin

3
@Denis: хеширование на стороне клиента не особо помогает. Это может сделать вещи немного сложнее, чем простой текст, но тот, кто действительно хочет украсть пароль, может сделать это без проблем. Будет безопасно работать только в том случае, если вы отправите хотя бы разовый токен по защищенному каналу (ssl), и в этом случае вы можете просто отправить пароль в SSL для начала.
Eduardo Scoz 06

4
Я просто говорю, что Yahoo считала, что хеширование на стороне клиента было достаточно безопасным, пока они не могли позволить себе полностью перейти на ssl. Но эй, я за https :)
Денис

74

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


7
Да, я знал это, но это все же хороший комментарий, который стоит оставить для других, кто сюда заглянет. :)
WhyNotHugo

или отправьте его в заголовок
Джеймс

22

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


4
Однако сервер делает доступ к вашему открытому тексту пароля, они могут сохранить его как обычный текст, журнал это неправильно , как открытый текст и т.д. То есть, ваш пароль не остается на стороне клиента, сервер также видит именно то , что он есть.
xref

14

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

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

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


6
Ваш комментарий кафетерия не имеет никакого смысла, сколько бы я его ни перечитывал. Зачем людям просто подходить к компьютеру и вводить свои учетные данные? Что вы пытаетесь доказать? Кроме того, хеширование никоим образом не сделает это более небезопасным. Когда этот вопрос был написан в 2009 году, было обычным делом хэшировать пароли и передавать их по
обычному

4
Я upvoted оба из них , потому что, да, принятый ответ будет читается много лет спустя. Было бы хорошо, если бы @CodeDog указал на некоторую стратегию смягчения последствий. И да, люди просто подходят к случайным компьютерам, например, в местной библиотеке, и вводят свои данные!
JoeAC

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

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

Я сам выполнил такой эксперимент, войдя в свой банковский счет, и должен согласиться с @CodeDog - полезные данные запроса включают мой логин и пароль в виде открытого текста.
Artur Michajluk

6

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

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

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

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

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

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

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

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

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

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

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


Имейте в виду, что это обсуждение относится к 2009 году. Это были в значительной степени лучшие практики в то время.
WhyNotHugo

3
@WhyNotHugo Я в курсе. Я решил оставить ответ, потому что главный ответ Google на этот вопрос привел меня сюда, так почему бы и нет.
Лукка Ферри,

4

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


Да, я понимаю, спасибо, я просто имел в виду передачу здесь.
WhyNotHugo

0

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

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

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

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

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

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


1
Высказывая хорошие моменты, вы отвечаете на ответ (который сам по себе не имеет отношения к заданному вопросу), поэтому он не подходит для модели вопросов и ответов Stackoverflow.
Мартин
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.