Вход в личный кабинет Что требуется для работы аутентификации.
Чтобы наша аутентификация начала работать, потребуется создать 2 файла, один из которых чаще всего уже имеется – это файл .htaccess, если его нет, то необходимо его создать. В данном файле указываем следующие параметры:
Аутентификация и авторизация
Когда говорят об аутентификации, используя сокращение «auth», речь может идти об одном из двух следующих понятий:
При описании различий этих понятий я обычно использую аналогию из мира Unix. Аутентификация — это вход в систему с использованием имени и пароля. Авторизация — это разрешения на чтение, запись и выполнение, имеющие отношение к конкретным файлам и директориям.
Здесь мы уделим основное внимание аутентификации, так как это, в сравнении с авторизацией, понятие более фундаментальное, и так как прежде чем пользователя можно будет авторизовать, он должен пройти процедуру аутентификации. После того, как на сервере будет реализован механизм аутентификации, оснастить его системой авторизации обычно довольно просто, хотя то, как будет выглядеть система авторизации некоего проекта, очень сильно зависит от особенностей самого проекта.
Глава 4. аутентификация, часть 1
Аутентификация с помощью ключа API — это метод, который преодолевает слабость использования общих учетных данных, требуя доступа к API с помощью уникального ключа. В этой схеме ключ обычно представляет собой длинную последовательность букв и цифр, отличную от пароля для входа владельца учетной записи. Владелец дает ключ клиенту, так же как отель дает гостю ключ от одноместного номера.
Когда клиент аутентифицируется с помощью ключа API, сервер понимает, что можно разрешить клиенту доступ к данным, но теперь имеет возможность ограничить административные функции, такие как изменение паролей или удаление учетных записей. Иногда ключи используются просто, чтобы пользователю не приходилось выдавать свой пароль. Гибкость обеспечивается аутентификацией API Key для ограничения контроля, а также защиты паролей пользователей.
Итак, где же находится ключ API? Заголовок для него тоже есть, да? К сожалению, нет. В отличие от Basic Auth, который является установленным стандартом со строгими правилами, ключи API были разработаны в нескольких компаниях на заре интернета. В результате аутентификация с помощью ключа API немного похожа на дикий запад; у каждого свой способ делать это.
Однако со временем появилось несколько общих подходов. Один из них заключается в том, чтобы клиент поместил ключ в заголовок Авторизации вместо имени пользователя и пароля. Другой — добавить ключ в URL-адрес (http://example.com? api_key=my_secret_key ). Реже ключ закапывают где-нибудь в теле запроса рядом с данными. Куда бы ни пошел ключ, эффект будет одинаковым — он позволяет серверу аутентифицировать клиента.
Группы
Если к защищенной директории необходимо предоставить доступ множеству людей, удобнее всего разделить их на группы, в соответствии с которыми будет предоставлен доступ.
Дайджест-аутентификация (digest)
Дайджест-аутентификация – более безопасная и надежная альтернатива простой, но небезопасной базовой аутентификации.
Итак, как это работает?
Дайджест-аутентификация использует криптографическое хеширование MD5 в сочетании с использованием одноразовых номеров. Таким образом, информация о пароле скрывается для предотвращения различных видов злонамеренных атак.
Это может показаться немного сложным, но станет яснее, когда вы увидите, как это работает на простом примере.
Когда стоит использовать basic auth
По мне, ее стоит применять в двух случаях.
Первое, при разработке проекта, чтобы скрыть от посторонних глаз целый сайт или отдельный раздел.
Второе, в простой админке вроде упомянутого примера с лендингом.
Краткое резюме
Как видите, дайджест-аутентификацию сложнее понять и реализовать.
Она также более безопасна, чем обычная проверка подлинности, но все же уязвима для атаки “человек посередине”. RFC 2617 рекомендует использовать вместо этого дайджест-аутентификацию базовой аутентификации, поскольку она устраняет некоторые ее недостатки.
Итак, вкратце дайджест-аутентификация:
- Не отправляет пароли в виде обычного текста по сети.
- Предотвращает повторные атаки
- Защита от подделки сообщений
Некоторые из слабых мест:
- Уязвимость к атаке “человек посередине”.
- Многие параметры безопасности не требуются, и поэтому дайджест-проверка подлинности будет менее безопасной, если не задана.
- Предотвращает использование надежных алгоритмов хеширования паролей при хранении паролей.
В связи с этим дайджест-аутентификация пока не получила широкого распространения. Базовая аутентификация намного проще и в сочетании с SSL еще более безопасна, чем дайджест-аутентификация.
Области безопасности
Области безопасности предоставляют способ связать разные права доступа к разным группам ресурсов на сервере. Они называются защитными пространствами.
Фактически это означает, что в зависимости от ресурса, к которому вы хотите получить доступ, вам может потребоваться ввести разные учетные данные.
На сервере может быть несколько областей. Например, один может быть для статистической информации веб-сайта, доступ к которой имеют только администраторы веб-сайта. Другой вариант – изображения веб-сайтов, к которым другие пользователи могут получить доступ и загрузить изображения.
Плюсы и минусы базовой аутентификации
Из плюсов: простота и нативность реализации. Делается парой команд и обеспечивается средствами браузера.
Подробное объяснение
Давайте определим это:
Атрибут ответа рассчитывается следующим образом:
Пример digest authentication
1. Пользовательский клиент -> Сервер
Связанные с аутентификацией заголовки запросов/ответов
Сервер выдает запрос, используя заголовок ответа WWW-Authenticate. Он содержит информацию о протоколе и области безопасности.
После того, как клиент вводит учетные данные, запрос отправляется снова. На этот раз с заголовком авторизации, содержащим алгоритм и комбинацию имени пользователя и пароля.
Если учетные данные верны, сервер возвращает ответ и дополнительную информацию в необязательном заголовке ответа Authentication-Info.
Структура аутентификации запроса/ответа
Когда кто-то отправляет запрос, вместо того, чтобы немедленно ответить на него, сервер отправляет запрос клиенту. Он требует от пользователя предоставить подтверждение личности, введя секретную информацию (имя пользователя и пароль).
После этого запрос повторяется с использованием предоставленных учетных данных, и, если они верны, пользователь получает ожидаемый ответ. Если учетные данные неверны, сервер может повторно отправить запрос или просто отправить сообщение об ошибке.