Как защитить аутентификацию, но не полезную нагрузку?

Question

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

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

Отредактировано, чтобы добавить:

Это для настольного клиента, взаимодействующего с веб-службой (без использования браузера).

Answer 1

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

Answer 2

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

Answer 3

Как насчет OpenID?Есть ли причина, по которой вам необходимо хранить аутентификационную информацию?

Отредактировано, чтобы добавить

Извините, не заметил, что это десктопное приложение.Как насчет OAuth?

Answer 4

Есть ли способ структурировать исходный URL-адрес запроса, чтобы указать пользователя?Затем сервер может ответить другой областью (действующей как «соль») для каждого пользователя в ответе аутентификации дайджеста HTTP.Например, запросите URL-адреса формы http://user.y.com/service или http://www.y.com/user/service приведет к ответу на вызов, например:

WWW-Authenticate: Digest realm="user@y.com", nonce="oqa9hvq49krprkphtqc"

---

Можете ли вы объяснить, что является причиной запрета на шифрование?Если вы подвергаетесь атакам «человек посередине», вам необходимо защитить целостность всего запроса.Там SSL был бы очень полезен.Если у вас абсолютно нет шифрования, будет ли приемлемым использование SSL с использованием незашифрованного набора шифров?