Вход в систему без HTTPS, как защитить?

HTTPS является абсолютно жизненно важным для поддержания безопасного соединения между веб-сайтом и браузером. Общедоступные сети Wi-Fi подвергают пользователей риску , и при правильном использовании HTTPS является единственным инструментом , который может защитить учетные записи пользователей от этой уязвимости .

Если ваш хост не поддерживает HTTPS, то можно использовать такую ​​службу, как Cloudflare Universal SSL , чтобы гарантировать, что все браузеры подключаются к вашему сайту по HTTPS, , даже если ваш сервер не поддерживает SSL. / TLS . Соединение между Cloudflare и вашим сайтом по-прежнему будет незащищенным, но этот сервис Cloudflare предназначен для защиты пользователей от угроз, обнаруженных в общедоступных сетях Wi-Fi. С точки зрения тестера на проникновение, отсутствие HTTPS вызывает большие подозрения. Если вы не обеспечиваете базовое требование безопасности, например доставку трафика, то каких еще требований безопасности вам не хватает? Сертификаты HTTPS можно получить бесплатно с помощью Let's Encrypt или Start SSL , нет никаких законных оснований не поддерживать HTTPS.

HTTPS жизненно важен, потому что он делает гораздо больше, чем просто «шифрует пароли». Другая важная роль заключается в том, что он должен предотвращать вход пользователя на злонамеренный сервер, выдающий себя за реальный сервер. Использование системы только для защиты пароля по-прежнему является нарушением OWASP A9 - Недостаточная защита транспортного уровня , потому что вы все равно будете передавать учетные данные сеанса в виде обычного текста, а это все, что нужно злоумышленнику ( Firesheep ]).

1. Криптография на основе JavaScript не может использоваться для создания безопасного транспортного уровня .

2. «Токенизация логинов»: если злоумышленник перехватывает трафик, он получит имя пользователя / пароль в виде обычного текста, а затем он сможет просто войти в систему с этими новыми учетными данными.(Атака с воспроизведением)

3. «Каким-то образом зашифровать переданный пароль»: после того, как человек вошел в систему злоумышленник может прослушать трафик, чтобы получить действительный идентификатор сеанса ( cookie), а затем просто используйте его вместо входа в систему. Если весь сеанс был защищен с помощью SSL / TLS, это не проблема.

Существуют и другие более сложные атаки, которые влияют как на эту систему, так и на нашу текущую инфраструктуру SSL. Атака SSLStrip рассматривается более подробно. Я настоятельно рекомендую посмотреть доклад Moxie Marlinspike's Blackhat 2009 , который ведет к стандарту HTTP-Strict-Transport-Security .

Вы можете использовать аутентификацию HTTP Digest , которая поддерживается большинством браузеров и не передает пароль в открытом виде по сети.

Обратной стороной является уродливое окно входа в систему, отображаемое браузером. Если вы предпочитаете использовать формы, вы можете реализовать тот же протокол, что и HTTP-дайджест, в аутентификации ваших форм: отправлять скрытые поля, содержащие область и задачу, и попросить клиента добавить в JavaScript одноразовый номер и вычислить дайджест. Таким образом, вы будете использовать хорошо известный и проверенный протокол обмена, а не использовать свой собственный.

Дайджест HTTP требует только хеш-операций.

Вы можете зашифровать пароль с помощью Javascript и расшифровать его на сервере.

Я бы порекомендовал создать пару ключей RSA на сервере, отправить открытый ключ вместе с синхронизированной солью в браузер, а затем зашифровать пароль в сочетании с солью, используя открытый ключ в Javascript.

Вы можете найти реализацию RSA в Javascript здесь

Вы должны включить как IP-адрес, так и весь хедер X-FORWARDED-FOR в файлы cookie аутентификации, чтобы предотвратить кражу файлов cookie за прокси-серверами. .

Если вы имеете дело с конфиденциальными данными, вы можете сгенерировать случайный ключ AES в Javascript , а затем отправить его на сервер вместе с паролем, зашифрованным с помощью RSA.
Затем вы можете заставить все приложение использовать зашифрованные запросы AJAX с одной страницы и вообще не использовать файлы cookie аутентификации.

Обратите внимание, что без SSL невозможно защититься от активной атаки типа «злоумышленник в середине». Активный злоумышленник может полностью заменить ваш сайт своим прокси-сервером, и от этого невозможно защититься. (Поскольку не может быть никакого известного хорошего кода)

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

Конечно, это не мешает хакерам изменить сообщение ... но защищает ваш пароль.

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

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

Итог - вам необходимо использовать HTTPS, чтобы гарантировать безопасность сайта.

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

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

В частности, я бы посоветовал вам использовать бесплатную стороннюю службу аутентификации, такую ​​как OpenID . У них есть библиотеки для PHP , включая одну для CakePHP .

Изменить: (о рисках)

Хотя использование сторонней службы безопасной аутентификации (которая использует сам HTTPS) может уменьшить проблему, выполняя аутентификацию без использования HTTPS (на вашем сервере), это не полностью исключает возможность атак.

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

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

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