В сети Веб поддерживаются 3 типа аутентификации при клиент-серверных взаимодействиях:
Basic- базовая аутентификация, при которой имя пользователя и пароль передаются в заголовках http-пакетов. Пароль при этом не шифруется и присутствует в открытом виде в кодировке base64. Пароль может быть легко перехвачен при помощи сниффинга. Поскольку открытая передача пароля является небезопасной, то для обеспечения безопасности в данном случае необходимо использовать SSL.
Basic-процедура не позволяет контролировать количество неудачных попыток аутентификации. То есть позволяет «взламывать» защиту методом грубого подбора пароля (метод «грубой силы», англ. brute force).
Пример реализации basic-аутентификации на языке php:
<?php
if (!isset($_SERVER['PHP_AUTH_USER']))
{
Header ("WWW-Authenticate: Basic realm=\"Secured area - Authentication needed!\"");
Header ("HTTP/1.0 401 Unauthorized");
echo 'Вы нажали кнопку "ОТМЕНА", значит не хотите увидеть эту страницу...';
exit();
}
else {
if ($_SERVER['PHP_AUTH_USER'] != 'kda')
{
Header ("WWW-Authenticate: Basic realm=\"Secured area - No such user!\"");
Header ("HTTP/1.0 401 Unauthorized");
echo 'Вы нажали кнопку "ОТМЕНА" после того, как ввели неправильное имя пользователя...';
exit();
}
if ($_SERVER['PHP_AUTH_PW']!= 'pass')
{
Header ("WWW-Authenticate: Basic realm=\"Secured area - Wrong password!\"");
Header ("HTTP/1.0 401 Unauthorized");
echo 'Вы нажали кнопку "ОТМЕНА" после того, как ввели правильное имя пользователя но неправильный пароль...';
exit();
}
}
?>
<body>
<H1>Поздравляем! Вы получили доступ к защищенной странице, пройдя авторизацию.</H1>
</body>
Digest - дайджест-аутентификация, при которой пароль пользователя передается в хешированном виде. При этом для проверки пароля нехешированный пароль должен храниться на стороне сервера (в базе данных). Соответственно, методом атаки будет не сниффинг, а использование уязвимостей сервера.
Кроме того, возможна атака по принципу «человек посередине» (Man in the middle, MITM). При этом атакующему все равно, действительно ли это настоящий пароль или только хеш от него. Подключившись к каналу между контрагентами, атакующий осуществляет активное вмешательство в протокол передачи, удаляя, искажая информацию или навязывая ложную.
http://www.xakep.ru/post/27203/
http://www.deltann.ru/10/d-122008/p-89
Integrated - интегрированная аутентификация, при которой клиент и сервер обмениваются сообщениями для выяснения подлинности друг друга с помощью протоколов NTLM или Kerberos. Этот тип аутентификации защищен от перехвата удостоверений пользователей, поэтому для него не требуется протокол SSL. Только при использовании данного типа аутентификации можно работать по схеме http, во всех остальных случаях необходимо использовать схему https.
Cookie
Поскольку HTTP-сервер не помнит предыстории запросов клиентов, то каждый запрос обрабатывается независимо от других, и у сервера нет возможности определить, исходят ли запросы от одного клиента или разных клиентов.
Если сервер будет проверять TCP-соединения и запоминать IP-адреса компьютеров-клиентов, он все равно не сможет различить запросы от двух браузеров, выполняющихся на одной машине. И даже если допустить, что на компьютере работает лишь одна клиент-программа, то никто не может утверждать, что в промежутке между двумя запросами она не была завершена, а затем запущена снова уже другим пользователем.
Тем не менее, если вы когда-нибудь пользовались почтовым ящиком на mail.ru или на другом сервере, предоставляющем почтовые услуги пользователям Веб, вспомните, как вел себя клиент после того, как вы создали для себя почтовый ящик на сервере. Когда вы в следующий раз обратились с того же компьютера к mail.ru, вы, вероятно, заметили, что после загрузки веб-страницы ваше регистрационное имя уже отображалось в соответствующем поле ввода.
Такие сведения позволяет получить дополнительное средство под названием cookie. Механизм cookie позволяет серверу хранить информацию на компьютере клиента и извлекать ее оттуда.
Инициатором записи cookie выступает сервер. Если в ответе сервера присутствует поле заголовка Set-cookie, клиент воспринимает это как команду на запись cookie. В дальнейшем, если клиент обращается к серверу, от которого он ранее принял поле заголовка Set-cookie, помимо прочей информации он передает серверу данные cookie. Для передачи указанной информации серверу используется поле заголовка Cookie.
Назначение cookie:
· аутентификация пользователя;
· хранение персональных предпочтений и настроек пользователя;
· отслеживание состояния сессии доступа пользователя;
· идентификация пользователя в рейтинговых системах, счетчиках, системах баннерного показа, on-line голосованиях. Часто применяется как элемент защиты от так называемой «накрутки» счетчиков посещения
· ведение статистики о пользователях.
Таким образом, процедуру записи и получения cookie можно представить себе как своеобразный «запрос» сервера, инкапсулированный в его ответе клиенту.
Рассмотрим подробнее, какие данные передаются в поле заголовка Set-cookie и как они влияют на поведение клиента.
Пара имя = значение – именованные данные, сохраняемые с помощью механизма cookie. Эти данные должны храниться на клиент-машине и передаваться серверу в составе очередного запроса клиента.
Дата, являющаяся значением параметра expires, определяет время, по истечении которого информация cookie теряет свою актуальность. Если ключевое слово expires отсутствует, данные cooki e удаляются по окончании текущего сеанса работы браузера.
Значение параметра domain определяет домен, с которым связываются данные cookie. Чтобы узнать, следует ли передавать в составе запроса данные cookie, браузер сравнивает доменное имя сервера, к которому он собирается обратиться, с доменами, которые связаны с записями cookie, хранящимися на клиент-машине. Результат проверки будет считаться положительным, если сервер, которому направляется запрос, принадлежит домену, связанному с cookie. Если соответствие не обнаружено, данные cookie не передаются.
Путь, указанный в качестве значения параметра path, позволяет выполнить дальнейшую проверку и принять окончательное решение о том, следует ли передавать данные cookie в составе запроса. Помимо домена с записью cookie связывается путь. Если браузер обнаружил соответствие имени домена значению параметра domain, он проверяет, соответствует ли путь к ресурсу пути, связанному с cookie. Сравнение считается успешным, если ресурс содержится в каталоге, указанном посредством ключевого слова path, или в одном из его подкаталогов. Если и эта проверка дает положительный результат, данные cookie передаются серверу. Если параметр path в поле Set-Cookie отсутствует, то считается, что запись cookie связана с URL конкретного ресурса, передаваемого сервером клиенту.
Последний параметр, secure, указывает на то, что данные cookie должны передаваться по защищенному каналу.
Для передачи данных cookie серверу используется поле заголовка Cookie. Формат этого поля достаточно простой:
Cookie: имя=значение; имя=значение; ...
C помощью поля Cookie передается одна или несколько пар имя = значение. Каждая из этих пар принадлежит записи cookie, для которой URL запрашиваемого ресурса соответствуют имени домена и пути, указанным ранее в поле Set-cookie.
Куки будут невидимы до тех пор, пока не будет загружена следующая страница.
Куки обязаны быть удалены с теми же параметрами, с которыми были установлены.
