Аутентификация Digest

В этой статье будет рассмотрен алгоритм Digest аутентификации, решающей некоторые проблемы, имеющиеся у HTTP Basic Authentication. Например эта схема не передаёт password по сети открытым текстом. Официальное название схемы — «Digest Access Authentication».

Расширим нашу систему из предыдущей статьи.

К преимуществам Digest можно отнести следуещее:

1. passwords не передаются открыто по сети
2. способность защиты от повторяющихся атак (monitoring http nc value)
3. способность создать защиту (monitoring nonce)
   • в определённый промежуток времени
   • от определённого client
   • от определённого request

Один сайт может одновременно использовать несколько систем защиты, например Basic и Digest

Пришло время рассмотреть работу алгоритма Digest аутентификации:

1. Первый запрос от User Agent к Http Server заголовок Authorization пустой — значит server должен возвратить запрос на аутентификацию. Например такой:

2. ответ сервера:

HTTP/1.1 401 Unauthorized
        WWW-Authenticate: Digest
                 realm="testrealm@host.com",
                 qop="auth",
                 nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
                 opaque="5ccc069c403ebaf9f0171e9517f40e41",
                 algorithm=MD5,
                 stale=false

Разберём заголовок WWW-Authenticate (как вы заметили, он усложнился по сравнению с заголовком Basic):

3. У юзера всплывает модальное окно, предлагающее ввести username и password (обратите внимание, окно отличается от Basic окна). Происходит запрос юзера для аутентификации:

GET ... ... HTTP/1.1
        Authorization: Digest
                 username="Mufasa",
                 realm="testrealm@host.com",
                 nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
                 uri="/dir/index.html",
                 qop=auth,
                 nc=00000001,
                 cnonce="0a4f113b",
                 response="6629fae49393a05397450978507c4ef1",
                 opaque="5ccc069c403ebaf9f0171e9517f40e41"

Теперь разберём заголовок Authorization:

4. Последовательность обработки запроса пользователя

1. Проверяем, существует ли заголовок Authorization
2. Проверяем, является ли он Digest
3. Отсекаем слово Digest
4. Берём username (обратите внимание — в заголовке отсутствует password — по крайней мере его не видно)
5. проверяем базу данных с этим юзером, существует ли он — запоминаем его password из базы
6. проверяем запрос по ролям против страниц с ролями, как мы уже делали в Basic.

Если что-то не так — переходим к пункту 6. Если всё ok — идём дальше (это ещё далеко не всё :))

5. Проверка пароля пользователя

1. создаём строку A1 вида
   A1 = unq(username) : unq(realm) : passwd
2. хешируем A1
   HA1 = MD5(A1)
3. создаём строку A2 вида
   A2 = Http Method «:» digest-uri
4. хешируем A2
   HA2 = MD5(A2)
5. создаём строку GENRESPONSE вида
   GENRESPONSE = HA1 «:» nonce «:» nc «:» cnonce «:» qop «:» HA2
6. хешируем GENRESPONSE
   HGENRESPONSE = MD5(GENRESPONSE)

если HGENRESPONSE равен response в заголовке Authorization запроса юзера и nonce в порядке — всё ok, нет — переходим к пункту 6

6. выдаём состояние ответа сервера 401, поднимающее модальное окно как в пункте 2 иначе говоря формируем WWW-Authenticate по типу Digest