Что не является аутентификацией
Аутентификация
Учитывая степень доверия и политику безопасности систем, проводимая проверка подлинности может быть односторонней или взаимной. Обычно она проводится с помощью криптографических методов.
Аутентификацию не следует путать с авторизацией [2] (процедурой предоставления субъекту определённых прав) и идентификацией (процедурой распознавания субъекта по его идентификатору).
Содержание
История
С древних времён перед людьми стояла довольно сложная задача — убедиться в достоверности важных сообщений. Придумывались речевые пароли, сложные печати. Появление методов аутентификации с применением механических устройств сильно упрощало задачу, например, обычный замок и ключ были придуманы очень давно. Пример системы аутентификации можно увидеть в старинной сказке «Приключения Али́-Бабы́ и сорока разбойников». В этой сказке говорится о сокровищах, спрятанных в пещере. Пещера была загорожена камнем. Отодвинуть его можно было только с помощью уникального речевого пароля: «Сезам, откройся!».
В настоящее время в связи с обширным развитием сетевых технологий, автоматическая аутентификация используется повсеместно.
Элементы системы аутентификации
В любой системе аутентификации обычно можно выделить несколько элементов [3] :
Факторы аутентификации
Ещё до появления компьютеров использовались различные отличительные черты субъекта, его характеристики. Сейчас использование той или иной характеристики в системе зависит от требуемой надёжности, защищенности и стоимости внедрения. Выделяют 3 фактора аутентификации [4] :
Способы аутентификации
Аутентификация по многоразовым паролям
Один из способов аутентификации в компьютерной системе состоит во вводе вашего пользовательского идентификатора, в просторечии называемого «логином» (англ. login — регистрационное имя пользователя) и пароля — некой конфиденциальной информации. Достоверная (эталонная) пара логин-пароль хранится в специальной базе данных.
Простая аутентификация имеет следующий общий алгоритм:
Введённый субъектом пароль может передаваться в сети двумя способами:
Защищенность
С точки зрения максимальной защищенности, при хранении и передаче паролей следует использовать однонаправленные функции. Обычно для этих целей используются криптографически стойкие хэш-функции. В этом случае на сервере хранится только образ пароля. Получив пароль и проделав его хэш-преобразование, система сравнивает полученный результат с эталонным образом, хранящимся в ней. При их идентичности, пароли совпадают. Для злоумышленника, получившего доступ к образу, вычислить сам пароль практически невозможно.
Использование многоразовых паролей имеет ряд существенных минусов. Во-первых, сам эталонный пароль или его хэшированный образ хранятся на сервере аутентификации. Зачастую хранение пароля производится без криптографических преобразований, в системных файлах. Получив доступ к ним, злоумышленник легко доберётся до конфиденциальной информации. Во-вторых, субъект вынужден запоминать (или записывать) свой многоразовый пароль. Злоумышленник может заполучить его, просто применив навыки социальной инженерии, без всяких технических средств. Кроме того, сильно снижается защищенность системы в случае, когда субъект сам выбирает себе пароль. Зачастую это оказывается какое-то слово или комбинация слов, присутствующие в словаре. При достаточном количестве времени злоумышленник может взломать пароль простым перебором. Решением этой проблемы является использование случайных паролей или ограниченность по времени действия пароля субъекта, по истечении которого пароль необходимо поменять.
Базы учетных записей
На компьютерах с ОС семейства UNIX, базой является файл /etc/master.passwd (в дистрибутивах Linux обычно файл /etc/shadow, доступный для чтения только root), в котором пароли пользователей хранятся в виде хеш-функций от открытых паролей, кроме этого в этом же файле хранится информация о правах пользователя. Изначально в Unix-системах пароль (в зашифрованном виде) хранился в файле /etc/passwd, доступном для чтения всем пользователям, что было небезопасно.
На компьютерах с операционной системой Windows NT/2000/XP/2003 (не входящих в домен Windows) такая база данных называется SAM (Security Account Manager — Диспетчер защиты учётных записей). База SAM хранит учётные записи пользователей, включающие в себя все данные, необходимые системе защиты для функционирования. Находится в директории %windir%\system32\config\.
В доменах Windows Server 2000/2003 такой базой является Active Directory.
Однако более надёжным способом хранения аутентификационных данных признано использование специальных аппаратных средств (компонентов).
При необходимости обеспечения работы сотрудников на разных компьютерах (с поддержкой системы безопасности) используют аппаратно-программные системы, позволяющие хранить аутентификационные данные и криптографические ключи на сервере организации. Пользователи свободно могут работать на любом компьютере (рабочей станции), имея доступ к своим аутентификационным данным и криптографическим ключам.
Аутентификация по одноразовым паролям
Технологии использования одноразовых паролей можно разделить на:
В первом методе используется генератор псевдослучайных чисел с одинаковым значением для субъекта и для системы. Сгенерированный субъектом пароль может передаваться системе при последовательном использовании односторонней функции или при каждом новом запросе, основываясь на уникальной информации из предыдущего запроса.
Во втором методе используются временные метки. В качестве примера такой технологии можно привести SecurID. Она основана на использовании аппаратных ключей и синхронизации по времени. Аутентификация основана на генерации случайных чисел через определенные временные интервалы. Уникальный секретный ключ хранится только в базе системы и в аппаратном устройстве субъекта. Когда субъект запрашивает доступ в систему, ему предлагается ввести PIN-код, а также случайно генерируемое число, отображаемого в этот момент на аппаратном устройстве. Система сопоставляет введенный PIN-код и секретный ключ субъекта из своей базы и генерирует случайное число, основываясь на параметрах секретного ключа из базы и текущего времени. Далее проверяется идентичность сгенерированного числа и числа, введённого субъектом.
Третий метод основан на единой базе паролей для субъекта и системы и высокоточной синхронизации между ними. При этом каждый пароль из набора может быть использован только один раз. Благодаря этому, даже если злоумышленник перехватит используемый субъектом пароль, то он уже будет недействителен.
По сравнению с использованием многоразовых паролей, одноразовые пароли предоставляют более высокую степень защиты.
Многофакторная аутентификация
В последнее время всё чаще применяется, так называемая, расширенная или многофакторная аутентификация. Она построена на совместном использовании нескольких факторов аутентификации. Это значительно повышает защищенность системы.
В качестве примера можно привести использование SIM-карт в мобильных телефонах. Субъект вставляет аппаратно свою карту (устройство аутентификации) в телефон и при включении вводит свой PIN-код (пароль).
Также, к примеру в некоторых современных ноутбуках присутствует сканер отпечатка пальца. Таким образом, при входе в систему субъект должен пройти эту процедуру (биометрика), а потом ввести пароль.
Выбирая для системы тот или иной фактор или способ аутентификации необходимо прежде всего отталкиваться от требуемой степени защищенности, стоимости построения системы, обеспечения мобильности субъекта.
Можно привести сравнительную таблицу:
Протоколы аутентификации
Процедура аутентификации используется при обмене информацией между компьютерами, при этом используются весьма сложные криптографические протоколы, обеспечивающие защиту линии связи от прослушивания или подмены одного из участников взаимодействия. А поскольку, как правило, аутентификация необходима обоим объектам, устанавливающим сетевое взаимодействие, то аутентификация может быть и взаимной.
Более сложные протоколы аутентификации основаны на принципе «запрос-ответ», например, протокол CHAP (Challenge-Handshake Authentication Protocol). Работа протокола типа «запрос-ответ» может состоять минимум из четырех стадий:
Сам уникальный ключ, на основе которого производится шифрование и с одной, и с другой стороны, не передается по сети, следовательно, злоумышленник не сможет его перехватить. Но субъект должен обладать собственным вычислительным шифрующим устройством, например, смарт-карта, мобильный телефон.
Принцип действия протоколов взаимной аутентификации отличаются от протоколов типа «запрос-ответ» незначительно:
Алгоритм, приведенный выше, часто называют рукопожатием. В обоих случаях аутентификация проходит успешно, только если субъект имеет идентичные с системой уникальные ключи.
В операционных системах семейства Windows NT 4 используется протокол NTLM (NT LAN Manager — Диспетчер локальной сети NT). А в доменах Windows 2000/2003 применяется гораздо более совершенный протокол Kerberos.
Что такое Аутентификация: Методы и Элементы
Узнайте больше о том, для чего нужна аутентификация, и ознакомьтесь с её методами
Аутентификация (англ. authentication) — это основа безопасности любой системы, которая заключается в проверке подлинности данных о пользователе сервером.
Она не тождественна идентификации и авторизации. Эти три термина являются элементами защиты информации. Первая стадия — идентификация. На ней происходит распознавание информации о пользователе, например, логин и пароль. Вторая стадия — аутентификация. Это процесс проверки информации о пользователе. Третья стадия — авторизация. Здесь происходит проверка прав пользователя и определяется возможность доступа.
Содержание
Зачем нужна аутентификация
Аутентификация нужна для доступа к:
Элементы аутентификации
Методы аутентификации
Парольные
Самый распространенный метод. Аутентификация может проходить по одноразовым и многоразовым паролям. Многоразовый пароль задает пользователь, а система хранит его в базе данных. Он является одинаковым для каждой сессии. К ним относятся PIN-коды, слова, цифры, графические ключи. Одноразовые пароли — разные для каждой сессии. Это может быть SMS с кодом.
Комбинированные
Этот метод говорит сам за себя. Аутентификация происходит с использованием нескольких методов, например, парольных и криптографических сертификатов. Он требует специальное устройство для считывания информации.
Биометрические
Это самый дорогостоящий метод аутентификации. Он предотвращает утечку или кражу персональной информации. Проверка проходит по физиологическим характеристикам пользователя, например, по отпечатку пальца, сетчатке глаза, тембру голоса и даже ДНК.
Информация о пользователе
Она используется для восстановления логина или пароля и для двухэтапной аутентификации, чтобы обеспечить безопасность. К этому методу относится номер телефона, девичья фамилия матери, год рождения, дата регистрации, кличка питомца, место проживания.
Пользовательские данные
Этот метод основывается на геоданных о местоположении пользователя с использованием GPS, а также использует информацию о точках доступа беспроводной связи. Недостаток заключается в том, что с помощью прокси-серверов можно подменить данные.
Классификация видов аутентификации
В зависимости от количества используемых методов
В зависимости от политики безопасности систем и уровня доверия
Чтобы защитить владельца сайта от злоумышленников, используют криптографические протоколы аутентификации.
Типы протоколов обусловлены тем, где происходит аутентификация — на PC или в сети.
Что такое аутентификация и какая она бывает
Аутентификация (англ. authentication – подтверждение подлинности) – это процедура, во время которой определяется достоверность предоставленной информации (логин, пароль). То есть выясняется, действительно ли пользователь тот, кем представляется согласно введенным данным.
Виды аутентификации
Выделяют два типа – слабую (или однофакторную) и сильную (или двухфакторную, двойную) аутентификацию.
Однофакторная аутентификация
Классический вариант – аутентификация с помощью пароля. Некоторые пользователи грешат тем, что придумывают себе единый пароль для всех сайтов, которые требуют ввода данных для регистрации.
Логично, что один легче запомнить, чем десять разных. Впрочем, его легко и подобрать. По этой причине некоторые информационные системы используют временные пароли, смс-коды и т.д. Такой вариант интересен тем, что не нужно запоминать комбинации из «не менее 8 букв и цифр». Но от пользователя требуется иметь при себе устройство (например, мобильный телефон), на которое придет вышеуказанный идентификатор.
Двухфакторная аутентификация
По названию понятно, что двухфакторная аутентификация – это подтверждение личности пользователя с помощью двух или более факторов. Просто одного пароля недостаточно. Причина в том, что существует возможность подобрать комбинацию символов, даже самую мега-сложную.
Популярный вариант 2-факторной аутентификации – два пароля, один постоянный, другой одноразовый. Последний доставляется, допустим, в СМС сообщении. Настоящим будет пользователь, которому известна комбинация символов постоянного пароля и имеет с собой телефон для получения временного пароля. Мобильное устройство выступает вторым обязательным для аутентификации фактором.
Двусторонний тип аутентификации обеспечивают многие сервисы, предлагая пользователю самостоятельно выбрать цепочку взаимосвязи факторов.
Гарантировать максимальную безопасность может только двухэтапная аутентификация, когда одним из факторов выступает биометрия.
Способы аутентификации
С применением пароля
Парольная аутентификация ─ это когда пользователь идентифицируется по определенной комбинации символов, известной только ему. В качестве идентификатора используют и многоразовый пароль, что повторяется каждый раз для входа в систему (PIN код карточки или пароль для разблокировки телефона), и временный одноразовый, что присылают на email или телефон клиента.
Установка паролей ─ самый часто встречающийся вид однофакторной аутентификации, хоть он и не гарантирует подлинность пользователя. Одним паролем могут пользоваться несколько сотрудников-коллег. В таком случае, одному из них ничего не стоит изменить его или подменить владельца пароля. Тайна, известная двум людям, перестает быть тайной.
Взлом, кража, перехват паролей. Технологии развиваются и не каждый использует их для благого дела. Приходится искать альтернативные варианты защиты персональных данных и надежной парольной защиты:
Перечисленные методы применяют и в случае выбора других типов аутентификации.
С применением пользовательского предмета
Зависимо от данных, которые передают в систему, носителями информации могут выступать:
Человек, который держит в руках один из вышеуказанных носителей информации, будет являться подлинным пользователем. И здесь следует помнить о человеческом факторе и возможности кражи.
С применением биометрических данных
Биометрические системы аутентификации опираются на неповторимые человеческие физиологические и психологические характеристики.
Биометрическая аутентификация ─ это один из надежных и совершенных типов аутентификации, поскольку «информационные носители» невозможно украсть и сложно подделать. Есть гарантия, что пользователь именно тот, за которого себя выдает, реальный и подлинный.
С применением личной информации пользователя
Пользовательская личная информация редко используется в качестве единого фактора для аутентификации. Зачастую она выступает в связке с несколькими идентификаторами и используется для восстановления пароля (логина или других данных). Для аутентификации система запрашивает информацию, которая напрямую касается человека, что выполняет вход/регистрируется:
С помощью местонахождения пользователя
Аутентификация пользователя по его местоположению – новое направление в категории защитных механизмов. Смысл работы в том, что за основу аутентификации берутся данные GPS (Global Positioning System) ─ системы спутниковой навигации.
Пользователь применяет GPS аппаратуру для отправки своих координат. С помощью спутников месторасположение определяется вплоть до метра. Следовательно, пользователю разрешают или запрещают доступ. Этот тип аутентификации характеризуется высокой надежностью, потому что отследить и перехватить спутниковый сигнал достаточно сложно. При этом GPS аппаратура проста в использовании.
С помощью ключа
Это тип аутентификации в wi fi сетях характерный для гаджетов, телефонов. Для нее используются ключи разных типов: динамическая аутентификация WPA, WPA2, по MAC-адресу. Что это такое, вы можете почитать в статье Wikipedia о сетевых методах аутентификации wi fi.
С применением комбинаций методов удостоверения личности (многофакторная аутентификация)
Объединение методов идентификации юзера повышает уровень защиты. Выбирая элементы безопасности опирайтесь на законы и бизнес-стандарты, потребности и удобство пользователя. Не стоит объединять пароль и одноразовый код активации, отправленный по email, когда у человека нет возможности этот email получить и прочитать.
Протоколы аутентификации
Пользователь использует для аутентификации персональный идентификатор ─ неповторимый ключ (при идентификации через протокол) или пароль.
Характеристики протоколов аутентификации:
Говоря о безопасности протоколов и их возможности противостоять ряду атак, выделяют одностороннюю аутентификацию, двухстороннюю аутентификацию и криптографические протоколы аутентификации.
Какие бывают протоколы аутентификации
Выбор протокола зависит от того, где происходит аутентификация – на ПК или в сети.
Есть ряд стандартных протоколов для аутентификации по паролю на персональном компьютере (например, в веб-приложениях). Одним из них является HTTP аутентификация по протоколу HTTP 1.0/1.1.
Смысл его работы следующий:
Процесс HTTP аутентификации – стандартный и работает для всех видов браузеров. Да, существуют и нестандартные протоколы. Например, php аутентификация, которая применяется при разработке клиент-серверных приложений. Тогда статусы и остальные данные прописываются и сохраняются в других частях запроса.
Итого, при аутентификации пользователя на ПК используются такие методы, как: ввод логина и пароля, биометрические данные, USB-токены и сертификаты.
Для аутентификации в сети существуют протоколы и сертификаты, которые идентифицируют пользователя и собирают статистику о его действиях и предпочтениях. Часто мы, будучи пользователями, встречаем информацию о файлах Cookies. Своего рода открытую аутентификацию. Куки привязываются к IP-адресу и используются для отслеживания действий и предпочтений пользователя.
Как видите, аутентификация – это этап для подтверждения личности пользователя при входе в систему. Способы и методы аутентификации продолжают развиваться, совершенствоваться и улучшаться.
Задайте вопрос специалисту технической поддержки
Идентификация, аутентификация и авторизация — в чем разница?
Объясняем на енотах, в чем разница между идентификацией и авторизацией, а также зачем нужна аутентификация, тем более двухфакторная.
Это происходит с каждым из нас, причем ежедневно: мы постоянно идентифицируемся, аутентифицируемся и авторизуемся в разнообразных системах. И все же многие путают значение этих слов и часто употребляют термин «идентификация» или «авторизация», когда на самом деле речь идет об аутентификации.
Ничего такого уж страшного в этом нет — пока идет бытовое общение и обе стороны диалога по контексту понимают, что в действительности имеется в виду. Но всегда лучше знать и понимать слова, которые употребляешь, а то рано или поздно нарвешься на зануду-специалиста, который вынет всю душу за «авторизацию» вместо «аутентификации», кофе среднего рода и такое душевное, но неуместное в серьезной беседе слово «ихний».
Идентификация, аутентификация и авторизация: серьезные определения
Итак, что же значат термины «идентификация», «аутентификация» и «авторизация» — и чем соответствующие процессы отличаются друг от друга? Для начала проконсультируемся с «Википедией»:
Объясняем идентификацию, аутентификацию и авторизацию на енотах
Выше было очень много умных слов, теперь давайте упростим до конкретных примеров. Скажем, пользователь хочет войти в свой аккаунт Google. Google подходит лучше всего, потому что там процедура входа явным образом разбита на несколько простейших этапов. Вот что при этом происходит:
Аутентификация без предварительной идентификации лишена смысла — пока система не поймет, подлинность чего же надо проверять, совершенно бессмысленно начинать проверку. Для начала надо представиться.
Идентификация без аутентификации — это просто глупо. Потому что мало ли кто ввел существующий в системе логин! Системе обязательно надо удостовериться, что этот кто-то знает еще и пароль. Но пароль могли подсмотреть или подобрать, поэтому лучше подстраховаться и спросить что-то дополнительное, что может быть известно только данному пользователю: например, одноразовый код для подтверждения входа.
А вот авторизация без идентификации и тем более аутентификации очень даже возможна. Например, в Google Документах можно публиковать документы так, чтобы они были доступны вообще кому угодно. В этом случае вы как владелец файла увидите сверху надпись, гласящую, что его читает неопознанный енот. Несмотря на то, что енот совершенно неопознанный, система его все же авторизовала — то есть выдала право прочитать этот документ.
А вот если бы вы открыли этот документ для чтения только определенным пользователям, то еноту в таком случае сперва пришлось бы идентифицироваться (ввести свой логин), потом аутентифицироваться (ввести пароль и одноразовый код) и только потом получить право на чтение документа — авторизоваться.
А уж если речь идет о содержимом вашего почтового ящика, то Google никогда и ни за что не авторизует неопознанного енота на чтение вашей переписки — если, конечно, он не идентифицируется с вашим логином и не аутентифицируется с вашим паролем. Но тогда это уже не будет неопознанный енот, поскольку Google однозначно определит этого енота как вас.
Теперь вы знаете, чем идентификация отличается от аутентификации и авторизации. Что еще важно понимать: аутентификация — пожалуй, самый важный из этих процессов с точки зрения безопасности вашего аккаунта. Если вы ленитесь и используете для аутентификации только слабенький пароль, то какой-нибудь енот может ваш аккаунт угнать. Поэтому:
Обзор способов и протоколов аутентификации в веб-приложениях
Я расскажу о применении различных способов аутентификации для веб-приложений, включая аутентификацию по паролю, по сертификатам, по одноразовым паролям, по ключам доступа и по токенам. Коснусь технологии единого входа (Single Sign-On), рассмотрю различные стандарты и протоколы аутентификации.
Перед тем, как перейти к техническим деталям, давайте немного освежим терминологию.
Аналогично эти термины применяются в компьютерных системах, где традиционно под идентификацией понимают получение вашей учетной записи (identity) по username или email; под аутентификацией — проверку, что вы знаете пароль от этой учетной записи, а под авторизацией — проверку вашей роли в системе и решение о предоставлении доступа к запрошенной странице или ресурсу.
Однако в современных системах существуют и более сложные схемы аутентификации и авторизации, о которых я расскажу далее. Но начнем с простого и понятного.
Аутентификация по паролю
Этот метод основывается на том, что пользователь должен предоставить username и password для успешной идентификации и аутентификации в системе. Пара username/password задается пользователем при его регистрации в системе, при этом в качестве username может выступать адрес электронной почты пользователя.
Применительно к веб-приложениям, существует несколько стандартных протоколов для аутентификации по паролю, которые мы рассмотрим ниже.
HTTP authentication
Этот протокол, описанный в стандартах HTTP 1.0/1.1, существует очень давно и до сих пор активно применяется в корпоративной среде. Применительно к веб-сайтам работает следующим образом:
Весь процесс стандартизирован и хорошо поддерживается всеми браузерами и веб-серверами. Существует несколько схем аутентификации, отличающихся по уровню безопасности:
Forms authentication
Для этого протокола нет определенного стандарта, поэтому все его реализации специфичны для конкретных систем, а точнее, для модулей аутентификации фреймворков разработки.
Работает это по следующему принципу: в веб-приложение включается HTML-форма, в которую пользователь должен ввести свои username/password и отправить их на сервер через HTTP POST для аутентификации. В случае успеха веб-приложение создает session token, который обычно помещается в browser cookies. При последующих веб-запросах session token автоматически передается на сервер и позволяет приложению получить информацию о текущем пользователе для авторизации запроса.
Пример forms authentication.
Приложение может создать session token двумя способами:
Другие протоколы аутентификации по паролю
Два протокола, описанных выше, успешно используются для аутентификации пользователей на веб-сайтах. Но при разработке клиент-серверных приложений с использованием веб-сервисов (например, iOS или Android), наряду с HTTP аутентификацией, часто применяются нестандартные протоколы, в которых данные для аутентификации передаются в других частях запроса.
Существует всего несколько мест, где можно передать username и password в HTTP запросах:
Распространенные уязвимости и ошибки реализации
Аутентификации по паролю считается не очень надежным способом, так как пароль часто можно подобрать, а пользователи склонны использовать простые и одинаковые пароли в разных системах, либо записывать их на клочках бумаги. Если злоумышленник смог выяснить пароль, то пользователь зачастую об этом не узнает. Кроме того, разработчики приложений могут допустить ряд концептуальных ошибок, упрощающих взлом учетных записей.
Ниже представлен список наиболее часто встречающихся уязвимостей в случае использования аутентификации по паролю:
Аутентификация по сертификатам
Сертификат представляет собой набор атрибутов, идентифицирующих владельца, подписанный certificate authority (CA). CA выступает в роли посредника, который гарантирует подлинность сертификатов (по аналогии с ФМС, выпускающей паспорта). Также сертификат криптографически связан с закрытым ключом, который хранится у владельца сертификата и позволяет однозначно подтвердить факт владения сертификатом.
На стороне клиента сертификат вместе с закрытым ключом могут храниться в операционной системе, в браузере, в файле, на отдельном физическом устройстве (smart card, USB token). Обычно закрытый ключ дополнительно защищен паролем или PIN-кодом.
В веб-приложениях традиционно используют сертификаты стандарта X.509. Аутентификация с помощью X.509-сертификата происходит в момент соединения с сервером и является частью протокола SSL/TLS. Этот механизм также хорошо поддерживается браузерами, которые позволяют пользователю выбрать и применить сертификат, если веб-сайт допускает такой способ аутентификации.
Использование сертификата для аутентификации.
Во время аутентификации сервер выполняет проверку сертификата на основании следующих правил:
Пример X.509 сертификата.
После успешной аутентификации веб-приложение может выполнить авторизацию запроса на основании таких данных сертификата, как subject (имя владельца), issuer (эмитент), serial number (серийный номер сертификата) или thumbprint (отпечаток открытого ключа сертификата).
Использование сертификатов для аутентификации — куда более надежный способ, чем аутентификация посредством паролей. Это достигается созданием в процессе аутентификации цифровой подписи, наличие которой доказывает факт применения закрытого ключа в конкретной ситуации (non-repudiation). Однако трудности с распространением и поддержкой сертификатов делает такой способ аутентификации малодоступным в широких кругах.
Аутентификация по одноразовым паролям
Аутентификация по одноразовым паролям обычно применяется дополнительно к аутентификации по паролям для реализации two-factor authentication (2FA). В этой концепции пользователю необходимо предоставить данные двух типов для входа в систему: что-то, что он знает (например, пароль), и что-то, чем он владеет (например, устройство для генерации одноразовых паролей). Наличие двух факторов позволяет в значительной степени увеличить уровень безопасности, что м. б. востребовано для определенных видов веб-приложений.
Другой популярный сценарий использования одноразовых паролей — дополнительная аутентификация пользователя во время выполнения важных действий: перевод денег, изменение настроек и т. п.
Существуют разные источники для создания одноразовых паролей. Наиболее популярные:
Аппаратный токен RSA SecurID генерирует новый код каждые 30 секунд.
В веб-приложениях такой механизм аутентификации часто реализуется посредством расширения forms authentication: после первичной аутентификации по паролю, создается сессия пользователя, однако в контексте этой сессии пользователь не имеет доступа к приложению до тех пор, пока он не выполнит дополнительную аутентификацию по одноразовому паролю.
Аутентификация по ключам доступа
Этот способ чаще всего используется для аутентификации устройств, сервисов или других приложений при обращении к веб-сервисам. Здесь в качестве секрета применяются ключи доступа (access key, API key) — длинные уникальные строки, содержащие произвольный набор символов, по сути заменяющие собой комбинацию username/password.
В большинстве случаев, сервер генерирует ключи доступа по запросу пользователей, которые далее сохраняют эти ключи в клиентских приложениях. При создании ключа также возможно ограничить срок действия и уровень доступа, который получит клиентское приложение при аутентификации с помощью этого ключа.
Хороший пример применения аутентификации по ключу — облако Amazon Web Services. Предположим, у пользователя есть веб-приложение, позволяющее загружать и просматривать фотографии, и он хочет использовать сервис Amazon S3 для хранения файлов. В таком случае, пользователь через консоль AWS может создать ключ, имеющий ограниченный доступ к облаку: только чтение/запись его файлов в Amazon S3. Этот ключ в результате можно применить для аутентификации веб-приложения в облаке AWS.
Пример применения аутентификации по ключу.
Использование ключей позволяет избежать передачи пароля пользователя сторонним приложениям (в примере выше пользователь сохранил в веб-приложении не свой пароль, а ключ доступа). Ключи обладают значительно большей энтропией по сравнению с паролями, поэтому их практически невозможно подобрать. Кроме того, если ключ был раскрыт, это не приводит к компрометации основной учетной записи пользователя — достаточно лишь аннулировать этот ключ и создать новый.
С технической точки зрения, здесь не существует единого протокола: ключи могут передаваться в разных частях HTTP-запроса: URL query, request body или HTTP header. Как и в случае аутентификации по паролю, наиболее оптимальный вариант — использование HTTP header. В некоторых случаях используют HTTP-схему Bearer для передачи токена в заголовке (Authorization: Bearer [token]). Чтобы избежать перехвата ключей, соединение с сервером должно быть обязательно защищено протоколом SSL/TLS.
Пример аутентификации по ключу доступа, переданного в HTTP заголовке.
Кроме того, существуют более сложные схемы аутентификации по ключам для незащищенных соединений. В этом случае, ключ обычно состоит их двух частей: публичной и секретной. Публичная часть используется для идентификации клиента, а секретная часть позволяет сгенерировать подпись. Например, по аналогии с digest authentication схемой, сервер может послать клиенту уникальное значение nonce или timestamp, а клиент — возвратить хэш или HMAC этого значения, вычисленный с использованием секретной части ключа. Это позволяет избежать передачи всего ключа в оригинальном виде и защищает от replay attacks.
Аутентификация по токенам
Такой способ аутентификации чаще всего применяется при построении распределенных систем Single Sign-On (SSO), где одно приложение (service provider или relying party) делегирует функцию аутентификации пользователей другому приложению (identity provider или authentication service). Типичный пример этого способа — вход в приложение через учетную запись в социальных сетях. Здесь социальные сети являются сервисами аутентификации, а приложение доверяет функцию аутентификации пользователей социальным сетям.
Реализация этого способа заключается в том, что identity provider (IP) предоставляет достоверные сведения о пользователе в виде токена, а service provider (SP) приложение использует этот токен для идентификации, аутентификации и авторизации пользователя.
На общем уровне, весь процесс выглядит следующим образом:
Пример аутентификации «активного» клиента при помощи токена, переданного посредством Bearer схемы.
Процесс, описанный выше, отражает механизм аутентификации активного клиента, т. е. такого, который может выполнять запрограммированную последовательность действий (например, iOS/Android приложения). Браузер же — пассивный клиент в том смысле, что он только может отображать страницы, запрошенные пользователем. В этом случае аутентификация достигается посредством автоматического перенаправления браузера между веб-приложениями identity provider и service provider.
Пример аутентификации «пассивного» клиента посредством перенаправления запросов.
Существует несколько стандартов, в точности определяющих протокол взаимодействия между клиентами (активными и пассивными) и IP/SP-приложениями и формат поддерживаемых токенов. Среди наиболее популярных стандартов — OAuth, OpenID Connect, SAML, и WS-Federation. Некоторая информация об этих протоколах — ниже в статье.
Сам токен обычно представляет собой структуру данных, которая содержит информацию, кто сгенерировал токен, кто может быть получателем токена, срок действия, набор сведений о самом пользователе (claims). Кроме того, токен дополнительно подписывается для предотвращения несанкционированных изменений и гарантий подлинности.
При аутентификации с помощью токена SP-приложение должно выполнить следующие проверки:
В случае успешной проверки SP-приложение выполняет авторизацию запроса на основании данных о пользователе, содержащихся в токене.
Форматы токенов
Существует несколько распространенных форматов токенов для веб-приложений:
Пример SWT токена (после декодирования).
Issuer=http://auth.myservice.com&
Audience=http://myservice.com&
ExpiresOn=1435937883&
UserName=John Smith&
UserRole=Admin&
HMACSHA256=KOUQRPSpy64rvT2KnYyQKtFFXUIggnesSpE7ADA4o9w
Пример подписанного JWT токена (после декодирования 1 и 2 блоков).
Стандарт SAML
Стандарт Security Assertion Markup Language (SAML) описывает способы взаимодействия и протоколы между identity provider и service provider для обмена данными аутентификации и авторизации посредством токенов. Изначально версии 1.0 и 1.1 были выпущены в 2002 – 2003 гг., в то время как версия 2.0, значительно расширяющая стандарт и обратно несовместимая, опубликована в 2005 г.
Этот основополагающий стандарт — достаточно сложный и поддерживает много различных сценариев интеграции систем. Основные «строительные блоки» стандарта:
Кроме того, стандарт определяет формат обмена метаинформацией между участниками, которая включает список поддерживаемых ролей, протоколов, атрибутов, ключи шифрования и т. п.
Рассмотрим краткий пример использования SAML для сценария Single Sign-On. Пользователь хочет получить доступ на защищенный ресурс сервис-провайдера (шаг № 1 на диаграмме аутентификации пассивных клиентов). Т. к. пользователь не был аутентифицирован, SP отправляет его на сайт identity provider’а для создания токена (шаг № 2). Ниже приведен пример ответа SP, где последний использует SAML HTTP Redirect binding для отправки сообщения с запросом токена:
В случае такого запроса, identity provider аутентифицирует пользователя (шаги №3-4), после чего генерирует токен. Ниже приведен пример ответа IP с использованием HTTP POST binding (шаг № 5):
После того как браузер автоматически отправит эту форму на сайт service provider’а (шаг № 6), последний декодирует токен и аутентифицирует пользователя. По результатам успешной авторизации запроса пользователь получает доступ к запрошенному ресурсу (шаг № 7).
Стандарты WS-Trust и WS-Federation
WS-Trust и WS-Federation входят в группу стандартов WS-*, описывающих SOAP/XML-веб сервисы. Эти стандарты разрабатываются группой компаний, куда входят Microsoft, IBM, VeriSign и другие. Наряду с SAML, эти стандарты достаточно сложные, используются преимущественно в корпоративных сценариях.
Стандарт WS-Trust описывает интерфейс сервиса авторизации, именуемого Secure Token Service (STS). Этот сервис работает по протоколу SOAP и поддерживает создание, обновление и аннулирование токенов. При этом стандарт допускает использование токенов различного формата, однако на практике в основном используются SAML-токены.
Стандарт WS-Federation касается механизмов взаимодействия сервисов между компаниями, в частности, протоколов обмена токенов. При этом WS-Federation расширяет функции и интерфейс сервиса STS, описанного в стандарте WS-Trust. Среди прочего, стандарт WS-Federation определяет:
Можно сказать, что WS-Federation позволяет решить те же задачи, что и SAML, однако их подходы и реализация в некоторой степени отличаются.
Стандарты OAuth и OpenID Connect
В отличие от SAML и WS-Federation, стандарт OAuth (Open Authorization) не описывает протокол аутентификации пользователя. Вместо этого он определяет механизм получения доступа одного приложения к другому от имени пользователя. Однако существуют схемы, позволяющие осуществить аутентификацию пользователя на базе этого стандарта (об этом — ниже).
Первая версия стандарта разрабатывалась в 2007 – 2010 гг., а текущая версия 2.0 опубликована в 2012 г. Версия 2.0 значительно расширяет и в то же время упрощает стандарт, но обратно несовместима с версией 1.0. Сейчас OAuth 2.0 очень популярен и используется повсеместно для предоставления делегированного доступа и третье-сторонней аутентификации пользователей.
Чтобы лучше понять сам стандарт, рассмотрим пример веб-приложения, которое помогает пользователям планировать путешествия. Как часть функциональности оно умеет анализировать почту пользователей на наличие писем с подтверждениями бронирований и автоматически включать их в планируемый маршрут. Возникает вопрос, как это веб-приложение может безопасно получить доступ к почте пользователей, например, к Gmail?
> Попросить пользователя указать данные своей учетной записи? — плохой вариант.
> Попросить пользователя создать ключ доступа? — возможно, но весьма сложно.
Как раз эту проблему и позволяет решить стандарт OAuth: он описывает, как приложение путешествий (client) может получить доступ к почте пользователя (resource server) с разрешения пользователя (resource owner). В общем виде весь процесс состоит из нескольких шагов:
Взаимодействие компонентов в стандарте OAuth.
Стандарт описывает четыре вида грантов, которые определяют возможные сценарии применения:
Стандарт не определяет формат токена, который получает приложение: в сценариях, адресуемых стандартом, приложению нет необходимости анализировать токен, т. к. он лишь используется для получения доступа к ресурсам. Поэтому ни токен, ни грант сами по себе не могут быть использованы для аутентификации пользователя. Однако если приложению необходимо получить достоверную информацию о пользователе, существуют несколько способов это сделать:
Стоит заметить, что OpenID Connect, заменивший предыдущие версии стандарта OpenID 1.0 и 2.0, также содержит набор необязательных дополнений для поиска серверов авторизации, динамической регистрации клиентов и управления сессией пользователя.
Заключение
В этой статье мы рассмотрели различные методы аутентификации в веб-приложениях. Ниже — таблица, которая резюмирует описанные способы и протоколы: