Off: а ведь всё-равно не догоняю... =(

Sergey M. 25.04.2004 17:09

с Basic авторизацией всё более-менее понятно - пароль передаётся по сети и приходит на сервер в оригинальном виде (Base64 не в счёт), даже если кто-то спёр файлик с паролями - там он найдёт только криптованные экземпляры, которые подставлять в запрос нет смысла.

В варианте Digest что-то совершенно непонятное - в приведённом в документации примере откуда-то достаётся некриптованный пароль:

A1 = unq(username-value) ":" unq(realm-value) ":" passwd

   where

passwd = < user's password >

откуда он достаётся некриптованный, если на сервере мы храним только "результат надёжного однозначного необратимого преобразования (хеш)"?

Ладно, допустим в passwd у нас этот самый хэш, тогда для успешного сравнения на клиенте тоже должен быть хэш пароля (HGENRESPONSE равен response в заголовке Authorization запроса юзера). НО, в таком случае, что мешает спереть файлик с паролями, достать из него хеш пароля нужного юзера и сформировать актуальный response на клиентской стороне?

Я понимаю что на самом деле всё не так плохо - метод ведь рабочий, все его хвалят, по крайней мере утверждают что он гораздо надёжнее чем Basic, т.е. судя по всему я что-то где-то упустил... Но что? Где? Не сходится-то на уровне логики, а не на уровне технической реализации... Намекните, ежели кто в курсе, пожалста.

---