Прежде всего, попытайтесь понять, как работает аутентификация SSL (HTTPS) и HTTP.
Обычные методы HTTP-аутентификации (Digest, Basic и любые схемы аутентификации на основе форм + cookie, которые вы можете реализовать поверх HTTP) сами по себе небезопасны, поскольку они отправляют информацию аутентификации более или менее в виде открытого текста. Вне зависимости от того, находятся ли данные в полях или заголовках POST, и применяется ли кодировка base64, это не имеет никакого значения, пароль ясно виден любому, кто имеет доступ к сетевому трафику. Это означает, что HTTP-аутентификация по ненадежному каналу бесполезна: злоумышленнику, который прочитает ваш пароль, достаточно лишь немного понюхать сеть.
SSL реализует безопасный канал связи по изначально небезопасному каналу. Это работает примерно так:
- Сервер отправляет подписанный сертификат
- Клиент проверяет сертификат по списку известных ключей подписи; подписи сертификатов могут быть объединены в цепочку, так что каждый узел говорит: «Если подпись, которая подписывает меня, является хорошей, то и я тоже», но в конечном итоге цепочка должна быть преобразована в один из нескольких доверенных органов, предварительно настроенных на клиенте.
- Клиент использует открытый ключ шифрования сервера для отправки общего секрета
- Сервер расшифровывает общий секрет с помощью закрытого ключа (поскольку закрытый ключ имеет только законный сервер, другие серверы не смогут расшифровать общий секрет)
- Клиент отправляет фактические данные запроса, зашифрованные с использованием общего секрета
- Сервер расшифровывает данные запроса, затем отправляет зашифрованный ответ
- Клиент расшифровывает ответ и представляет его пользователю.
Обратите внимание на несколько важных моментов:
- Цепочка сертификатов позволяет клиентам удостовериться, что сервер, с которым они общаются, является реальным, а не кто-то перехватывает их запросы. Вот почему вы должны купить настоящий сертификат SSL, и почему браузеры выдают вам страшные предупреждения, когда вы заходите на сайт, который использует недействительный, просроченный или иным образом неверный сертификат: все шифрование в мире не поможет, если вы говорить не с тем человеком.
- Открытое / частное шифрование, используемое для обмена секретом, гарантирует, что успешное взаимодействие будет работать только между этой конкретной парой клиента и сервера: перехваченные сетевые пакеты будут зашифрованы, и им потребуется личный ключ сервера для получения данных.
- Симметричное шифрование используется для большей части запроса, потому что оно имеет гораздо меньшую нагрузку на производительность, чем шифрование с помощью закрытого / открытого ключа. Тем не менее, ключ (общий секрет) обменивается с использованием шифрования с закрытым / открытым ключом, поскольку это единственный способ сделать это безопасным способом (за исключением передачи его по отдельному каналу, такому как курьерская служба).
Очевидно, что это связано с некоторыми накладными расходами, но это не так плохо, как вы думаете - это в основном в масштабе, где «выбрасывать больше оборудования» является подходящим ответом, если вы не готовитесь к абсолютно огромным объемам трафика ( думаю гугл или фейсбук). При нормальных обстоятельствах, то есть при обычном использовании веб-приложения, издержки SSL незначительны, и, следовательно, как только у вас появятся какие-либо конфиденциальные данные, лучше всего просто запускать все через SSL, включая ресурсы. SSL также является единственным жизнеспособным способом защиты HTTP-трафика; другие методы просто не так стандартизированы и, следовательно, не получили широкой поддержки, и вы абсолютно не хотите реализовывать эти вещи самостоятельно, потому что, честно говоря, слишком легко их неправильно понять.
TL; DR: Да, SSL + Basic Authentication - хорошая идея, да, вам нужен защищенный сервер (и действительный сертификат ), да, это немного замедлит работу, но нет, это не то, о чем беспокоиться, верно Теперь.