Безопасная аутентификация без SSL

Question

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

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

Существуют ли разумные варианты защиты сайта без SSL? Я думал о вариантах аутентификации:

1. Реализация соленого хэша в JavaScript. Когда страница входа будет загружена, создайте солевой сервер. Отправьте его клиенту в открытом виде и сохраните в переменной сеанса.

2. Дайджест-аутентификация. Я только что нашел эту идею, просматривая SO, и это, вероятно, намного более разумно, чем использование моей собственной аутентификации.

3. OpenID. Это открытый стандарт, пароли не требуются (и я могу «взломать» SSL моего провайдера OpenID, чтобы повысить безопасность процесса входа в систему), но я понятия не имею, как работает OpenID или насколько он безопасен. (Требуется исследование. Например, можно ли воспроизвести аутентификацию OpenID?)

Проблема со всем этим в том, что:

• Сессии могут быть угнаны
• Безопасен только логин, все остальное в открытом виде

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

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

Что бы вы сделали в такой ситуации?

Answer 1

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

Если вам просто нужна простая аутентификация без реальной безопасности, ваш провайдер, вероятно, будет поддерживать HTTP Basic. Это (наряду с хорошим дизайном, который ограничивает возможности и резервные копии;) является разумным временным решением, когда вы беспокоитесь о других проблемах.

Для аутентификации вашей личности OpenID не может быть воспроизведен. Каждая последовательность аутентификации подписана. Тем не менее, OpenID сам по себе позволяет только установить вашу личность с сервером. Это не позволит вам подписать или иным образом подтвердить подлинность запроса. OAuth будет, но для части протокола требуется шифрование транспорта.

Вы можете подписывать каждый запрос общим секретом. Это предотвратит отправку или повторный запрос злоумышленником, но сами запросы все еще могут быть прочитаны перехватчиком. См. Документацию для аутентификации Amazon AWS (которая включает в себя клиентские библиотеки) или аутентификации flickr. Основной протокол:

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

Answer 2

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

Answer 3

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