В чем разница между Digest и базовой аутентификацией?

http базовая аутентификация доступа

• Шаг 1 : клиент делает запрос на информацию, посылая имя пользователя и пароль передаются на сервер в виде обычного текста
• Шаг 2: сервер отвечает требуемой информацией или ошибкой

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

плюсы:

• его просто реализовать, поэтому у ваших разработчиков клиентов будет меньше работы и меньше времени для доставки, поэтому разработчики могут с большей вероятностью захотеть использовать ваш API
• в отличие от Digest, вы можете хранить пароли на сервере в любой метод шифрования, который вам нравится, например bcrypt, делает пароли более безопасными
• только один вызов на сервер необходим для получения информации, что делает клиент немного быстрее, чем более сложные методы аутентификации может быть

плюсы:

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

В Резюме - если у вас есть контроль над клиентами или вы можете гарантировать, что они используют SSL, HTTP Basic-хороший выбор. Медлительность SSL может быть отменена скоростью только одного запроса

синтаксис базовой аутентификации

Value = username:password
Encoded Value =  base64(Value)
Authorization Value = Basic <Encoded Value> 
//at last Authorization key/value map added to http header as follows
Authorization: <Authorization Value>

http Digest аутентификация доступа
Использование аутентификации Digest Access хеширование (i.e digest означает разрезать на мелкие кусочки) методологии для генерации криптографического результата. Http Digest access authentication-это более сложная форма аутентификации, которая работает следующим образом:

• Шаг 1 : клиент отправляет запрос на сервер
• Шаг 2 : сервер отвечает специальным кодом (называется nonce то есть nУмбра использовать только после), другую строку представляя realm(хэш) и просит клиента аутентифицировать
• Шаг 3 : клиент отвечает этим nonce и зашифрованной версией имени пользователя, пароля и области (хэш)
• Шаг 4 : сервер отвечает запрошенной информацией, если хэш клиента соответствует их собственному хэшу имени пользователя, пароля и области или ошибке, если нет

плюсы:

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

плюсы:

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

В Резюме, http Digest по своей сути уязвим по крайней мере для двух атак, в то время как сервер, использующий сильное шифрование для паролей с HTTP Basic over SSL, с меньшей вероятностью разделяет эти уязвимости.

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

синтаксис аутентификации доступа к дайджесту RFC 2069

Hash1=MD5(username:realm:password)
Hash2=MD5(method:digestURI)
response=MD5(Hash1:nonce:Hash2)

синтаксис аутентификации доступа к дайджесту RFC 2617

Hash1=MD5(username:realm:password)
Hash2=MD5(method:digestURI)
response=MD5(Hash1:nonce:nonceCount:cnonce:qop:Hash2)
//some additional parameters added 

источник и пример

в Postman выглядит следующим образом:

давайте посмотрим разницу между двумя адресу http проверка подлинности с помощью Wireshark (инструмент для анализа пакетов, отправленных или полученных) .

1. Базовая Аутентификация Http

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

вот как отправляются и принимаются пакеты:

В первом пакете клиент заполняет учетные данные, используя в должности метод на ресурсе -lab/webapp/basicauth .Взамен сервер отвечает кодом ответа http 200 ok ,я.е логин:пароль были правильными .

теперь , в Authorization заголовок показывает, что это Basic авторизация с последующей случайной строкой .Эта строка закодировано (Base64) версия учетных данных admin:aadd (включая двоеточие ) .

2 . Http Digest Authentication(rfc 2069)

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

вот пакеты, показывающие запросы, сделанные клиентом, и ответ от сервера .

как только клиент вводит учетные данные, запрашиваемые сервером , пароль превращается в response используя алгоритм, а затем отправляется на сервер, если база данных сервера имеет тот же ответ, что и клиент, сервер дает доступ к ресурсу, в противном случае 401 ошибка .

В вышеприведенном Authorization на response строка вычисляется с использованием значений Username,Realm,Password,http-method,URI и Nonce как показано на рисунке :

(двоеточия включены)

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