Методы идентификации пользователя в протоколе HTTP

 

Классификация методов аутентификации

В зависимости от степени доверительных отношений, структуры, особенностей сети и удаленности объекта проверка может быть односторонней или взаимной. Также различают однофакторную и строгую (криптографическую) аутентификации. Из однофакторных систем, наиболее распространенными на данный момент являются парольные системы аутентификации. У пользователя есть идентификатор и пароль, т.е. секретная информация, известная только пользователю (и возможно - системе), которая используется для прохождения аутентификации. В зависимости от реализации системы, пароль может быть одноразовым или многоразовым. Рассмотрим основные методы аутентификации по принципу нарастающей сложности.

Базовая аутентификация

При использовании данного вида аутентификации имя пользователя и пароль включаются в состав веб-запроса (HTTPPOST или HTTPGET). Любой перехвативший пакет, легко узнает секретную информацию. Даже если контент с ограниченным доступом не слишком важен, этот метод лучше не использовать, так как пользователь может применять один и тот же пароль на нескольких веб-сайтах. Опросы Sophos показывают, что 41% в 2006 г. и 33% в 2009 г. пользователей применяют для всей своей деятельности в Интернете всего один пароль, будь то сайт банка или районный форум. Также из недостатков парольной аутентификации следует отметить невысокий уровень безопасности – пароль можно подсмотреть, угадать, подобрать, сообщить посторонним лицам и т.д

Дайджест-аутентификация - аутентификация, при которой пароль пользователя передается в хешированном виде. Казалось бы, что по уровню конфиденциальности паролей этот тип мало чем отличается от предыдущего, так как атакующему все равно, действительно ли это настоящий пароль или только хеш от него: перехватив сообщение, он все равно получает доступ к конечной точке. Но это не совсем так - пароль хэшируется всегда с добавлением произвольной строки символов, которая генерируется на каждое соединение заново. Таким образом при каждом соединении генерируется новый хэш пароля и перехват его ничего не даст. Дайджест-аутентификация поддерживается всеми популярными серверами и браузерами.

HTTPS

Протокол HTTPS позволяет шифровать все данные, передаваемые между браузером и сервером, а не только имена пользователей и пароли. Протокол HTTPS (основанный на системе безопасности SSL) следует использовать в случае, если пользователи должны вводить важные личные данные — адрес, номер кредитной карты или банковские сведения. Однако использование данного протокола значительно замедляет скорость доступа.

Аутентификация по предъявлению цифрового сертификата

Механизмы аутентификации с применением цифровых сертификатов, как правило, используют протокол с запросом и ответом. Сервер аутентификации отправляет пользователю последовательность символов, так называемый запрос. В качестве ответа выступает запрос сервера аутентификации, подписанный с помощью закрытого ключа пользователя. Аутентификация с открытым ключом используется как защищенный механизм аутентификации в таких протоколах как SSL, а также может использоваться как один из методов аутентификации в рамках протоколов Kerberos и RADIUS.

Аутентификация по Cookies

Множество различных сайтов используют в качестве средства аутентификации cookies, к ним относятся чаты, форумы, игры. Если cookie удастся похитить, то, подделав его, можно аутентифицироваться в качестве другого пользователя. В случае, когда вводимые данные плохо фильтруются или не фильтруются вовсе, похитить cookies становится не очень сложным предприятием. Чтобы как-то улучшить ситуации используется защита по IP-адресу, то есть cookies сессии связываются с IP-адресом, с которого изначально пользователь ауторизовывался в системе. Однако IP-адрес можно подделать используя IP-спуфинг, поэтому надеяться на защиту по IP-адресу тоже нельзя. На данный момент большинство браузеров используют куки с флагом HTTPonly, который запрещает доступ к cookies различным скриптам.

Децентрализованная аутентификация

Одним из главных минусов таких систем является то, что взлом дает доступ сразу ко многим сервисам.

OpenID

Открытая децентрализованная система аутентификации пользователей. OpenID позволяет пользователю иметь один логин-пароль для различных веб-сайтов. Безопасность обеспечивается подписыванием сообщений. Передача ключа для цифровой подписи основана на использовании алгоритма Диффи — Хеллмана, также возможна передача данных по HTTPS. Возможные уязвимости OpenID:

