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

101

Чим автентифікація дайджесту відрізняється від базової автентифікації, окрім надсилання облікових даних у вигляді простого тексту?

digest-authentication

— SoftwareGeek
джерело

Велике пояснення по @Gumbo прямо тут: stackoverflow.com/a/5288679/591487

— inorganik

Щось, що вам НІКОЛИ не слід використовувати. Не захищає пароль під час транзиту і вимагає від сервера зберігання паролів у простому режимі.

— CodesInChaos

Дайджест забезпечує кращу безпеку під час транзиту, ніж автентифікація Basic для незашифрованого трафіку, але він слабкий. Набагато безпечніше використовувати Basic auth в поєднанні з SSL / TLS, тому що ви також можете зберігати паролі на сервері в зашифрованому вигляді.

— rustyx

Відповіді:

179

Основна відмінність полягає в тому, що він не вимагає надсилання імені користувача та пароля через провід у простому тексті. Він також захищений від повторних атак, оскільки використовує одноразовий номер із сервера.

Сервер надає клієнтові номер одноразового використання (без позначення), який він поєднує з іменем користувача, цариною, паролем та запитом URI. Клієнт запускає всі ці поля методом хешування MD5 для створення хеш-ключа.

Він надсилає цей хеш-ключ на сервер разом із ім'ям користувача та цариною для спроби автентифікації.

На сервері той самий метод використовується для створення хешкею, лише замість використання пароля, введеного у браузер, сервер шукає очікуваний пароль для користувача з його БД користувача. Він шукає збережений пароль для цього імені користувача, працює через той же алгоритм і порівнює його з тим, що надіслав клієнт. Якщо вони збігаються, то доступ надається, інакше він може надіслати назад 401 Несанкціонований (відсутність входу або помилка входу) або 403 Заборонено (доступ заборонено).

Перевірка автентичності стандартизована в RFC2617 . У Вікіпедії є хороший огляд його :

Ви можете подумати про це так:

Клієнт робить запит
Клієнт отримує повернення від сервера і запит на аутентифікацію 401
Клієнт відправляє назад такий масив відповідей (ім'я користувача, область, generator_md5_key (ні, ім'я користувача, ім'я, область, URI, password_given_by_user_to_browser)) (так, це дуже спрощено)
Сервер бере ім'я користувача та область (плюс він знає URI, який запитує клієнт), і він шукає пароль для цього імені. Тоді він переходить і робить свою власну версію create_md5_key (ні, ім'я користувача, область, URI, пароль_I_have_for_this_user_in_my_db)
Він порівнює вихідний файл generator_md5 (), який він отримав, з тим, який надіслав клієнт, якщо вони відповідають клієнту, який надіслав правильний пароль. Якщо вони не відповідають, надісланий пароль був неправильним.

— Ян Ч.
джерело

Приємне пояснення. Чи є ім’я користувача & pwd для користувача Windows? Звідки вони породжені?

— SoftwareGeek

Вони не залежать від того, який користувач набере в браузері. Пароль повинен відповідати тому, що сервер зберігав пароль для цього користувача. Швидше за все, це щось специфічне для цього веб-додатка, а не ваш пароль Windows. Це дуже залежить від способу збирання веб-додатків.

— Ян C.

Цій відповіді вже 6 років, але я думаю, що всі системи, що знають про безпеку, зберігають паролі у форматі солоного хешу Не існує і не повинно бути жодного способу отримання оригінального пароля з бази даних, що робить неможливим авторизацію дайджесту.

— Рамон де Кляйн

Якщо дайджест хешу імені користувача та пароля зберігається в db замість простих паролів, тоді все одно можна використовувати дайджест auth @RamondeKlein

— karakays

@BlueBockser Я думаю, що karakays означав, що замість простого пароля хеш, отриманий в результаті поєднання імені користувача, і його пароля, повинен зберігатися на сервері під час реєстрації та обчислюватися на стороні клієнта перед автентифікацією. Це також можна зробити лише за допомогою хешу пароля.

— logo_writer

Хеш облікових даних надсилається по дроту.

HA1 = MD5(username:realm:password)

У Вікіпедії є чудова стаття на цю тему

— Філіп Фурі
джерело

від клієнта до сервера? Чи можете ви надати кроки для взаємодії? Стаття у Вікіпедії хороша, але мені потрібно краще пояснення чи приклад.

— SoftwareGeek

Так, клієнт генерує хеш-значення і відправляє його на сервер. Стаття у Вікіпедії докладно описує протокол, я пропоную вам ознайомитись для отримання додаткової інформації.

— Філіп Фурі

Єдиний спосіб отримати хеш HA1 облікових даних - це знати пароль. Сервер знає HA1, але не пароль, який його створив. Якщо HA1 був відомий зловмиснику, він міг би потрапити до системи. Так воно не направляється вниз по дроту. Попередній хеш на основі nonce тощо робиться перед цим, і це має узгоджуватися з аналогічним розрахунком, зробленим на сервері. Таким чином, поки сервер зберігає HA1 приватним, система захищена.

— Кріс Оклі
джерело

Це пояснення для дайджесту аутентифікації, коли пароль не надсилається у простому тексті (що стосується Basic Auth)

— Ерік Оппедійк