Что такое дайджест-аутентификация?

101

Чем дайджест-проверка подлинности отличается от обычной проверки подлинности, кроме отправки учетных данных в виде простого текста?

digest-authentication 
— Программное обеспечениеGeek
источник
1
Отличное объяснение от @Gumbo прямо здесь: stackoverflow.com/a/5288679/591487
— inorganik
2
То, что вы НИКОГДА не должны использовать. Не защищает пароль при передаче и требует, чтобы сервер хранил пароли в открытом виде.
— CodesInChaos
2
Дайджест действительно обеспечивает лучшую безопасность при передаче, чем обычная проверка подлинности для незашифрованного трафика, но он слаб. НАМНОГО безопаснее использовать вместо этого базовую аутентификацию в сочетании с SSL / TLS, потому что таким образом вы также можете хранить пароли на сервере в зашифрованном виде.
— rustyx 09

Ответы:

179

Основное отличие состоит в том, что не требуется отправлять имя пользователя и пароль по сети в виде открытого текста. Он также невосприимчив к повторным атакам, поскольку использует одноразовый номер с сервера.

Сервер дает клиенту одноразовый номер (nonce), который он объединяет с именем пользователя, областью, паролем и запросом URI. Клиент запускает все эти поля с помощью метода хеширования MD5 для получения хеш-ключа.

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

На стороне сервера тот же метод используется для генерации хэш-ключа, только вместо использования пароля, введенного в браузер, сервер ищет ожидаемый пароль для пользователя в своей пользовательской БД. Он ищет сохраненный пароль для этого имени пользователя, выполняет тот же алгоритм и сравнивает его с тем, что отправил клиент. Если они совпадают, доступ предоставляется, в противном случае он может отправить обратно 401 Unauthorized (без входа или неудачный вход) или 403 Forbidden (доступ запрещен).

Дайджест-аутентификация стандартизирована в RFC2617 . В Википедии есть хороший обзор :

Вы можете думать об этом так:

  1. Клиент делает запрос
  2. Клиент получает одноразовый номер от сервера и запрос аутентификации 401
  3. Клиент отправляет следующий массив ответов (имя пользователя, область, generate_md5_key (nonce, username, realm, URI, password_given_by_user_to_browser)) (да, это очень упрощено)
  4. Сервер берет имя пользователя и область (плюс он знает URI, запрашиваемый клиентом) и ищет пароль для этого имени пользователя. Затем он переходит и выполняет свою собственную версию generate_md5_key (nonce, username, realm, URI, password_I_have_for_this_user_in_my_db)
  5. Он сравнивает вывод generate_md5 (), который он получил, с тем, который отправил клиент, если они совпадают с тем, что клиент отправил правильный пароль. Если они не совпадают, отправленный пароль был неверным.
— Ян К.
источник
Хорошее объяснение. Являются ли имя пользователя и пароль для пользователя Windows? Откуда они берутся?
— SoftwareGeek
Это все, что пользователь вводит в браузер. Пароль должен соответствовать тому, что сервер сохранил для пароля этого пользователя. Скорее всего, это что-то конкретное для этого веб-приложения, а не ваш пароль Windows. Это очень сильно зависит от того, как создано веб-приложение.
— Ян С.
14
Этому ответу 6 лет, но я предполагаю, что все системы безопасности хранят пароли в формате соленого хэша. Нет и не должно быть способа получить исходный пароль из базы данных, делающий невозможной авторизацию дайджеста.
— Рамон де Кляйн
3
Если дайджест-хэш имени пользователя и пароля хранится в db вместо простых паролей, тогда все еще можно использовать дайджест-аутентификацию @RamondeKlein
— karakays
1
@BlueBockser Я думаю, что karakays означал, что вместо использования простого пароля хэш, полученный в результате объединения имени пользователя и его пароля, должен храниться на сервере при регистрации и вычисляться на стороне клиента перед аутентификацией. Это также можно сделать с помощью хеша пароля.
— logo_writer 01
14

Хэш учетных данных отправляется по сети.

HA1 = MD5(username:realm:password)

В Википедии есть отличная статья на эту тему

— Филип Фурье
источник
от клиента к серверу? Не могли бы вы предоставить шаги для взаимодействия? Статья в Википедии хороша, но мне нужно более подробное объяснение или пример.
— SoftwareGeek
Да, клиент генерирует хеш-значение и отправляет его на сервер. Статья в Википедии подробно описывает протокол, я предлагаю вам обратиться к нему для получения дополнительной информации.
— Филип Фури, 05
1

Единственный способ получить хэш HA1 учетных данных - это знать пароль. Сервер знает HA1, но не знает пароль, который его сгенерировал. Если HA1 был известен злоумышленнику, он мог проникнуть в систему. Так что это не передается по проводам. Перед этим выполняется дополнительный хэш на основе одноразового номера и т. Д., И это должно согласовываться с аналогичным расчетом, выполняемым на сервере. Таким образом, пока сервер сохраняет HA1 закрытым, система в безопасности.

— Крис Окли
источник
Это объяснение дайджест-аутентификации, при которой пароль не отправляется в виде обычного текста (как в случае с базовой
— аутентификацией
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.