Используя Apache, довольно просто настроить страницу, использующую базовую аутентификацию доступа, чтобы запросить у пользователя имя/пароль и использовать эти учетные данные каким-то образом, чтобы предоставить доступ к этому пользователю.
Это безопасно, если соединение между клиентом и сервером безопасно?
Беспокойство по поводу базового auth заключается в том, что учетные данные отправляются в виде открытого текста и уязвимы к обнюханию пакетов, если это соединение защищено с использованием TLS/SSL, тогда оно столь же безопасно, как и другие методы, использующие шифрование.
Базовый auth через http в среде, которую можно обнюхать, не похож на auth, потому что пароль можно легко отменить, а затем повторно использовать. В ответ на забавный комментарий выше о кредитных картах по поводу того, что ssl "бит" более безопасен, проблема в том, что базовая аутентификация используется снова и снова по одному и тому же каналу. Если вы один раз нарушаете пароль, вы ставите под угрозу безопасность каждой транзакции по этому каналу, а не только один атрибут данных.
Если бы вы знали, что вы будете передавать один и тот же номер кредитной карты через веб-сессию снова и снова, я надеюсь, что вы придумали какой-то другой элемент управления, кроме как полагаясь на SSL, потому что вероятность того, что кредит номер карты, который часто будет скомпрометирован... в конце концов.
Как следует из самого имени, "базовая аутентификация" - это просто базовый механизм безопасности. Не полагайтесь на него, чтобы обеспечить вам безопасную защиту.
Использование SSL поверх него делает его более безопасным, но есть более эффективные механизмы.
Это старый поток, и я не верю, что самый высокий голос/ответ был правильным.
Как отметил @Nateowami, поток обмена файлами безопасности описывает ряд проблем с базовой аутентификацией.
Я хотел бы указать еще один: если вы правильно выполняете проверку пароля, базовая аутентификация делает ваш сервер более уязвимым для отказа в обслуживании. Зачем? В старые времена было распространено мнение, что соленого хэша было достаточно для проверки пароля. Это уже не так. В настоящее время мы говорим, что вам нужно иметь медленные функции, чтобы предотвратить грубые принудительные пароли в случае, когда база данных становится открытой (что происходит слишком часто). Если вы используете базовый auth, то вы вынуждаете ваш сервер выполнять эти медленные вычисления при каждом вызове API, что добавляет большую нагрузку на ваш сервер. Вы делаете его более уязвимым для DoS, просто используя этот устаревший механизм аутентификации.
В более общем плане, пароли имеют более высокое значение, чем сеансы: компрометация пароля пользователя позволяет неограниченно захватывать учетную запись пользователя, не говоря уже о возможности захвата других систем, к которым пользователь обращается из-за повторного использования пароля; тогда как сеанс пользователя ограничен временем и ограничен одной системой. Поэтому в целях углубленной защиты данные с высоким значением, такие как пароли, не должны использоваться повторно, если это не необходимо. Обычная проверка подлинности является устаревшей технологией и должна быть устаревшей.
Если вы создаете пароли с htpasswd, переходите к htdigest.
Дайджест-аутентификация защищена даже по незашифрованным соединениям, и ее так же легко настроить. Конечно, базовая аутентификация в порядке, когда вы переходите на ssl, но почему бы воспользоваться такой возможностью, когда вы могли бы просто использовать аутентификацию дайджеста?
Причина, по которой большинство сайтов предпочитает OAuth over Basic Auth, заключается в том, что Basic Auth требует, чтобы пользователи вводили свой пароль в стороннем приложении. Это стороннее приложение должно хранить пароль в открытом виде. Единственный способ отменить доступ - это изменение пользователем пароля. Это, однако, отменяет доступ для всех сторонних приложений. Итак, вы можете увидеть, что проблема здесь.
С другой стороны, OAuth требует веб-фрейма. Пользователь вводит свою регистрационную информацию на странице входа на этот конкретный сайт. Затем сайт генерирует токен доступа, который приложение может использовать для аутентификации в будущем. Плюсы: