15. Положения о защите
Этот раздел предназначается, чтобы сообщить разработчикам приложений, информационным провайдерам, и пользователям ограничений безопасности в HTTP/1.1 как описано в соответствии с этим документом. Обсуждение не включает категорические решения показанных проблем, хотя оно действительно делает некоторые предложения для того, чтобы уменьшить угрозы безопасности.
15.1. Идентификация Клиентов
Схема аутентификации Basic не безопасный метод аутентификации пользователей, и при этом он в любом случае не защищает объект, который передан открытым текстом через физическую сеть, используемую как носитель. HTTP не препятствует тому, чтобы дополнительные схемы аутентификации и механизмы кодирования использовались, чтобы увеличить безопасность или суммирование расширений (например, схемы, чтобы использовать одноразовые пароли) к аутентификации Basic.
Самый серьезный недостаток в аутентификации Basic — то, что она заканчивается по существу передача открытого текста пароля пользователя по физической сети. Именно эта проблема Digest Authentication пытается обратиться.
Поскольку аутентификация Basic вовлекает передачу открытого текста паролей, он никогда не ДОЛЖЕН использоваться (без расширений), чтобы защитить чувствительную или ценную информацию.
Обычное использование аутентификации Basic в идентифицирующих целях — требование, чтобы пользователь предоставил имя пользователя и пароль как средство идентификации, например, в целях собрать точную статистику использования по серверу. Когда используется таким образом заманчиво думать, что нет никакой опасности в ее использовании, если незаконный доступ к защищенным документам не главное беспокойство. Это только правильно, если сервер выпускает и имя пользователя и пароль пользователям и в особенности не позволяет пользователю выбирать его или её собственный пароль.
Опасность возникает, потому что начинающие пользователи часто многократно используют отдельный пароль, чтобы избежать задачи поддержания множественных паролей.
Если сервер разрешает пользователям выбирать свои собственные пароли, то угроза не только незаконный доступ к документам относительно сервера но также и незаконный доступ к учетным записям всех пользователей, которые хотели использовать их пароль учетной записи. Если пользователям разрешают выбрать их собственный пароль, который также означает, что сервер должен поддержать файлы, содержащие (по-видимому зашифрованный) пароли. Многие из них могут быть паролями учетной записи пользователей возможно на отдаленных сайтах. Владелец или администратор такой системы могли очевидно взять на себя обязательства, если эта информация не сохранена безопасным видом.
Basic Authentication также уязвим для имитации поддельными серверами. Если пользователя можно привести, полагают, что он подключается к хосту, содержащему информацию, защищенную стандартной аутентификацией, когда фактически он подключается к враждебному серверу или шлюзу тогда, атакующий может запросить пароль, хранить его для более позднего использования, и симулировать ошибку. Этот type атаки не возможен с Digest Authentication [32]. разработчики Server ДОЛЖНЫ принять меры против возможности этого вида подделывания сценариями интерфейса компьютерной графики или шлюзами. В особенности очень опасно для сервера просто перевернуть подключение к шлюзу, так как тот шлюз может тогда использовать постоянный механизм подключения, чтобы участвовать во множественных транзакциях клиентом, олицетворяя оригинального сервера способом, который не является обнаруживаемым клиентом.