· подверженфишинговым атакам. Например, мошеннический сайт может перенаправить пользователя на поддельный сайт OpenID провайдера, который попросит пользователя ввести его секретные логин и пароль.

· уязвим перед атакой человек посередине

Аутентификация по OpenID сейчас активно используется и предоставляется такими гигантами, как BBC, Google, IBM, MicrosoftMySpace, PayPal, VeriSign, Yandex и Yahoo!

OpenAuth

Используется для аутентификации AOL пользователей на веб-сайтах. Позволяет им пользоваться сервисами AOL, а также любыми другими надстроенными над ними. Позволяет проходить аутентификацию на сайтах, не относящихся к AOL, при этом не создавая нового пользователя на каждом сайте. Протокол функционирует похожим на OpenID образом. Также приняты дополнительные меры безопасности:

· данные сессии (в том числе информация о пользователе) хранятся не в cookies.

· cookies аутентификации шифруются алгоритмом 'PBEWithSHAAnd3-KeyTripleDES-CBC'

· доступ к cookies аутентификации ограничен определенным доменом, так что дрyгие сайты не имеют к ним доступа (в том числе сайты AOL)

OAuth

OAuth позволяет пользователю разрешить одному интернет-сервису получить доступ к данным пользователя на другом интернет-сервисе. Протокол используется в таких системах, как Twitter, Google (Google также поддерживает гибридный протокол, объединяющий в себе OpenID и OAuth)

Отслеживание аутентификации самим пользователем

Во многом безопасность пользователей в Интернете зависит от поведения самих пользователей. Так например, Google показывает с какого IP адреса включены пользовательские сесcии, логирует авторизацию, также позволяет осуществить следующие настройки:

· передача данных только по HTTPS.

· Google может детектировать, что злоумышленник использует ваш аккаунт (друзья считают ваши письма спамом, последняя активность происходила в нехарактерное для вас время, некоторые сообщения исчезли...)

· отслеживание списка третьих сторон, имеющих доступ к используемым пользователем продуктам Google

Зачастую пользователю сообщается с какого IP адреса он последний раз проходил аутентификацию.

Многофакторная аутентификация

Для повышения безопасности на практике используют несколько факторов аутентификации сразу. Однако, при этом важно понимать, что не всякая комбинация нескольких методов является многофакторной аутентификацией. Используются факторы различной природы:

Свойство, которым обладает субъект. Например, биометрия, природные уникальные отличия: лицо, отпечатки пальцев, радужная оболочка глаз, капиллярные узоры, последовательность ДНК.

Знание - информация, которую знает субъект. Например, пароль, пин-код.

Владение - вещь, которой обладает субъект. Например, электронная или магнитная карта, флеш-память.

В основе одного из самых надёжных на сегодняшний день методов многофакторной аутентификации лежит применение персональных аппаратных устройств - токенов. По сути, токен – это смарт-карта или USB-ключ. Токены позволяют генерировать и хранить ключи шифрования, обеспечивая тем самым строгую аутентификацию.

Использование классических «многоразовых» паролей является серьёзной уязвимостью при работе с чужих компьютеров, например в интернет-кафе. Это подтолкнуло ведущих производителей рынка аутентификации к созданию аппаратных генераторов одноразовых паролей. Такие устройства генерируют очередной пароль либо по расписанию (например, каждые 30 секунд), либо по запросу (при нажатии на кнопку). Каждый такой пароль можно использовать только один раз. Проверку правильности введённого значения на стороне сервера проверяет специальный сервер аутентификации, вычисляющий текущее значение одноразового пароля программно. Для сохранения принципа двухфакторности аутентификации помимо сгенерированного устройством значения пользователь вводит постоянный пароль.

 

Протокол FTP.

 

FileTransferProtocol (FTP) - сетевой протокол, предназначенный для передачи файлов в компьютерных сетях. Протокол FTP позволяет подключаться к серверам FTP, просматривать содержимое каталогов и загружать файлы с сервера или на сервер, кроме того, возможен режим передачи файлов между серверами.

Функции протокола FTP

- решение задач разделения доступа к файлам на удаленных хостах

- прямое или косвенное использование ресурсов удаленных компьютеров

- обеспечение независимости клиента от файловых систем удаленных хостов

