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