Аутентификация пользователя в SSL-фрейме

Question

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

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

Вдобавок мне нужно будет получить выделенные серверы для моей службы.Это предлагаемое решение является временным до тех пор.

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

http://mydomain.com

эквивалентно

https://mydomain-com.secureserver.com

Myмысль должна иметь:

http://mydomain.com/login.php

... в котором iframe открывает страницу с защищенного сервера, что-то вроде этого:

<iframe src="http://mydomain-com.secureserver.com/ssllogin.php"></iframe>

• Я аутентифицирую пользователя вssllogin.php с (хэшированными + (для каждого пользователя - случайно посоленными)) паролями из базы данных.
• После правильной регенерации сеанса установите сеанс, проверяющий аутентификацию.
• Этот сеанс затем каким-то образом переноситсяи проверено на http://mydomain.com

Возможно ли достичь такого подхода?Будет ли это улучшением моей безопасности при входе в систему или просто перенесет «точку перехвата пароля» для злоумышленника на другой экземпляр?

Все отзывы приветствуются.

Answer 1

Вам не нужен фрейм.Просто сделайте действие формы входа, чтобы указать https://yourdomain.com/login.php.Там вы можете проверить правильность имени пользователя и пароля, а затем снова перенаправить на обычный http.

НО , это не на 100% безопасно.Тот факт, что вы отправляете имя пользователя и пароль через https, может помешать злоумышленнику или анализатору получить это.Но если позже вы вернетесь к обычному http, этот злоумышленник / перехватчик сможет перехватить сеанс любого вошедшего в систему пользователя, прослушивающего cookie-файлы сеанса этого пользователя.

Если вы хотите большей безопасности (не 100%,но больше, чем в предыдущем варианте), всегда оставайтесь в https для всех ресурсов (css, js, images, а не только для ваших файлов php / html) и даже обслуживайте страницу входа через https.

Для некоторыхрассуждения об этих пунктах см. firesheep (о проблемах с захватом сеанса) или недавней атаке Тунисское правительство на тунисских пользователей facebook / yahoo / gmail (для обслуживания даже страницы входа черезhttps).

edit : извините, я неправильно прочитал ваш вопрос.Если домен SSL отличается от домена не-ssl, у вас могут возникнуть проблемы, поскольку cookie-файл сеанса будет работать только с тем же доменом или поддоменами.Таким образом, если вы войдете в систему и отправите файл cookie сеанса с https://yourdomain.secure -server.com , браузер отправит его только на ваш домен.secure-server.com (или * .secure-server.com, если хотите), но не на yourdomain.com.Я думаю, что можно сделать файл cookie с подстановочными знаками действительным для всех поддоменов * .com, но лучше этого не делать (вы хотите, чтобы файлы cookie ваших пользователей отправлялись на evil.com?)