Дайджест-аутентификация HTTP - PullRequest
14 голосов
/ 21 января 2010

Я хочу использовать HTTP Digest Authentication с центральной базой данных, в которой хранятся имена пользователей и зашифрованные пароли. Эти данные должны использоваться различными серверами, такими как Apache httpd или Tomcat, например. Клиентами будут люди с браузерами и другими приложениями, взаимодействующими RESTful.

Насколько я понимаю, я не мог использовать таблицу с хешированными паролями. Возможно хранить HA1 = MD5 (имя пользователя: realm: пароль) , если требуется пароль в виде открытого текста - правильно?

С другой стороны, представляется возможным использовать хешированные пароли с Apache httpd:

Apache httpd doc говорит:

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

Работает ли это с дайджест-аутентификацией? Нет параметра для указания алгоритма хеширования. Как Apache httpd решает, какой алгоритм использовать?

RFC 2617 говорит:

4.13 Хранение паролей

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

Похоже, пароль должен быть открытым текстом.

В спецификации Servlet 3.0 написано:

Хотя пароли не отправляются на провод, HTTP Digest аутентификация требует этого открытого текста пароля эквиваленты быть доступными для аутентификация контейнера так, чтобы он может проверить полученные аутентификаторы путем расчета ожидаемого дайджеста.

Что такое «эквивалент пароля с открытым текстом» здесь? Хэш пароля?

Документация Tomcat говорит:

При использовании переваренных паролей с DIGEST аутентификация, открытый текст используется для создания дайджеста разные. В приведенных выше примерах {cleartext-пароль} должен быть заменен с {Имя пользователя}: {область}: {зашифрованный текст-пароль}. Например, в разработке среда это может принять форму TestUser: локальный: 8080: testPassword

.

Здесь требуется простой текстовый пароль.

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

Должен ли пользователь повторно вводить свои учетные данные, если он запрашивает страницу из другого субдомена?

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

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

Ответы [ 2 ]

6 голосов
/ 21 января 2010

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

Я думаю, что лучшее решение для вас - создать страницу входа в систему и использовать сеансы файлов cookie для управления привилегиями пользователей. С этим решением вы получите ответ на другие вопросы:

  • Файл cookie можно настроить для использования между поддоменами: http://en.wikipedia.org/wiki/HTTP_cookie#Cookie_attributes
  • Сессия будет действительной до тех пор, пока пользователи не закроют браузер, не истечет время ожидания или пока пользователь не нажмет кнопку выхода из системы. Никогда не забывайте предлагать эту опцию своим пользователям !!!
0 голосов
/ 20 апреля 2014

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

и вам придется передавать имя пользователя и пароль в HTTP URL вместо обычной формы http://www.rojotek.com/blog/2008/05/19/http-authentication-in-a-url/

...