- эффективная и надежная передачи данных.

Схемаработы FTP.

Простейшая схема работы протокола FTP представлена на рисунке 7. В FTP соединение инициируется интерпретатором протокола пользователя. Управление обменом осуществляется по каналу управления в стандарте протокола TELNET. Команды FTP генерируются интерпретатором протокола пользователя и передаются на сервер. Ответы сервера отправляются пользователю также по каналу управления. В общем случае пользователь имеет возможность установить контакт с интерпретатором протокола сервера и отличными от интерпретатора протокола пользователя средствами.

Рис.7. Простейшая схема работы протокола FTP

 

Команды FTP определяют параметры канала передачи данных и самого процесса передачи. Они также определяют и характер работы с удаленной и локальной файловыми системами.

Сессия управления инициализирует канал передачи данных. При организации канала передачи данных последовательность действий другая, отличная от организации канала управления. В этом случае сервер инициирует обмен данными в соответствии с согласованными в сессии управления параметрами.

Канал данных устанавливается для того же хоста, что и канал управления, через который ведется настройка канала данных. Канал данных может быть использован как для приема, так и для передачи данных.

 

Алгоритм работы протокола FTP:

Сервер FTP использует в качестве управляющего соединение на TCP порт 21, который всегда находится в состоянии ожидания соединения со стороны пользователя FTP.

После того как устанавливается управляющее соединение модуля “Интерпретатор протокола пользователя” с модулем сервера — “Интерпретатор протокола сервера”, пользователь (клиент) может отправлять на сервер команды. FTP-команды определяют параметры соединения передачи данных: роль участников соединения (активный или пассивный), порт соединения (как для модуля “Программа передачи данных пользователя”, так и для модуля “Программа передачи данных сервера”), тип передачи, тип передаваемых данных, структуру данных и управляющие директивы, обозначающие действия, которые пользователь хочет совершить (например, сохранить, считать, добавить или удалить данные или файл и другие).

После того как согласованы все параметры канала передачи данных, один из участников соединения, который является пассивным (например, “Программа передачи данных пользователя”), становится в режим ожидания открытия соединения на заданный для передачи данных порт. После этого активный модуль (например, “Программа передачи данных сервера”) открывает соединение и начинает передачу данных.

После окончания передачи данных, соединение между “Программой передачи данных сервера” и “Программой передачи данных пользователя” закрывается, но управляющее соединение “Интерпретатора протокола сервера” и “Интерпретатора протокола пользователя” остается открытым. Пользователь, не закрывая сессии FTP, может еще раз открыть канал передачи данных.

Основу передачи данных FTP составляет механизм установления соединения между соответствующими портами и выбора параметров передачи. Каждый участник FTP-соединения должен поддерживать порт передачи данных по умолчанию. По умолчанию “Программа передачи данных пользователя” использует тот же порт, что и для передачи команд (обозначим его “U”), а “Программа передачи данных сервера” использует порт L-1, где “L”- управляющий порт. Однако, участниками соединения используются порты передачи данных, выбранные для них “Интерпретатором протокола пользователя”, поскольку из управляющих процессов участвующих в соединении, только “Интерпретатор протокола пользователя” может изменить порты передачи данных как у “Программы передачи данных пользователя”, так и у “Программы передачи данных сервера”.

Пассивная сторона соединения должна до того, как будет подана команда “начать передачу”, “слушать” свой порт передачи данных. Активная сторона, подающая команду к началу передачи данных, определяет направление перемещения данных.

После того как соединение установлено, между “Программой передачи данных сервера” и “Программой передачи данных пользователя” начинается передача. Одновременно по каналу “Интерпретатор протокола сервера” — “Интерпретатор протокола пользователя” передаются уведомления о получении данных. Протокол FTP требует, чтобы управляющее соединение было открыто, пока по каналу обмена данными идет передача. Сессия FTP считается закрытой только после закрытия управляющего соединения.

Как правило, сервер FTP ответственен за открытие и закрытие канала передачи данных. Сервер FTP должен самостоятельно закрыть канал передачи данных в следующих случаях:

Сервер закончил передачу данных в формате, который требует закрытия соединения.

· Сервер получил от пользователя команду “прервать соединение”.

