Безопасный домен (HTTPS) абсолютно необходим для входа на страницу?

Question

Кажется, что большинство крупных веб-сайтов будут использовать защищенный домен, но есть несколько основных исключений, в частности, Facebook и Twitter.

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

Так как же таким крупным сайтам, как Facebook и Twitter, это сходит с рук? Если безопасный домен по какой-либо причине недоступен, какие дополнительные меры предосторожности можно предпринять?

Answer 1

Если безопасность вообще важна: Да, страница входа должна быть https, как и страница, на которую она публикует. Другого пути просто нет.

Если вы посещаете страницу, а это не https, вы абсолютно не можете доверять ничему, представленному с этой страницы. Поскольку соединение не защищено, его можно легко подделать (например, сделав отправку на не-https страницу, или, возможно, отправив на совершенно другой домен, который вы никогда не узнаете, пока он не станет слишком поздно). Принимая во внимание, что если вы посещаете страницу https, вы можете доверять ей. Вы знаете, откуда возникла страница и что она не была подделана. И, конечно, вы должны перейти на страницу https, так как вы хотите, чтобы эти данные были зашифрованы (а браузер должен предупредить вас, если он попытается отправить форму со страницы https * От 1009 * до (не https)).

Answer 2

Извините за поздний пост, но я не думаю, что кто-то из вышеперечисленных обратился к ключевому элементу того, как это делают Facebook и Twitter. Основная часть состоит в том, что их не входящие в HTTPS формы регистрации отправляют на абсолютный URL через HTTPS .

Посмотрите на действие:

// facebook
<form method="POST" action="https://login.facebook.com/login.php?login_attempt=1" id="login_form">

// twitter
<form method="post" id="signin" action="https://twitter.com/sessions">

В этом случае «действие» формы настроено на использование https и рукопожатие ssl. происходит до любые данные отправляются, поэтому соединение является безопасным. (Независимо от того, отображается ли оригинальная форма с использованием https, не имеет значения). Однако, если действие формы использовало относительный путь, то по умолчанию использовался протокол, который использовался для отображения формы. В итоге, вы должны использовать абсолютный URL, если вы хотите установить сеанс SSL перед отправкой ваших учетных данных.

Answer 3

Я, вероятно, буду опущен, но ответ на этот вопрос "абсолютно необходим", правильный ответ действительно должен быть "нет". В большинстве ситуаций это не имеет значения. Даже hotmail.com и другие крупные сайты имеют незашифрованные процессы входа, некоторые требуют, чтобы вы щелкнули ссылку, чтобы перейти на страницу https.

Это действительно зависит от того, что вы защищаете. Данные HIPPA, финансовая информация да абсолютно необходимы. Стандартный форум или другой сайт, на самом деле не имеет значения.

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

Answer 4

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

Я бы сказал, что какое-то шифрование должно быть обязательным для аутентификации. Что касается вопроса, да, HTTPS будет лучшим вариантом. Очевидно, что самой простой вещью, которую нужно проверить, является строка адреса вверху, если она начинается с "https://",, но это на самом деле не имеет значения. Важно то, куда отправляется ваша информация для аутентификации (имя пользователя / пароль), что может быть некоторые другие страницы через стандартные формы HTML или некоторую магию JavaScript. Лучший способ - проверить исходный код или включить предупреждения браузера относительно отправки незашифрованных данных.

НТН

Answer 5

Я не уверен, какие методы обычно используются, но любая информация, которая не сохраняется и только сравнивается (например, имя пользователя и пароль), может быть хеширована (например, SHA1 или MD5) на клиенте.

Однако для этого требуются сценарии на стороне клиента, которые могут быть отключены или иным образом недоступны. Может случиться так, что некоторые сайты не считают свою информацию достаточно чувствительной, чтобы требовать защищенной передачи (вам не следует отправлять какую-либо конфиденциальную информацию в Facebook, Twitter и т. Д.).