Процесс проверки подлинности чего либо
Механизмы аутентификации в пользовательских интерфейсах
Для кого эта статья
Начало
Процессы аутентификации
Варианты фиксирования уникального имени пользователя (логин)
Есть несколько возможных способов проверки подлинности при предоставлении доступа к данным учётной записи в какой-либо системе. Логином могут выступать следующие пункты:
Номер телефона (+996 777 777 777)
Уникальное имя (username)
Учётная запись в стороннем сервисе (Google, Facebook, Apple… и так далее)
Варианты подтверждения логина (пароль)
SMS код (9379992SMS)
Код в электронном сообщении (9379992MAIL)
Ключи доступа / Токены (как пример ssh key)
Сканеры внешности (лицо, отпечаток пальца)
Необходимость интернет соединения при различных видах аутентификации
Не все виды аутентификации пользователя требуют интернет соединения для проверки соответствия логина и пароля пользователя. На пример: вы можете без подключения к интернету разблокировать свой телефон, компьютер, сейф с кодовым замком или открыть дверь в подъезд.
Соединение нужно для тех типов аутентификации, в которых личные данные пользователей хранятся на удалённом сервере. Это как доступ к банковской ячейке, открыть которую вы можете только придя в банк, подтвердив свою личность и в присутствии охраны.
Комбинации ввода логина и пароля
Описанные выше варианты логинов и паролей могут комбинироваться между собой для проверки подлинности пользователя. На пример:
Номер телефона
Уникальное имя
Код в Email сообщении
Механизм проверки соответствия логина и пароля
Процесс проверки соответствия логина и пароля проходит в несколько этапов.
Отправляем данные на проверку
Система получает данные, которые ввёл пользователь, ищет в своей базе данных пользователя, проверяет соответствие логина и пароля.
Система отправляет результат проверки пользователю.
Получаем результат проверки
Для всех способов аутентификации процесс проверки соответствия одинаковый.
Двухфакторная аутентификация
Упрощённая схема двух факторной аутентификации
Ошибки аутентификации
Во время проверки логина и пароля могут возникнуть ситуации, когда аутентификация не пройдена и пользователь не получил доступ к своим личным данным.
Логин введён неверно
Пароль введён неверно
Нет соединения с сервером
Ошибка проверки данных сервером
Превышен лимит ошибочных попыток аутентификации
Пользователь ввёл верно свои денные, но он не зарегистрирован
Учётная запись пользователя заблокирована администратором
Лимиты ошибочных попыток аутентификации вводятся для усиления безопасности личных данных пользователей. После превышения лимита обычно предлагается восстановить пароль, либо повторить аутентификацию позже. В системах с повышенным уровнем контроля за безопасностью данных пользователя принимаются меры блокировки учётной записи до момента подтверждения личности пользователя (на пример в банковских картах).
Процесс восстановления пароля
Подтвердить свою личность (на пример пройти по ссылке в электронном письме от сервиса восстановления пароля или ввести код из СМС)
Ввести новый пароль
Повторить ввод нового пароля
Сохранить новый пароль
После прохождения данных этапов пользователь для входа в систему может использовать свой логин и новый пароль.
В системах с повышенным контролем за безопасностью данных пользователей используется более сложный механизм подтверждения личности пользователя для смены пароля. Примером может служить приход пользователя в банк, чтобы восстановить пин-код к своей карте или личному кабинету в системе банка.
Упрощённое объяснение термина «сессия»
Cookies
Вы можете проектировать свои интерфейсы как с сохранением сессий пользователей, так и без сохранения.
Заключение
Надеюсь вам было полезно, и хоть немного интересно.
Аутентификация и авторизация в микросервисных приложениях
Автор: Вячеслав Михайлов, Solutions Architect
Это вводная часть материала, основанного на докладе, прочитанном мной прошлым летом. Печатный материал предполагает больше информации, т.к. в одном докладе обычно не получается рассказать обо всех деталях.
Что такое аутентификация?
На процессах аутентификации и авторизации основано разделения прав доступа, без которого не обходится ни одно более или менее серьезное приложение. Поэтому понимать, как они происходили раньше и происходят теперь, очень важно, но, прежде чем углубиться в описание технологии, давайте разберемся с ключевыми терминами.
Идентификация — процесс определения, что за человек перед нами. Аутентификация — процесс подтверждения, что этот человек именно тот, за кого себя выдает. Авторизация — процесс принятия решения о том, что именно этой аутентифицированной персоне разрешается делать. То есть, это три разных, последовательных и взаимно не заменяемых понятия. Идентификацию часто подразумевают в составе аутентификации. Самое главное — четко различать аутентификацию и авторизацию.
В ходе аутентификации мы удостоверяемся, что человек, который к нам пришел, обладает доказательствами, подтверждающими личность. В этой статье речь в основном пойдет как раз об аутентификации.
Способы аутентификации
При использовании HTTP-протокола простейший способ аутентификации — Basic access authentication. В принципе этот протокол устарел и уже редко используется в интернете, особенно в незащищенных соединениях, но еще сохраняется во внутрикорпоративных системах, просто потому что некоторые из них созданы достаточно давно. Стоит разобраться, как он работает.
HTTP Basic Authentication
Первым, что при обращении к защищенному ресурсу сервер выдаст пользователю, не имеющему доступа, будет ошибка 401 Unauthorized. При этом ответ также содержит информацию о типе аутентификации (в нашем случае – Basic), который он может принимать, и контекст, в рамках которого эта аутентификация действует (Realm). Пользователь вводит логин и пароль, они упаковываются в Base64 и отправляются на сервер для проверки. Здесь существуют различные опасности. Самая распространенная — угроза man-in-the-middle attack, или атаки посредника, в ходе которой при использовании незащищенного соединения учетные данные могут перехватить злоумышленники в момент передачи от клиента к серверу или обратно.
HTTP Digest Authentication
Следующим этапом развития технологии стала чуть более сложная система HTTP digest authentication, которая исключает передачу учетных данных в открытом виде — здесь для проверки используется MD5-хеш с некоторыми примесями, что позволяет избежать подбора логина и пароля. Конечно, этот алгоритм выглядит более надежным, но и он подвержен целому ряду не самых сложных атак. Например, вот тут можно почитать об атаках более подробно.
Forms Authentication
Позднее появился процесс Forms authentication, при котором аутентификация происходит на более высоком уровне модели абстракции. HTTP-сервер при этом не сообщает об ошибке доступа, а просто перенаправляет неаутентифицированного пользователя на другую страницу. Обычно на этой странице отображаются поля для ввода логина и пароля, после заполнения которых формируется POST-запрос с данными и через защищенный канал направляется на сервер. Серверная сторона в свою очередь возвращает пользователю токен или идентификатор сессии, который сохраняется в Cookies и в дальнейшем используется для доступа к защищенному ресурсу.
Token Authentication
На схеме хорошо видно, как и в какой последовательности приложения обмениваются информацией при использовании аутентификацией по токенам.
На следующей схеме дополнительно отражены те этапы взаимодействия, в которых пользователь принимает непосредственное участие. Этот момент и является недостатком подобной схемы — нам всегда нужен пользователь, чтобы получить доступ к ресурсу.
OAuth2 & Open ID Connect
Дальнейшее усовершенствование процесса понадобилось ввиду того, что токен-аутентификация требует присутствия пользователя в момент получения доступа к защищенному ресурсу. Потому что Identity provider при передаче ему управления будет с пользователем взаимодействовать, запрашивая, например, логин и пароль.
В случае сервиса, который от имени пользователя должен через определенные промежутки времени опрашивать некий третий ресурс, — допустим, получать доступ к списку контактов в социальной сети — токен-аутентификация работать уже не будет. Дело в том, что идентификаторы сессии обычно живут очень недолго, чтобы в случае их перехвата злоумышленники получили доступ к сервису лишь на ограниченное время. Но из-за короткого срока действия токена не хватает, например, на ночной процесс.
В 2006 году в ходе работы над реализацией протокола Open ID для Twitter обнаружилась потребность в новом открытом протоколе авторизации. В 2007 инженеры Google и AOL начали совместную работу над ним, а в 2009 Twitter предложил своим пользователям решение, делегировавшее сторонним сервисам доступ к аккаунтам и основанное на протоколе OAuth. Три года спустя была опубликована новая версия — OAuth 2, упростившая разработку клиентских приложений и получившая целый ряд новых возможностей, среди которых оказалось и обновление токена без участия пользователя. Многие сервисы начали использовать этот протокол еще до его официального утверждения.
Разбираемся детально ху из ху
OpenID 1.0 (2006) & OpenID 2.0 (2007) позволяли приложению(арб) запрашивать у доверенного сервера (authority) проверку пользователя(user). Отличия между версиями для нас несущественны.
Взгляд сверху
Обычно в системах встречаются разные компоненты: пользователи, работающие через браузер, пользователи, взаимодействующие с сервером через мобильные приложения, и просто серверные приложения, нуждающиеся в принадлежащих вам данных, хранящихся на других серверах, доступ к которым осуществляется через Web API.
Single sign-on — технология единого входа — позволяет пользователю переключаться между различными приложениями без повторной аутентификации. Используя SSO можно избежать множественных логинов, так что пользователь просто не будет замечать этих переключений. При этом ситуации, когда в рамках вашей инфраструктуры таких приложений будет больше одного, встречаются постоянно. Технология единого входа особенно удобна в больших энтерпрайз-системах, состоящих из десятков приложений, слабо связанных между собой. Вряд ли пользователи будут довольны, вводя логин и пароль при каждом обращении к системе учета рабочего времени, корпоративному форуму или внутренней базе документов.
В качестве реализации мы рассматриваем протокол OAuth2. В принципе, существуют и другие, например, Kerberos, успешно взаимодействующий с Windows, но в случае гетерогенной сети, в которой существуют компьютеры, использующие и Windows-, и Mac-, и UNIX-системы, использовать проприетарные протоколы зачастую неудобно. Тем более, это касается случаев, когда доступ к вашим сервисам осуществляется через веб — здесь OAuth2 оказывается лучшим кандидатом.
На рисунке выше показано, какие именно протоколы используются при каждом типе взаимодействия.
Как мы знаем из раздела «разбираемся детально ху из ху», OpenID Сonnect нужен, чтобы получить у пользователя его учетные данные и проверить их. OAuth 2.0 нужен, чтобы получать токены доступа и с ними обращаться к ресурсам.
Терминология OAuth2 & OpenID Connect
Сервис выдачи токенов
Open ID Connect Provider — важнейший объект всей конструкции централизованного сервиса аутентификации, он также может называться Security Token Service, Identity Provider authorization server и т. д. Различные источники называют его по-разному, но по смыслу это сервис, который выдает токены клиентам.
Клиент
Client — устройство или программа (браузер, приложение), которым требуется либо токен для аутентификации пользователя, либо токен для доступа к какому-то ресурсу (подразумевается, что данный ресурс «знаком» с тем конкретным «Security Token Service» у которого клиент запрашивает токен для доступа).
Пользователь
User — собственно конечный пользователь — человек.
Область (scope)
Scope — идентификатор ресурса, к которому клиент хочет получить доступ. Список scope посылается в адрес сервиса выдачи токенов в составе запроса на аутентификацию.
По умолчанию все клиенты имеют возможность запрашивать любые области, но это можно (и нужно) ограничивать в конфигурации сервиса выдачи токенов.
Scopes бывают двух видов:
Запрос на аутентификацию
Authentication/Token Request — процесс запроса аутентификации.
Токен личности
Identity Token — подтверждение аутентификации. Этот токен содержит минимальный набор информации о пользователе.
Токен доступа
Access Token — информация, что конкретному пользователю разрешается делать. Клиент запрашивает Access Token и затем использует его для доступа к ресурсам (Web APIs). Access Token содержит информацию о клиенте и пользователе, если она присутствует. Важно понимать, что есть такие типы авторизации, при которых пользователь в процессе непосредственно не участвует (подробнее об этом в следующей части)
Токен обновления
Refresh Token — токен, по которому STS вернет новый Access Token. В зависимости от режима работы, Refresh Token может быть многоразовым и одноразовым. В случае с одноразовым токеном, при запросе нового Access Token будет также сформирован готовый Refresh Token, который следует использовать при повторном обновлении. Очевидно, что одноразовые токены более безопасны.
Более подробно о составе токенов в разделе «структура токена».
Процесс аутентификации
При обращении пользователя к клиенту, тот перенаправляет пользователя на Open ID Connect Provider, который запрашивает у пользователя логин и пароль. В случае успешного прохождения проверки параметров аутентификации он возвращает назад identity token и access token, с которыми пользователь может обращаться к защищенному ресурсу.
Структура токена
Формат
В реализации OAuth2 используется так называемый jwt-токен, который состоит из трех частей. Допустим, при обращении к Identity provider вы отправляете логин/пароль и в ответ получаете токен. Он будет включать в себя: Header (заголовок), Payload (контент) и Signature (подпись). На сайте jwt.io его можно декодировать и посмотреть содержимое формате JSON. На этом сайте вы также найдете описание правил формирования jwt-токенов.
В том, что токены в процессе обмена передаются незашифрованными, ничего страшного нет. Мы изначально исходим из предположения, что коммуникация происходит по защищенному HTTPS-каналу, и повторное шифрование токена было бы избыточным. Единственное, в чем нам нужно убедиться – то, что токен не был подменен или сфальсифицирован на клиентской стороне, для этого достаточно иметь подпись и проверять ее на сервере. Кроме того, токен не содержит никакой критически важной информации.
Кроме identity tokens, есть еще и аccess tokens, которые содержат информацию о выданных пользователю клеймах. Срок действия access token достаточно короткий, потому что его хищение может обеспечить несанкционированный доступ к ресурсу. Т. е. злоумышленник, если ему удастся заполучить токен этого типа, доступ получит на очень непродолжительное время. Для получения нового access token используется refresh token, который обычно не фигурирует в незащищенных средах, в частности в режиме доступа из браузера он вообще не используется. Какие именно токены будут возвращены клиенту в процессе аутентификации, разберемся в следующей части.
Основные поля
Кратко остановимся на том, какие есть стандартные полях в токене и зачем они нужны:
Заключение первой части
В этой статье мы постарались дать теоретический и терминологический фундамент, который понадобится нам создании работающего решения в следующих статьях.
Минимальная реализация интеграция Identity Server в ваше приложение выглядит так:
Минимальная реализация интеграции веб-клиента с Identity Server:
Минимальная реализация интеграции веб-API с Identity Server:
Аутентификация
Учитывая степень доверия и политику безопасности систем, проводимая проверка подлинности может быть односторонней или взаимной. Обычно она проводится с помощью криптографических методов.
Аутентификацию не следует путать с авторизацией [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.