Дайджест-аутентификация HTTP

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

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

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

http://httpd.apache.org/docs/2.2/mod/mod_authn_dbd.html говорит:

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

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

В RFC 2617 говорится:

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

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

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

В спецификации сервлета 3.0 говорится:

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

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

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

При использовании переваренных паролей с аутентификацией ДАЙДЖЕСТ открытый текст, используемый для создания дайджеста, отличается. В приведенных выше примерах {cleartext-password} необходимо заменить на {username}: {realm}: {cleartext-password}. Например, в среде разработки это может иметь форму testUser: localhost: 8080: testPassword.

Требуется пароль в виде открытого текста.

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

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

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

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


person deamon    schedule 21.01.2010    source источник


Ответы (2)


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

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

  • Файл cookie можно настроить для использования между субдоменами: http://en.wikipedia.org/wiki/HTTP_cookie#Cookie_attributes
  • Сеанс будет действителен до тех пор, пока пользователи не закроют браузер, не истечет время ожидания или пока пользователи не нажмут кнопку выхода. Никогда не забывайте предлагать эту возможность своим пользователям !!!
person Pedro Laguna    schedule 21.01.2010
comment
Я использую md5 для хеширования паролей в моей базе данных, можно ли использовать дайджест-аутентификацию? - person vrunoa; 04.05.2014

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

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

person user3296005    schedule 20.04.2014