· Пользователь изменил параметры порта передачи данных.

· Было закрыто управляющее соединение.

· Возникли ошибки, при которых невозможно возобновить передачу данных.

 

Протокол SMTP.

 

SMTP (англ. SimpleMailTransferProtocol — простой протокол передачи почты) — это сетевой протокол, предназначенный для передачи электронной почты в сетях TCP/IP.

SMTP используется для отправки почты от пользователей к серверам и между серверами для дальнейшей пересылки к получателю. Для приёма почты почтовый клиент должен использовать протоколы POP3 или IMAP.

Данные передаются при помощи TCP, при этом обычно используется порт 25 или 587. При передаче сообщений между серверами обычно используется порт 25.

Чтобы доставить сообщение до адресата, необходимо переслать его почтовому серверу домена, в котором находится адресат. Для этого обычно используется запись типа MX (англ. MaileXchange — обмен почтой) системы DNS. Если MX запись отсутствует, то для тех же целей может быть использована запись типа A. Некоторые современные реализации SMTP-серверов для определения сервера, обслуживающего почту в домене адресата, также могут задействовать SRV-запись.

Сервер SMTP — это конечный автомат с внутренним состоянием. Клиент передает на сервер строку команда<пробел>параметры<перевод строки>. Сервер отвечает на каждую команду строкой, содержащей код ответа и текстовое сообщение, отделенное пробелом. Код ответа — число от 100 до 999, представленное в виде строки, трактующийся следующим образом:

· 2ХХ — команда успешно выполнена

· 3XX — ожидаются дополнительные данные от клиента

· 4ХХ — временная ошибка, клиент должен произвести следующую попытку через некоторое время

· 5ХХ — неустранимая ошибка

Текстовая часть ответа носит справочный характер и предназначен для человека, а не программы.

Изначально SMTP не поддерживал единой схемы авторизации. В результате этого спам стал практически неразрешимой проблемой, так как было невозможно определить, кто на самом деле является отправителем сообщения — фактически можно отправить письмо от имени любого человека. В настоящее время производятся попытки решить эту проблему при помощи спецификаций SPF, Sender ID, YahooDomainKeys. Единой спецификации на настоящий момент не существует.

 

Протокол доставки POP3.

 

POP3 (англ. PostOfficeProtocolVersion 3) — это сетевой протокол, используемый для получения сообщений электронной почты с сервера. Обычно используется в паре с протоколом SMTP.

Рис. 10. Схема «Клиент-сервер по протоколу POP3»

Описание протокола РОРЗ

Рассмотрим представленную на Рис. 10. схему «Клиент-сервер по протоколу POP3». Конструкция протокола РОРЗ обеспечивает возможность пользователю обратиться к своему почтовому серверу и изъять накопившуюся для него почту. Пользователь может получить доступ к РОР-серверу из любой точки доступа к Интернет. При этом он должен запустить специальный почтовый агент (UA), работающий по протоколу РОРЗ, и настроить его для работы со своим почтовым сервером. Итак, во главе модели POP находится отдельный персональный компьютер, работающий исключительно в качестве клиента почтовой системы (сервера). Подчеркнем также, что сообщения доставляются клиенту по протоколу POP, а посылаются по-прежнему при помощи SMTP. То есть на компьютере пользователя существуют два отдельных агента-интерфейса к почтовой системе - доставки (POP) и отправки (SMTP). Разработчики протокола РОРЗ называет такую ситуацию "раздельные агенты" (split UA). Концепция раздельных агентов кратко обсуждается в спецификации РОРЗ.

В протоколе РОРЗ оговорены три стадии процесса получения почты: авторизация, транзакция и обновление. После того как сервер и клиент РОРЗ установили соединение, начинается стадия авторизации. На стадии авторизации клиент идентифицирует себя для сервера. Если авторизация прошла успешно, сервер открывает почтовый ящик клиента и начинается стадия транзакции. В ней клиент либо запрашивает у сервера информацию (например, список почтовых сообщений), либо просит его совершить определенное действие (например, выдать почтовое сообщение). Наконец, на стадии обновления сеанс связи заканчивается. Далее перечислены команды протокола РОРЗ, обязательные для работающей в Интернет реализации минимальной конфигурации.

