Насколько безопасна отправка конфиденциальных данных через https?

Question

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

Answer 1

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

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

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

Answer 2

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

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

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

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

Answer 3

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

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

Answer 4

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

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

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

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

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

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

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

Answer 5

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

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

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

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

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

Answer 6

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

Answer 7

инспектор ssl может открывать трафик ssl http: // www.ssl-inspector.com/files/file/SSL%20Inspector%20Appliance%20Product%20Brief%20(2-11).pdf

Answer 8

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

Answer 9

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

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

Answer 10

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

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

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