Существуют ли какие-либо жизнеспособные альтернативы "классической" аутентификации cookie? - PullRequest
11 голосов
/ 03 апреля 2009

Есть ли какой-либо способ (кроме проверки подлинности HTTP, который, как я понимаю, по своей сути небезопасен через Интернет?), Для "реального" веб-сайта, чтобы обрабатывать логины и аутентификацию, а не традиционный способ, использующий сеансовые куки?

Ответы [ 7 ]

6 голосов
/ 03 апреля 2009

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

Если вам нужно достойное объяснение того, как реализовать дайджест-проверку подлинности HTTP в вашем приложении, Пол Джеймс написал отличную статью об этом .

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

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

3 голосов
/ 03 апреля 2009

Базовая аутентификация HTTP совершенно безопасна при использовании с сайтом SSL (https://)), поскольку весь HTTP-трафик, включая учетные данные, будет зашифрован. Однако при использовании этого метода пользователям необходимо взаимодействовать с всплывающим окном аутентификации браузера. для входа на ваш сайт.

2 голосов
/ 03 апреля 2009

Чтобы было ясно, единственный РЕАЛЬНЫЙ способ сделать это - через HTTPS.

Но, поскольку я предполагаю, что это не вариант, и я также предполагаю, что вы ищете систему «полностью управляемого входа в систему», я продолжаю:




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

Проблемы с этим подходом:

  1. Атака воспроизведения все еще возможна.
  2. Только пользователи с включенным JavaScript смогут авторизоваться таким образом.




Другой подход - более сложный механизм «вызов / ответ»:

  1. Отправьте "Challenge" вместе со страницей входа.
  2. Рассчитать хеш стороны пароля + вызова клиента.
  3. Введите логин.
  4. Рассчитайте хэш пароля + запроса (которому НЕ ДОЛЖЕН доверять запрос страницы) на стороне сервера и сравните.

И проблемы с этим:

  1. Только пользователи с включенным JavaScript смогут авторизоваться таким образом.
  2. Пароль PLAINTEXT должен храниться на сервере для проверки ответа на запрос и должен быть зашифрован на диске или защищен иным образом.




Теперь, чтобы быть справедливым, проблема № 2 не так опасна, как кажется. Фактически, когда вы вместо этого используете аутентификацию HASH, сам хэш поднимается до уровня «ключа».



На этом этапе довольно безопасно использовать cookie для хранения случайно сгенерированного логина ReferrenceID, аналогичного их идентификатору сеанса, но сервер может захотеть зашифровать с использованием ссылающегося IP как части IV или KEY, чтобы другие пользователи не могли захватить ReferrenceID.

В любом случае, я надеюсь, что это немного определит направление вашего дизайна.

1 голос
/ 03 апреля 2009

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

Во-вторых, если вам нужно использовать HTTPS во всех случаях, чтобы сделать его безопасным, после этого вы получили базовый Auth, похожий материал, такой как "Digest" и "NTLM Auth".

1 голос
/ 03 апреля 2009

HTTP-аутентификация не небезопасна при использовании HTTP.

0 голосов
/ 03 апреля 2009

Использование SSL для шифрования в сочетании с HttpOnly Cookies для предотвращения XSS - ваш лучший выбор для использования файлов cookie. Я не собираюсь говорить, что это пуленепробиваемый, однако.

0 голосов
/ 03 апреля 2009

Когда вы используете https, вы также можете установить сертификат в браузере вашего клиента и убедиться в этом. myopenid предлагает это для своих учетных записей OpenID. У меня есть один, и он работает очень хорошо (с точки зрения клиента).

...