Команды протокола POP версии 3 (для минимальной конфигурации )

USER Идентифицирует пользователя с указанным именем

PASS Указывает пароль для пары клиент-сервер

QUIT Закрывает TCP-соединение

STAT Сервер возвращает количество сообщений в почтовом ящике плюс размер почтового ящика

LIST Сервер возвращает идентификаторы сообщений вместе с размерами сообщений (параметром команды может быть идентификатор сообщения)

RETR Извлекает сообщение из почтового ящика (требуется указывать аргумент-идентификатор сообщения)

DELE Отмечает сообщение для удаления (требуется указывать аргумент - идентификатор сообщения)

NOOP Сервер возвращает положительный ответ, но не совершает никаких действий

LAST Сервер возвращает наибольший номер сообщения из тех, к которым ранее уже обращались

RSET Отменяет удаление сообщения, отмеченного ранее командой DELE

В протоколе РОРЗ определено несколько команд, но на них дается только два ответа: +ОК (позитивный, аналогичен сообщению-подтверждению АСK) и -ERR (негативный, аналогичен сообщению "не подтверждено" NAK). Оба ответа подтверждают, что обращение к серверу произошло и что он вообще отвечает на команды. Как правило, за каждым ответом следует его содержательное словесное описание. В RFC 1225 есть образцы нескольких типичных сеансов РОРЗ. Сейчас мы рассмотрим несколько из них, что даст возможность уловить последовательность команд в обмене между сервером и клиентом.

Авторизация пользователя

После того как программа установила TCP-соединение с портом протокола РОРЗ (официальный номер 110), необходимо послать команду USER с именем пользователя в качестве параметра. Если ответ сервера будет +ОК, нужно послать команду PASS с паролем этого пользователя:

CLIENT: USER kcope ERVER: +ОК CLIENT: PASS secret SERVER: +ОКkcope'smaildrop has 2 messages (320 octets) (Впочтовомящикеkcopeесть 2 сообщения (320 байтов)...)

Транзакции РОРЗ

После того как стадия авторизации окончена, обмен переходит на стадию транзакции. В следующих примерах демонстрируется возможный обмен сообщениями на этой стадии.

Команда STAT возвращает количество сообщений и количество байтов в сообщениях:

CLIENT: STAT

SERVER: +ОК 2 320

Команда LIST (без параметра) возвращает список сообщений в почтовом ящике и их размеры:

CLIENT: LIST

SERVER: +ОК 2 messages (320 octets)

SERVER: 1 120

SERVER: 2 200

SERVER:....

Команда NOOP не возвращает никакой полезной информации, за исключением позитивного ответа сервера. Однако позитивный ответ означает, что сервер находится в соединении с клиентом и ждет запросов:

CLIENT: NOOP

SERVER: +ОК

Следующие примеры показывают, как сервер POP3 выполняет действия. Например, команда RETR извлекает сообщение с указанным номером и помещает его в буфер местного UA:

CLIENT: RETR 1 SERVER: +OK 120 octets SERVER: <the POPS server sends the entire message here> (РОРЗ-сервервысылаетсообщениецеликом) SERVER:......

Команда DELE отмечает сообщение, которое нужно удалить:

CLIENT: DELE 1

SERVER: +OK message 1 deleted... (сообщение 1 удалено) CLIENT: DELE 2 SERVER: -ERRmessage 2 alreadydeletedсообщение 2 ужеудалено)

Команда RSET снимает метки удаления со всех отмеченных ранее сообщений:

CLIENT: RSET

SERVER: +OK maildrop has 2 messages (320 octets)

(в почтовом ящике 2 сообщения (320 байтов))

Как и следовало ожидать, команда QUIT закрывает соединение с сервером:

CLIENT: QUIT SERVER: +OK dewey POP3 server signing off CLIENT: QUIT SERVER: +OK dewey POP3 server signing off (maildrop empty) CLIENT: QUIT SERVER: +OK dewey POP3 server signing off (2 messages left)

Обратите внимание на то, что отмеченные для удаления сообщения на самом деле не удаляются до тех пор, пока не выдана команда QUIT и не началась стадия обновления. В любой момент в течение сеанса клиент имеет возможность выдать команду RSET, и все отмеченные для удаления сообщения будут восстановлены.