Обсуждение:Дайджест-аутентификация
Эта статья тематически связана с вики-проектом «Информационные технологии», цель которого — создание и улучшение статей по темам, связанным с информационными технологиями. Вы можете её отредактировать, а также присоединиться к проекту, принять участие в его обсуждении и поработать над требуемыми статьями. |
Два вопроса править
1) Зачем нужен элемент "opaque"? В спецификации сказано, что это - заданная сервером строка, которую клиент должен вернуть без изменений. Можно было бы предположить, что этот элемент предназначен для хранения идентификатора сессии, однако элемент "nonce" подходит для этого лучше. В статье об этом ничего не сказано, а интересно было бы узнать. И что будет, если не указать "opaque"? В расчёте "response" он ведь не участвует.
2) Касательно преимуществ "более высокого уровня защиты" сравнительно с базовой аутентификацией: Насколько я понимаю, основным преимуществом считается отсутствие передачи пароля в открытом виде, т.е. защита от его перехвата третьими лицами. Но это преимущество исчезает, если используется соединение по SSL (а если достаточно сертификата на стороне сервера, то это не создаёт никаких неудобств для клиента). Зато появляется один неприятный недостаток, о котором многие не подозревают: Уязвимость к краже с сервера базы с идентификационными данными клиентов. Обычно с этим борются тем, что хранят в базе не пароли, а хэш от них. Здесь тоже можно хранить вместо пароля строку HA1=MD5(username:realm:password). Но хэширование по алгоритму MD5 не является хоть сколько-нибудь надёжным способом защиты пароля! Этот алгоритм имеет малую вычислительную сложность, а поэтому пароль по известному хэшу элементарно подбирается с помощью брут-форс метода (т.е. тупым перебором вариантов с проверкой). Для надёжного хэширования паролей существуют специальные алгоритмы, например, scrypt. Однако в случае дайджест-аутентификации мы не можем их применить! Потому что, не зная пароля, сервер может проверить аутентификацию пользователя только по HA1=MD5(username:realm:password).
В спецификации сказано, что с алгоритм хэширования можно явно указать с помощью элемента "algorithm". Однако неизвестно, поймёт ли софт клиента, если указать в качестве "algorithm" что-то другое, кроме MD5. К тому же, использование алгоритмов хэшировая с большой вычислительной сложностью (таких, как scrypt) - неудачное решение для аутентификации каждого запроса от клиентов, ибо это здорово загрузит сервер. Это было бы приемлемо только при открытии сессии, т.е. при первом входе клиента на сервер (когда он вводит логин и пароль), а значит при последующих запросах от клиента предпочтительным решением всё же является передача пароля на сервер в нехэшированном виде. Или передача только идентификатора сессии (как при стандартной cookie-аутентификации).
Мой сегодняшний вывод из всего этого таков: Реализованные на сегодняшний день механизмы http-аутентификации имеют ряд существенных неустранимых недостатков (у базовой атентификации тоже есть недостатки). К сожалению, основным недостатком стандартного механизма cookie-аутентификации является то, что если пользователь полностью отключил cookie, она не будет работать... Eugepros 11:09, 28 октября 2013 (UTC)
Написание термина править
Digest authentication по-русски должно писаться как «дайджест-аутентификация», т. е. через дефис, поскольку является сложным словом. Хорошо бы поправить как название статьи, так и везде по тексту. $tatic 06:42, 2 июля 2014 (UTC)
- Совершенно верно, коллега. Вы могли и сами исправить, а так ещё целый год провисело. Stas 19:53, 9 июля 2015 (UTC)