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

http Basic Access Authentication

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

обычная проверка подлинности использует 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 Access Authentication
Использование дайджест-проверки подлинности доступа хеширование (т. е. дайджест означает нарезку на мелкие кусочки) методологии для генерации криптографического результата. Http Digest access authentication-это более сложная форма аутентификации, которая работает следующим образом:

• Шаг 1 : клиент отправляет запрос на сервер
• Шаг 2 : сервер отвечает специальным кодом (называется a nonce т. е. nУмбра использовать только после), другую строку представляя область(хэш) и просит клиента аутентифицировать
• Шаг 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 

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

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

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

1. Обычная Проверка Подлинности Http

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

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

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

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

2 . Http Digest Authentication(rfc 2069)

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

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

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

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

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

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