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

     Базовая аутентификация - это, пожалуй, самый простой ме­тод аутентификации, при котором клиент вводит имя пользователя и пароль на сервере, клиент посылает серверу эту информацию (эта информация размещается в специальный аутентифицирующий заголовок).

Содержимое заголовка кодируется с помощью алгоритма Base-64 - очень простого алгоритма, который практически всегда используется в MIME-(Multipurpose Internet Mail Extension) сообщениях электронной почты. Закодированная данным методом (Base-64) информация очень просто рас­кодируется, поэтому не надо надеяться на то, что Base-64 защитит от перехвата пароля.

     Ниже показана пересылка с употреблением базовой аутентификации.

     В первую очередь клиент запрашивает URL (шаг 1). Сервер отвечает ему сообще­нием 401 Unauthorized (шаг 2), оповещающим клиента о том, что он не авторизирован для доступа к этой области (к какой именно - тоже говорится в этом сообщении, потому что на сервере могут быть защищенные области).

     В сообщении тоже определяем метод аутентификации (в этом случае - ба­зовая). После этого (шаг 3) клиент еще раз запрашивает нужный ему URL, но теперь к запросу он добавляет аутентифицирующий заголовок. Если клиент написал правильные имя сервера и пароль, сервер возвращает клиен­ту запрошенный URL (шаг 4).

     Базовая аутентификация не представляется безопасным методом аутентифика­ции пользователей. Как уже было отмечено, Base-64 очень просто расшифровать, поэтому нужно считать, что имя пользователя и пароль транслируются по сети в открытом виде. Да, в сети, скорее всего, никто перехватывать па­роль не будет, но через сколько транзитных сетей пройдет запрос клиента, прежде чем попадет к серверу? В каждой из этих сетей трафик клиента сервера может быть перехвачен и декодирован.

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

     Digest-аутентификацию.

     Преимущества этого метода, перед ранее рассмотренным, заключаются в следующем:

• Пароли никогда не передаются в открытом виде.
• Реализована защита от атаки повтора. Гарантируется целостность тела сообщения.

     Пересылаемый пароль шифруется с помощью алгоритма MD5. Зашифрованный с помощью MD5 пароль нельзя декодировать. Сервер создает контрольную сумму MD5 для пароля пользователя, который хра­нится в его базе данных, и сравнивает ее с полученной контрольной суммой. Если они совпадают, значит, совпадают и пароли, поэтому пользова­телю предоставляется доступ.

     Применение алгоритма MD5 помогает решить проблему перехвата пароля, но не снимает главной проблемы - атаки повтора. Для решения этой проблемы Digest-аутентификация применяет специальные токены, которые называются моментами (nonces).

     Значение момента может изменяться в зависимости от времени. Когда сервер отправляет клиенту запрос (сообщение 401), он добавляет момент в свой заголовок.

     Клиент присоединяет момент к паролю и создает MD5-хеш по этой собранной строке (пароль+момент). Полученный таким образом MD5-хеш посылается обратно серверу. Как было замечено раньше, сервер создает свой хэш (свою контрольную сумму), при этом он использует ожидаемый пароль и пере­данный клиенту момент.

     Сгенерированный хэш он сравнивает с хэшем, полученным от клиента. Этот механизм намного сокращает возможность атаки повтора, так как момент - на то он и момент - действителен на протяжении очень малого промежутка времени и зависит от IP-адреса. Несмотря на преимущества, digest-аутентификация использует­ся в кои веки раз, так как она очень уж медленная. Так как Basic-аутентификацию употреблять в некоторых случаях (например, для доступа к банковской системе) недопустимо, для аутентификации пользователя и шифрова­ния данных применяется протокол HTTPS (Secure HTTP - безопасный HTTP), дающий простоту базовой аутентификации и обеспечи­вающий безопасность данных с помощью SSL.

     Например, кредитных карточек, причем пересылается не один номер время от времени, а сотни тысяч номеров в день. Задача шифрования таких важных данных возложена на плечи протокола HTTPS - это безопасная версия протокола HTTP.

     Протокол HTTPS для кодирования может употреблять SSL (Secure Sock­ets Layer) или TLS (Transport Layer Security). TLS представляется более актуальным (и предпочтительным) методом, но в настоящее время SSL больше распространен. Общепринято употреблять термин SSL, даже когда речь идет о TLS (всегдабудет употребляться термин SSL, чтобы не было путаницы).

     Причина популярности SSL - простота его применения. Кодирование данных выполняется отдельной SSL-библиотекой. Когда браузер пыта­ется послать данные по безопасному соединению, он передает эти данные идентичной функции из SSL-библиотеки: за передачу самих данных отвечает SSL-функция.

     Для Web-дизайнера нет никакой разницы между кодингом страницы для HTTP или HTTPS - он пишет страничку как обычно, а проблема безопас­ности данных возложена на HTTPS.

     Однако сама HTTPS-транзакция отличается от обычной HTTP-транзакции. На рисунке ниже показано, что прежде всего клиент подключается к 443-му ТСР-порту сервера. Затем начинается стадия обмена SSL-параметрами: клиент и сервер обмениваются информацией о версии протокола, об применяемом шифре, аутентифицируют друг друга и создают временные ключи сессии.

     Перед закрытием TCP-соединения обе стороны тоже должны послать уведомление о закрытии SSL-данных. На данной стадии есть пробле­ма: обмен ключами во время установки безопасного соединения происхо­дит по небезопасной среде (по Интернету). Если злоумышленник перехватит ключи, в последующем кодировании посылаемых данных не будет смысла.

     Решением этой проблемы стало создание криптографии с открытым клю­чом (Public Key Cryptography, РКС). Хотя РКС и дает необходи­мую безопасность, но работает очень медленно. Поэтому позже был создан и теперь активно применяется алгоритм RSA (Rivest Shamir Adleman), названный по первым буквам его создателей: Рон Райвест (R. Rivest), Ади Шамир (A. Shamir) и Леонард Аделман (L. Adleman). RSA ощутимо быстрее РКС.