Насколько безопасна отправка конфиденциальных данных через https? - PullRequest
24 голосов
/ 10 октября 2008

Достаточно ли безопасен SSL для использования конфиденциальных данных (например, пароля) в строке запроса? Есть ли дополнительные опции для реализации?

Ответы [ 10 ]

48 голосов
/ 10 октября 2008

SSL обеспечивает безопасный уровень безопасности транспортного уровня . Никто между клиентом и сервером не может читать информацию.

Но вам следует изменить свое мнение о записи конфиденциальных данных в строку запроса . Он будет отображаться в истории браузера и отображается в адресной строке браузера и в журналах на сервере. См. Эту статью: Насколько безопасны строки запросов по HTTPS?

Если использование строк запроса является единственным вариантом (я сомневаюсь в этом), вот интересная статья о защите строк запроса .

5 голосов
/ 10 октября 2008

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

Однако для входа в форму входа потребуется ввод [type = text]. Потребовалась бы работа, чтобы «распаковать» это и превратить запрос в запрос HTTP GET, используя строки запроса, а не POST с данными в параметрах формы. Я не могу представить, почему кто-то сделал бы это. После того, как пароль был предоставлен пользователем (и пользователь аутентифицирован), используйте факт аутентификации, а не храните пароль. Если вам нужно сохранить пароль, для олицетворения, скажем, храните его на стороне сервера и желательно в защищенной строке. Если вы пытаетесь сделать единый вход (один раз введите мой идентификатор / пароль для многих сайтов), то используйте какую-либо службу центральной аутентификации (CAS) - OpenID, WindowsLive - или внедрите свою собственную.

Чем меньше раз пароль пересекает провод, тем лучше.

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

2 голосов
/ 10 октября 2008

Не существует «достаточно безопасного», безопасность - это не статичная вещь со свойством bool, которое имеет либо false, либо true.

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

Но если вы используете SSL, по крайней мере все передаваемые данные зашифрованы (за исключением целевого IP-адреса, поскольку он используется для маршрутизации вашего пакета).

Еще один момент, который следует учитывать: если вы введете строку запроса пароля вручную в браузере, она может оказаться в кеше локального браузера (в полностью незашифрованном локальном файле). Так что лучше используйте POST, а не GET Transfer Mechanics.

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

2 голосов
/ 10 октября 2008

согласен с тем, что SSL безопасен * ish и проблема строки запроса

помните, что существуют ограничения по SSL -

убедитесь, что сертификат является корневым.

на некоторых машинах с Windows 2000 должен быть установлен sp для работы 128-битного ssl, если его там нет, то он переходит к 40-битной или полной нагрузке (если я правильно помню)

Некоторые программные брандмауэры, такие как ISA, где вы публикуете защищенный сайт и подтверждаете его, действуют как человек посередине.

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

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

2 голосов
/ 10 октября 2008

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

SSL довольно безопасен, если вы занимаетесь интернет-банкингом и доверяете ему, тогда SSL тоже подойдет вам.

1 голос
/ 23 июля 2011
1 голос
/ 10 октября 2008

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

0 голосов
/ 13 марта 2009

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

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

Надеюсь, это поможет.

0 голосов
/ 10 октября 2008

Не следует ли отправлять хешированные пароли? - не бери в голову, если я ошибаюсь.

SSL - в значительной степени самая безопасная из всех, что вы можете получить.

0 голосов
/ 10 октября 2008

вы никогда не должны отправлять что-либо критически чувствительное, используя строки запроса!

...