Аутентификатор что это – Аутентификация — что это такое и почему сейчас повсеместно используется двухфакторная аутентификация

alexxlab 24.11.2020 Leave a comment

Содержание

Google Authenticator для компьютера

Всем привет! Сегодня мы поговорим о защите вашей учетной записи через Google Authenticator. Мы покажем как правильно подключить аутентификатор на компьютере и пользоваться им с телефоном или без.

В последнее время, защита личных данных и учетных записей стала очень актуальной. Все больше пользователей стараются подключить проверку дополнительных параметров при входе и усилить защиту акканутов. Одной из лучших программ для мобильной аутентификации является Google Authenticator.

Что это и как подключить?

Google Authenticator — это мобильное приложение, которое обеспечивает двухфакторную защиту учетных записей, посредством создания дополнительного кода, который нужно указать перед входом в аккаунт. Данную программу можно применить для защиты учетной записи Google, страницы ВКонтакте и других аккаунтов.

Основные возможности программы:

Генерация новых кодов без подключения к сети Internet или сотовой связи;
Поддерживание нескольких учетных записей и пользователей;
Простая настройка GA и минимализм интерфейса;
Поддержка на Android, iOS и BlackBerry.

Приложение GA работает достаточно просто и эффективно — вы скачиваете из Play Market саму программу, далее в настройках аккаунта, где поддерживается двухфакторная авторизация, подключаете эту опцию. Запустите приложение на телефоне и при помощи камеры распознайте QR-код, либо введите указанный ключ, после подтверждения укажите обновляющийся код доступа.

Вы можете добавить устройство, через которое открываете страницу, в список доверенных, что бы не вводить код постоянно.Например, такую аутентификацию для учетной записи Гугл можно подключить на странице настроек безопасности аккаунта. Для входа в Контакт тоже можно установить проверку через Google Authenticator. Подробнее на видео:

Google Authenticator на компьютере онлайн?

Многие пользователи интересуются — можно ли установить это приложение на ПК и использовать его прямо на Рабочем Столе. Я смог запустить аутентификатор через эмулятор Nox App Player.

Такие эмуляторы создают идентичную копию Андроид-устройства на компьютере и позволяют запустить практически все приложения и множество игр через неё. Выбор среди эмуляторов есть — Nox, BlueStacks, Andy, Droid4x. Выбор я остановил на Ноксе. Он оказался очень легким, быстрым и бесплатным. Плюс ко всему, радует большая совместимость Андроид приложений и широкий выбор настроек.

Для успешного запуска вам потребуется сделать все по-пунктам:

Перейдите на официальный ресурс эмулятора и загрузите последнюю версию.
Проведите установку. Перед началом просмотрите установочное соглашение — там нужно убрать галочки с партнерского ПО.
Запустите Плей Маркет и авторизируйте учетную запись Гугл для возможности прямого скачивания.
Найдите приложение и проведите установку.
Далее запустите Google Authenticator.

Программка работает и выполняет все функции, но есть небольшая проблема со сканированием QR-кодов. Дело в том, что веб-камера зеркально отображает такой код и он не распознается. Я убрал эту проблему следующим образом — сделал скрин, скинул его в обычный Paint, увеличил изображение и сделал отображение по горизонтали. Все сразу же распозналось и я подключился без проблем.

Если вы не хотите выполнять эти манипуляции, тогда просто вводите секретный ключ, предварительно выбрав «Ввести ключ». На этом все, в случае трудностей пишите в комментарии.

Вконтакте

Facebook

Одноклассники

Twitter

Google+

Аутентификация — это… Что такое Аутентификация?

Аутентифика́ция (англ. Authentication) — процедура проверки подлинности^[1], например: проверка подлинности пользователя путём сравнения введённого им пароля с паролем в базе данных пользователей; подтверждение подлинности электронного письма путём проверки цифровой подписи письма по ключу проверки подписи отправителя; проверка контрольной суммы файла на соответствие сумме, заявленной автором этого файла. В русском языке термин применяется в основном в сфере информационных технологий.

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

Аутентификацию не следует путать с авторизацией^[2] (процедурой предоставления субъекту определённых прав) и идентификацией (процедурой распознавания субъекта по его идентификатору).

История

С древних времён перед людьми стояла довольно сложная задача — убедиться в достоверности важных сообщений. Придумывались речевые пароли, сложные печати. Появление методов аутентификации с применением механических устройств сильно упрощало задачу, например, обычный замок и ключ были придуманы очень давно. Пример системы аутентификации можно увидеть в старинной сказке «Приключения Али́-Бабы́ и сорока разбойников». В этой сказке говорится о сокровищах, спрятанных в пещере. Пещера была загорожена камнем. Отодвинуть его можно было только с помощью уникального речевого пароля: «Сезам, откройся!».

В настоящее время в связи с обширным развитием сетевых технологий, автоматическая аутентификация используется повсеместно.

Элементы системы аутентификации

В любой системе аутентификации обычно можно выделить несколько элементов^[3]:

субъект, который будет проходить процедуру аутентификации
характеристика субъекта — отличительная черта
хозяин системы аутентификации, несущий ответственность и контролирующий её работу

сам механизм аутентификации, то есть принцип работы системы
механизм, предоставляющий или лишающий субъекта определенных прав доступа

Элемент аутентификации	Пещера 40 разбойников	Регистрация в системе	Банкомат
Субъект	Человек, знающий пароль	Авторизованный пользователь	Владелец банковской карты
Характеристика	Пароль «Сезам, откройся!»	Секретный пароль	Банковская карта и персональный идентификатор
Хозяин системы	40 разбойников	Предприятие, которому принадлежит система	Банк
Механизм аутентификации	Волшебное устройство, реагирующее на слова	Программное обеспечение, проверяющее пароль	Программное обеспечение, проверяющее карту и идентификатор
Механизм управления доступом	Механизм, отодвигающий камень от входа в пещеру	Процесс регистрации, управления доступом	Разрешение на выполнение банковских операций

Факторы аутентификации

Ещё до появления компьютеров использовались различные отличительные черты субъекта, его характеристики. Сейчас использование той или иной характеристики в системе зависит от требуемой надёжности, защищенности и стоимости внедрения. Выделяют 3 фактора аутентификации^[4]:

Что-то, что мы знаем — пароль. Это секретная информация, которой должен обладать только авторизованный субъект. Паролем может быть речевое слово, текстовое слово, комбинация для замка или персональный идентификационный номер (PIN). Парольный механизм может быть довольно легко реализован и имеет низкую стоимость. Но имеет существенные минусы: сохранить пароль в секрете зачастую бывает проблематично, злоумышленники постоянно придумывают новые методы кражи, взлома и подбора пароля (см. бандитский криптоанализ). Это делает парольный механизм слабозащищенным.

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

Способы аутентификации

Аутентификация по многоразовым паролям

Один из способов аутентификации в компьютерной системе состоит во вводе вашего пользовательского идентификатора, в просторечии называемого «логином» (англ. login — регистрационное имя пользователя) и пароля — некой конфиденциальной информации. Достоверная (эталонная) пара логин-пароль хранится в специальной базе данных.

Простая аутентификация имеет следующий общий алгоритм:

Субъект запрашивает доступ в систему и вводит личный идентификатор и пароль
Введенные уникальные данные поступают на сервер аутентификации, где сравниваются с эталонными
При совпадении данных с эталонными, аутентификация признается успешной, при различии — субъект перемещается к 1-му шагу

Введённый субъектом пароль может передаваться в сети двумя способами:

Незашифрованно, в открытом виде, на основе протокола парольной аутентификации (Password Authentication Protocol, PAP)
С использованием шифрования SSL или TLS. В этом случае уникальные данные, введённые субъектом передаются по сети защищенно.

Защищенность

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

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

Базы учетных записей

На компьютерах с ОС семейства 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.

Однако более надёжным способом хранения аутентификационных данных признано использование специальных аппаратных средств (компонентов).

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

Аутентификация по одноразовым паролям

Заполучив однажды многоразовый пароль субъекта, злоумышленник имеет постоянный доступ к взломанной конфиденциальной информации. Эта проблема решается применением одноразовых паролей (OTP – One Time Password). Суть этого метода — пароль действителен только для одного входа в систему, при каждом следующем запросе доступа — требуется новый пароль. Реализован механизм аутентификации по одноразовым паролям может быть как аппаратно, так и программно.

Технологии использования одноразовых паролей можно разделить на:

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

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

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

Во втором методе используются временные метки. В качестве примера такой технологии можно привести SecurID. Она основана на использовании аппаратных ключей и синхронизации по времени. Аутентификация основана на генерации случайных чисел через определенные временные интервалы. Уникальный секретный ключ хранится только в базе системы и в аппаратном устройстве субъекта. Когда субъект запрашивает доступ в систему, ему предлагается ввести PIN-код, а также случайно генерируемое число, отображаемого в этот момент на аппаратном устройстве. Система сопоставляет введенный PIN-код и секретный ключ субъекта из своей базы и генерирует случайное число, основываясь на параметрах секретного ключа из базы и текущего времени. Далее проверяется идентичность сгенерированного числа и числа, введённого субъектом.

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

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

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

В последнее время всё чаще применяется, так называемая, расширенная или многофакторная аутентификация. Она построена на совместном использовании нескольких факторов аутентификации. Это значительно повышает защищенность системы.

В качестве примера можно привести использование SIM-карт в мобильных телефонах. Субъект вставляет аппаратно свою карту (устройство аутентификации) в телефон и при включении вводит свой PIN-код (пароль).

Также, к примеру в некоторых современных ноутбуках присутствует сканер отпечатка пальца. Таким образом, при входе в систему субъект должен пройти эту процедуру (биометрика), а потом ввести пароль.

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

Можно привести сравнительную таблицу:

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

Протоколы аутентификации

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

Самый простой протокол аутентификации — доступ по паролю (Password Authentication Protocol, PAP). Его суть состоит в том, что вся информация о субъекте (идентификатор и пароль) передается по сети в открытом виде. Это и является главным недостатком PAP, так как злоумышленник может легко получить доступ к передающимся незашифрованным данным.

Более сложные протоколы аутентификации основаны на принципе «запрос-ответ», например, протокол CHAP (Challenge-Handshake Authentication Protocol). Работа протокола типа «запрос-ответ» может состоять минимум из четырех стадий:

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

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

Принцип действия протоколов взаимной аутентификации отличаются от протоколов типа «запрос-ответ» незначительно:

Субъект отправляет системе запрос, содержащий его персональный идентификатор и случайное число N1
Система зашифровывает полученное число N1 на основе уникального ключа, генерирует случайное число N2, и отправляет их оба субъекту
Cубъект расшифровывает полученное число на основе своего уникального ключа и сравнивает результат с N1. Идентичность означает, что система обладает тем же уникальным ключом, что и субъект
Субъект зашифровывает полученное число N2 на основе своего уникального ключа и результат отправляет системе
Система расшифровывает полученное сообщение на основе того же уникального ключа. При совпадении результата с исходным числом N2, взаимная аутентификация проходит успешно.

Алгоритм, приведенный выше, часто называют рукопожатием. В обоих случаях аутентификация проходит успешно, только если субъект имеет идентичные с системой уникальные ключи.

В операционных системах семейства Windows NT 4 используется протокол NTLM (NT LAN Manager — Диспетчер локальной сети NT). А в доменах Windows 2000/2003 применяется гораздо более совершенный протокол Kerberos.

См. также

Примечания

Ссылки

Литература

Ричард Э. Смит Аутентификация: от паролей до открытых ключей = Authentication: From Passwords to Public Keys First Edition. — М.: «Вильямс», 2002. — С. 432. — ISBN 0-201-61599-1

Аутентификация в Интернете — Википедия

Аутентификация — проверка подлинности предъявленного пользователем идентификатора. Аутентификация требуется при доступе к таким интернет-сервисам как:

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

В зависимости от важности ресурса, для доступа к нему могут применяться разные методы аутентификации:

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

Классификация методов аутентификации[править | править код]

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

Базовая аутентификация[править | править код]

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

Дайджест-аутентификация[править | править код]

Это аутентификация, при которой пароль пользователя передается в хешированном виде. Казалось бы, что по уровню конфиденциальности паролей этот тип мало чем отличается от предыдущего, так как атакующему все равно, действительно ли это настоящий пароль или только хеш от него: перехватив сообщение, он все равно получает доступ к конечной точке. Но это не совсем так — пароль хешируется всегда с добавлением произвольной строки символов, которая генерируется на каждое соединение заново. Таким образом при каждом соединении генерируется новый хеш пароля и перехват его ничего не даст. Для более подробного описания алгоритма работы обратитесь к http://www.faqs.org/rfcs/rfc2617.html — RFC2617 — HTTP Authentication: Basic and Digest Access Authentication. Дайджест-аутентификация поддерживается всеми популярными серверами и браузерами.

HTTPS[править | править код]

Протокол HTTPS позволяет шифровать все данные, передаваемые между браузером и сервером, а не только имена пользователей и пароли. Протокол HTTPS (основанный на системе безопасности TLS) следует использовать в случае, если пользователи должны вводить важные личные данные — адрес, номер кредитной карты или банковские сведения. Однако использование данного протокола значительно ^{[насколько?]}^{[источник не указан 1155 дней]} замедляет скорость доступа.

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

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

Аутентификация по Cookies[править | править код]

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

Децентрализованная аутентификация[править | править код]

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

OpenID[править | править код]

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

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

Аутентификация по OpenID сейчас активно используется и предоставляется такими гигантами, как BBC^[6], Google^[7], IBM, Microsoft^[8]MySpace, PayPal, VeriSign, Yandex и Yahoo!^[9]^[10]^[11]

OpenAuth[править | править код]

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

данные сессии (в том числе информация о пользователе) хранятся не в cookies.
cookies аутентификации шифруются алгоритмом ‘PBEWithSHAAnd3-KeyTripleDES-CBC’
доступ к cookies аутентификации ограничен определенным доменом, так что другие сайты не имеют к ним доступа (в том числе сайты AOL)

OAuth[править | править код]

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

Отслеживание аутентификации самим пользователем[править | править код]

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

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

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

Многофакторная аутентификация[править | править код]

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

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

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

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

Обзор способов и протоколов аутентификации в веб-приложениях / DataArt corporate blog / Habr

Я расскажу о применении различных способов аутентификации для веб-приложений, включая аутентификацию по паролю, по сертификатам, по одноразовым паролям, по ключам доступа и по токенам. Коснусь технологии единого входа (Single Sign-On), рассмотрю различные стандарты и протоколы аутентификации.

Перед тем, как перейти к техническим деталям, давайте немного освежим терминологию.

Идентификация — это заявление о том, кем вы являетесь. В зависимости от ситуации, это может быть имя, адрес электронной почты, номер учетной записи, итд.
Аутентификация — предоставление доказательств, что вы на самом деле есть тот, кем идентифицировались (от слова “authentic” — истинный, подлинный).
Авторизация — проверка, что вам разрешен доступ к запрашиваемому ресурсу.

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

Аналогично эти термины применяются в компьютерных системах, где традиционно под идентификацией понимают получение вашей учетной записи (identity) по username или email; под аутентификацией — проверку, что вы знаете пароль от этой учетной записи, а под авторизацией — проверку вашей роли в системе и решение о предоставлении доступа к запрошенной странице или ресурсу.

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

Аутентификация по паролю

Этот метод основывается на том, что пользователь должен предоставить username и password для успешной идентификации и аутентификации в системе. Пара username/password задается пользователем при его регистрации в системе, при этом в качестве username может выступать адрес электронной почты пользователя.

Применительно к веб-приложениям, существует несколько стандартных протоколов для аутентификации по паролю, которые мы рассмотрим ниже.

HTTP authentication

Этот протокол, описанный в стандартах HTTP 1.0/1.1, существует очень давно и до сих пор активно применяется в корпоративной среде. Применительно к веб-сайтам работает следующим образом:

Сервер, при обращении неавторизованного клиента к защищенному ресурсу, отсылает HTTP статус “401 Unauthorized” и добавляет заголовок “WWW-Authenticate” с указанием схемы и параметров аутентификации.
Браузер, при получении такого ответа, автоматически показывает диалог ввода username и password. Пользователь вводит детали своей учетной записи.
Во всех последующих запросах к этому веб-сайту браузер автоматически добавляет HTTP заголовок “Authorization”, в котором передаются данные пользователя для аутентификации сервером.
Сервер аутентифицирует пользователя по данным из этого заголовка. Решение о предоставлении доступа (авторизация) производится отдельно на основании роли пользователя, ACL или других данных учетной записи.

Весь процесс стандартизирован и хорошо поддерживается всеми браузерами и веб-серверами. Существует несколько схем аутентификации, отличающихся по уровню безопасности:

Basic — наиболее простая схема, при которой username и password пользователя передаются в заголовке Authorization в незашифрованном виде (base64-encoded). Однако при использовании HTTPS (HTTP over SSL) протокола, является относительно безопасной.

Пример HTTP аутентификации с использованием Basic схемы.
Digest — challenge-response-схема, при которой сервер посылает уникальное значение nonce, а браузер передает MD5 хэш пароля пользователя, вычисленный с использованием указанного nonce. Более безопасная альтернативв Basic схемы при незащищенных соединениях, но подвержена man-in-the-middle attacks (с заменой схемы на basic). Кроме того, использование этой схемы не позволяет применить современные хэш-функции для хранения паролей пользователей на сервере.
NTLM (известная как Windows authentication) — также основана на challenge-response подходе, при котором пароль не передается в чистом виде. Эта схема не является стандартом HTTP, но поддерживается большинством браузеров и веб-серверов. Преимущественно используется для аутентификации пользователей Windows Active Directory в веб-приложениях. Уязвима к pass-the-hash-атакам.
Negotiate — еще одна схема из семейства Windows authentication, которая позволяет клиенту выбрать между NTLM и Kerberos аутентификацией. Kerberos — более безопасный протокол, основанный на принципе Single Sign-On. Однако он может функционировать, только если и клиент, и сервер находятся в зоне intranet и являются частью домена Windows.

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

Forms authentication

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

Работает это по следующему принципу: в веб-приложение включается HTML-форма, в которую пользователь должен ввести свои username/password и отправить их на сервер через HTTP POST для аутентификации. В случае успеха веб-приложение создает session token, который обычно помещается в browser cookies. При последующих веб-запросах session token автоматически передается на сервер и позволяет приложению получить информацию о текущем пользователе для авторизации запроса.

Пример forms authentication.

Приложение может создать session token двумя способами:

Как идентификатор аутентифицированной сессии пользователя, которая хранится в памяти сервера или в базе данных. Сессия должна содержать всю необходимую информацию о пользователе для возможности авторизации его запросов.
Как зашифрованный и/или подписанный объект, содержащий данные о пользователе, а также период действия. Этот подход позволяет реализовать stateless-архитектуру сервера, однако требует механизма обновления сессионного токена по истечении срока действия. Несколько стандартных форматов таких токенов рассматриваются в секции «Аутентификация по токенам».

Необходимо понимать, что перехват session token зачастую дает аналогичный уровень доступа, что и знание username/password. Поэтому все коммуникации между клиентом и сервером в случае forms authentication должны производиться только по защищенному соединению HTTPS.

Другие протоколы аутентификации по паролю

Два протокола, описанных выше, успешно используются для аутентификации пользователей на веб-сайтах. Но при разработке клиент-серверных приложений с использованием веб-сервисов (например, iOS или Android), наряду с HTTP аутентификацией, часто применяются нестандартные протоколы, в которых данные для аутентификации передаются в других частях запроса.

Существует всего несколько мест, где можно передать username и password в HTTP запросах:

URL query — считается небезопасным вариантом, т. к. строки URL могут запоминаться браузерами, прокси и веб-серверами.
Request body — безопасный вариант, но он применим только для запросов, содержащих тело сообщения (такие как POST, PUT, PATCH).
HTTP header —оптимальный вариант, при этом могут использоваться и стандартный заголовок Authorization (например, с Basic-схемой), и другие произвольные заголовки.

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

Ниже представлен список наиболее часто встречающихся уязвимостей в случае использования аутентификации по паролю:

Веб-приложение позволяет пользователям создавать простые пароли.
Веб-приложение не защищено от возможности перебора паролей (brute-force attacks).
Веб-приложение само генерирует и распространяет пароли пользователям, однако не требует смены пароля после первого входа (т.е. текущий пароль где-то записан).
Веб-приложение допускает передачу паролей по незащищенному HTTP-соединению, либо в строке URL.
Веб-приложение не использует безопасные хэш-функции для хранения паролей пользователей.
Веб-приложение не предоставляет пользователям возможность изменения пароля либо не нотифицирует пользователей об изменении их паролей.
Веб-приложение использует уязвимую функцию восстановления пароля, которую можно использовать для получения несанкционированного доступа к другим учетным записям.
Веб-приложение не требует повторной аутентификации пользователя для важных действий: смена пароля, изменения адреса доставки товаров и т. п.
Веб-приложение создает session tokens таким образом, что они могут быть подобраны или предсказаны для других пользователей.
Веб-приложение допускает передачу session tokens по незащищенному HTTP-соединению, либо в строке URL.
Веб-приложение уязвимо для session fixation-атак (т. е. не заменяет session token при переходе анонимной сессии пользователя в аутентифицированную).
Веб-приложение не устанавливает флаги HttpOnly и Secure для browser cookies, содержащих session tokens.
Веб-приложение не уничтожает сессии пользователя после короткого периода неактивности либо не предоставляет функцию выхода из аутентифицированной сессии.

Аутентификация по сертификатам

Сертификат представляет собой набор атрибутов, идентифицирующих владельца, подписанный certificate authority (CA). CA выступает в роли посредника, который гарантирует подлинность сертификатов (по аналогии с ФМС, выпускающей паспорта). Также сертификат криптографически связан с закрытым ключом, который хранится у владельца сертификата и позволяет однозначно подтвердить факт владения сертификатом.

На стороне клиента сертификат вместе с закрытым ключом могут храниться в операционной системе, в браузере, в файле, на отдельном физическом устройстве (smart card, USB token). Обычно закрытый ключ дополнительно защищен паролем или PIN-кодом.

В веб-приложениях традиционно используют сертификаты стандарта X.509. Аутентификация с помощью X.509-сертификата происходит в момент соединения с сервером и является частью протокола SSL/TLS. Этот механизм также хорошо поддерживается браузерами, которые позволяют пользователю выбрать и применить сертификат, если веб-сайт допускает такой способ аутентификации.

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

Во время аутентификации сервер выполняет проверку сертификата на основании следующих правил:

Сертификат должен быть подписан доверенным certification authority (проверка цепочки сертификатов).
Сертификат должен быть действительным на текущую дату (проверка срока действия).
Сертификат не должен быть отозван соответствующим CA (проверка списков исключения).

Пример X.509 сертификата.

После успешной аутентификации веб-приложение может выполнить авторизацию запроса на основании таких данных сертификата, как subject (имя владельца), issuer (эмитент), serial number (серийный номер сертификата) или thumbprint (отпечаток открытого ключа сертификата).

Использование сертификатов для аутентификации — куда более надежный способ, чем аутентификация посредством паролей. Это достигается созданием в процессе аутентификации цифровой подписи, наличие которой доказывает факт применения закрытого ключа в конкретной ситуации (non-repudiation). Однако трудности с распространением и поддержкой сертификатов делает такой способ аутентификации малодоступным в широких кругах.

Аутентификация по одноразовым паролям

Аутентификация по одноразовым паролям обычно применяется дополнительно к аутентификации по паролям для реализации two-factor authentication (2FA). В этой концепции пользователю необходимо предоставить данные двух типов для входа в систему: что-то, что он знает (например, пароль), и что-то, чем он владеет (например, устройство для генерации одноразовых паролей). Наличие двух факторов позволяет в значительной степени увеличить уровень безопасности, что м. б. востребовано для определенных видов веб-приложений.

Другой популярный сценарий использования одноразовых паролей — дополнительная аутентификация пользователя во время выполнения важных действий: перевод денег, изменение настроек и т. п.

Существуют разные источники для создания одноразовых паролей. Наиболее популярные:

Аппаратные или программные токены, которые могут генерировать одноразовые пароли на основании секретного ключа, введенного в них, и текущего времени. Секретные ключи пользователей, являющиеся фактором владения, также хранятся на сервере, что позволяет выполнить проверку введенных одноразовых паролей. Пример аппаратной реализаций токенов — RSA SecurID; программной — приложение Google Authenticator.
Случайно генерируемые коды, передаваемые пользователю через SMS или другой канал связи. В этой ситуации фактор владения — телефон пользователя (точнее — SIM-карта, привязанная к определенному номеру).
Распечатка или scratch card со списком заранее сформированных одноразовых паролей. Для каждого нового входа в систему требуется ввести новый одноразовый пароль с указанным номером.

Аппаратный токен 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) приложение использует этот токен для идентификации, аутентификации и авторизации пользователя.
На общем уровне, весь процесс выглядит следующим образом:

Клиент аутентифицируется в identity provider одним из способов, специфичным для него (пароль, ключ доступа, сертификат, Kerberos, итд.).
Клиент просит identity provider предоставить ему токен для конкретного SP-приложения. Identity provider генерирует токен и отправляет его клиенту.
Клиент аутентифицируется в SP-приложении при помощи этого токена.

Пример аутентификации «активного» клиента при помощи токена, переданного посредством Bearer схемы.

Процесс, описанный выше, отражает механизм аутентификации активного клиента, т. е. такого, который может выполнять запрограммированную последовательность действий (например, iOS/Android приложения). Браузер же — пассивный клиент в том смысле, что он только может отображать страницы, запрошенные пользователем. В этом случае аутентификация достигается посредством автоматического перенаправления браузера между веб-приложениями identity provider и service provider.

Пример аутентификации «пассивного» клиента посредством перенаправления запросов.

Существует несколько стандартов, в точности определяющих протокол взаимодействия между клиентами (активными и пассивными) и IP/SP-приложениями и формат поддерживаемых токенов. Среди наиболее популярных стандартов — OAuth, OpenID Connect, SAML, и WS-Federation. Некоторая информация об этих протоколах — ниже в статье.

Сам токен обычно представляет собой структуру данных, которая содержит информацию, кто сгенерировал токен, кто может быть получателем токена, срок действия, набор сведений о самом пользователе (claims). Кроме того, токен дополнительно подписывается для предотвращения несанкционированных изменений и гарантий подлинности.

При аутентификации с помощью токена SP-приложение должно выполнить следующие проверки:

Токен был выдан доверенным identity provider приложением (проверка поля issuer).
Токен предназначается текущему SP-приложению (проверка поля audience).
Срок действия токена еще не истек (проверка поля expiration date).
Токен подлинный и не был изменен (проверка подписи).

В случае успешной проверки SP-приложение выполняет авторизацию запроса на основании данных о пользователе, содержащихся в токене.

Форматы токенов

Существует несколько распространенных форматов токенов для веб-приложений:

Simple Web Token (SWT) — наиболее простой формат, представляющий собой набор произвольных пар имя/значение в формате кодирования HTML form. Стандарт определяет несколько зарезервированных имен: Issuer, Audience, ExpiresOn и HMACSHA256. Токен подписывается с помощью симметричного ключа, таким образом оба IP- и SP-приложения должны иметь этот ключ для возможности создания/проверки токена.
Пример SWT токена (после декодирования).
Issuer=http://auth.myservice.com&
Audience=http://myservice.com&
ExpiresOn=1435937883&
UserName=John Smith&
UserRole=Admin&
HMACSHA256=KOUQRPSpy64rvT2KnYyQKtFFXUIggnesSpE7ADA4o9w
JSON Web Token (JWT) — содержит три блока, разделенных точками: заголовок, набор полей (claims) и подпись. Первые два блока представлены в JSON-формате и дополнительно закодированы в формат base64. Набор полей содержит произвольные пары имя/значения, притом стандарт JWT определяет несколько зарезервированных имен (iss, aud, exp и другие). Подпись может генерироваться при помощи и симметричных алгоритмов шифрования, и асимметричных. Кроме того, существует отдельный стандарт, отписывающий формат зашифрованного JWT-токена.
Пример подписанного JWT токена (после декодирования 1 и 2 блоков).
{ «alg»: «HS256», «typ»: «JWT» }.
{ «iss»: «auth.myservice.com», «aud»: «myservice.com», «exp»: «1435937883», «userName»: «John Smith», «userRole»: «Admin» }.
S9Zs/8/uEGGTVVtLggFTizCsMtwOJnRhjaQ2BMUQhcY
Security Assertion Markup Language (SAML) — определяет токены (SAML assertions) в XML-формате, включающем информацию об эмитенте, о субъекте, необходимые условия для проверки токена, набор дополнительных утверждений (statements) о пользователе. Подпись SAML-токенов осуществляется при помощи ассиметричной криптографии. Кроме того, в отличие от предыдущих форматов, SAML-токены содержат механизм для подтверждения владения токеном, что позволяет предотвратить перехват токенов через man-in-the-middle-атаки при использовании незащищенных соединений.

Стандарт SAML

Стандарт Security Assertion Markup Language (SAML) описывает способы взаимодействия и протоколы между identity provider и service provider для обмена данными аутентификации и авторизации посредством токенов. Изначально версии 1.0 и 1.1 были выпущены в 2002 – 2003 гг., в то время как версия 2.0, значительно расширяющая стандарт и обратно несовместимая, опубликована в 2005 г.

Этот основополагающий стандарт — достаточно сложный и поддерживает много различных сценариев интеграции систем. Основные «строительные блоки» стандарта:

Assertions — собственный формат SAML токенов в XML формате.
Protocols — набор поддерживаемых сообщений между участниками, среди которых — запрос на создание нового токена, получение существующих токенов, выход из системы (logout), управление идентификаторами пользователей, и другие.
Bindings — механизмы передачи сообщений через различные транспортные протоколы. Поддерживаются такие способы, как HTTP Redirect, HTTP POST, HTTP Artifact (ссылка на сообщения), SAML SOAP, SAML URI (адрес получения сообщения) и другие.
Profiles — типичные сценарии использования стандарта, определяющие набор assertions, protocols и bindings необходимых для их реализации, что позволяет достичь лучшей совместимости. Web Browser SSO — один из примеров таких профилей.

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

Рассмотрим краткий пример использования 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 определяет:

Формат и способы обмена метаданными о сервисах.
Функцию единого выхода из всех систем (single sign-out).
Сервис атрибутов, предоставляющий дополнительную информацию о пользователе.
Сервис псевдонимов, позволяющий создавать альтернативные имена пользователей.
Поддержку пассивных клиентов (браузеров) посредством перенаправления.

Можно сказать, что 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). В общем виде весь процесс состоит из нескольких шагов:

Пользователь (resource owner) дает разрешение приложению (client) на доступ к определенному ресурсу в виде гранта. Что такое грант, рассмотрим чуть ниже.
Приложение обращается к серверу авторизации и получает токен доступа к ресурсу в обмен на свой грант. В нашем примере сервер авторизации — Google. При вызове приложение дополнительно аутентифицируется при помощи ключа доступа, выданным ему при предварительной регистрации.
Приложение использует этот токен для получения требуемых данных от сервера ресурсов (в нашем случае — сервис Gmail).

Взаимодействие компонентов в стандарте OAuth.

Стандарт описывает четыре вида грантов, которые определяют возможные сценарии применения:

Authorization Code — этот грант пользователь может получить от сервера авторизации после успешной аутентификации и подтверждения согласия на предоставление доступа. Такой способ наиболее часто используется в веб-приложениях. Процесс получения гранта очень похож на механизм аутентификации пассивных клиентов в SAML и WS-Federation.
Implicit — применяется, когда у приложения нет возможности безопасно получить токен от сервера авторизации (например, JavaScript-приложение в браузере). В этом случае грант представляет собой токен, полученный от сервера авторизации, а шаг № 2 исключается из сценария выше.
Resource Owner Password Credentials — грант представляет собой пару username/password пользователя. Может применяться, если приложение является «интерфейсом» для сервера ресурсов (например, приложение — мобильный клиент для Gmail).
Client Credentials — в этом случае нет никакого пользователя, а приложение получает доступ к своим ресурсам при помощи своих ключей доступа (исключается шаг № 1).

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

Зачастую API сервера ресурсов включает операцию, предоставляющую информацию о самом пользователе (например, /me в Facebook API). Приложение может выполнять эту операцию каждый раз после получения токена для идентификации клиента. Такой метод иногда называют псевдо-аутентификацией.
Использовать стандарт OpenID Connect, разработанный как слой учетных данных поверх OAuth (опубликован в 2014 г.). В соответствии с этим стандартом, сервер авторизации предоставляет дополнительный identity token на шаге № 2. Этот токен в формате JWT будет содержать набор определенных полей (claims) с информацией о пользователе.

Стоит заметить, что OpenID Connect, заменивший предыдущие версии стандарта OpenID 1.0 и 2.0, также содержит набор необязательных дополнений для поиска серверов авторизации, динамической регистрации клиентов и управления сессией пользователя.

Заключение

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

Способ	Основное применение	Протоколы
По паролю	Аутентификация пользователей	HTTP, Forms
По сертификатам	Аутентификация пользователей в безопасных приложениях; аутентификация сервисов	SSL/TLS
По одноразовым паролям	Дополнительная аутентификация пользователей (для достижения two-factor authentication)	Forms
По ключам доступа	Аутентификация сервисов и приложений	—
По токенам	Делегированная аутентификация пользователей; делегированная авторизация приложений	SAML, WS-Federation, OAuth, OpenID Connect

Надеюсь, что информация оказалась полезна, и вы сможете применить ее при дизайне и разработке новых приложений. До новых встреч!

Автор: Дмитрий Выростков, Solutions Architect в DataArt.

аутентификатор — это… Что такое аутентификатор?

аутентификатор

аутентификатор
Блок данных, добавленный к сообщению, зашифрованный с помощью асимметричного криптографического алгоритма и используемый в процессе передачи сообщения для проверки подлинности отправителя и целостности сообщения.
[ОСТ 45.127-99]

Тематики

защита информации

Справочник технического переводчика. – Интент. 2009-2013.

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

Смотреть что такое «аутентификатор» в других словарях:

отделять аутентификатор от одного сообщения, чтобы аутентифицировать другое — — [http://www.rfcmd.ru/glossword/1.8/index.php?a=index&d=4583] Тематики защита информации EN strip an authenticates off one message to authenticate another … Справочник технического переводчика
проверять аутентификатор — — [http://www.rfcmd.ru/glossword/1.8/index.php?a=index&d=5053] Тематики защита информации EN verify an authenticates … Справочник технического переводчика
Kerberos — /kɛərbərəs/ сетевой протокол аутентификации, позволяющий передавать данные через незащищённые сети для безопасной идентификации. Ориентирован , в первую очередь , на клиент серверную модель и обеспечивает взаимную аутентификацию оба… … Википедия
BitTorrent — Эта статья о протоколе. Статья о клиенте: BitTorrent (программа). BitTórrent (букв. англ. «битовый поток») пиринговый (P2P) сетевой протокол для кооперативного обмена файлами через Интернет. Файлы передаются частями, каждый torrent… … Википедия
аутентификация данных (цифровая подпись) — Процесс подтверждения подлинности (отсутствия фальсификации или искажения) произвольных данных, предъявленных в электронной форме. Данные могут представлять собой: сообщения, файл, элемент базы данных (программы), идентификатор (аутентификатор)… … Справочник технического переводчика

Почему вам больше никогда не стоит использовать Google Authenticator |

Не бывает достаточной безопасности. С другой стороны, использование глючной или слабой защиты может дать вам шаткую иллюзию безопасности, в то время, как вы остаётесь уязвимым к разного рода угрозам.

Использование только паролей, в общем – плохая идея, мы выяснили это с тех пор, как появился Интернет. Мы осуществляем прогресс, двигаясь к миру без паролей, но в то же время, многие веб-сайты предлагают дополнительную защиту пользовательских аккаунтов с помощью Двух-Факторной Аутентификации (2FA).

В общем и целом, существует 2 типа такой аутентификации: Временный одноразовый пароль (TOTP) а также Универсальный Двух-Фактор (U2F). Вы можете быть уже знакомы с первым типом, поскольку он используется наиболее часто: во время логина, предлагается ввести одноразовый пароль, генерируемый вашим приложением на смартфоне, отдельным аппаратным устройством, или же присылаемый в СМС. Метод прост, но есть несколько простых способов, делающих его опасным.

pic_one

Я видел предупреждения типа “мой телефон взломали” от трёх людей из Кремниевой Долины/Биткойн среды/венчурной тусни. Будьте на чеку, и включите 2FA.

Как работает TOTP?

Временный одноразовый пароль, в основном популяризованный приложением Google Authenticator, подтверждает вашу личность на основании общего секрета. Этот секрет дложен быть известен вам и вашему провайдеру.

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

Обе стороны генерируют одинаковый хеш, из одинаковых исходных данных, делясь секретом в момент регистрации.

В чём неадекватность TOTP?

Метод весьма прост в использовании, однако, он не лишён нескольких уязвимостей и неудобств.

1. Вам необходимо вручную вводить код во время авторизации (логина)

2. Слишком громоздкий бэкап. Вам необходимо совершать много шагов, чтобы сделать бэкап секрета. Кроме того, хорошие сервисы обычно предоставляют резервные коды, вместо того, чтобы явным образом призывать сохранять секрет. Если вы потеряете ваш секрет, и логин вместе с резервным кодом, вам придётся выполнить весь процесс регистрации TOTP заново.

3. Коды бекапа высылаются через Интернет, что совершенно небезопасно.

4. У вас и провайдера один и тот же секрет. Если атакующий хакнет компанию и получит доступ и к базе паролей, и к базе секретов, он сможет проникать в любой аккаунт совершенно незаметно.

5. Секрет показывается простым текстом или QR-кодом. Он не может быть представлен в виде хеша. Это также означает, что скорее всего секрет хранится в виде текстового файла, на серверах провайдера.

6. Секрет может быть раскрыт во время регистрации, так как провайдеру необходимо выдать вам сгенерированный секрет. Используя TOTP, вам нужно верить в способность провайдеров защитить приватность секрета. Но можете ли вы верить?

Как работает FIDO/U2F?

Стандарт U2F, разработанный Альянсом FIDO, был создан технологическими корпорациями, вроде Google и Microsoft, под влиянием найденных уязвимостей в TOTP. U2F использует криптографию с публичными ключами для подтверждения вашей личности (Reddit – “Объясняйте, будто мне лет пять”). В противовес TOTP, в данном варианте вы являетесь единственным, кто знает секрет (приватный ключ).

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

Выгоды U2F:

1. Через Интернет никогда не пересылается секрет (приватный ключ)

Никакая конфиденциальная информация не будет опубликована, благодаря криптографии публичного ключа.

2. Легче использовать. Нет нужды применять одноразовые коды.

3. Приватность. С секретом не ассоциируется никакая персональная информация.

4. Бекап теоретически легче. Однако, не всегда возможен; например, вы не сможете бекапить Yubikey.

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

Более того, вы можете забекапить ваш секрет (приватный ключ). С одной стороны, это делает вас ответственным за вашу же безопасность, но с другой – вам больше не нужно доверять какой-то компании, чтобы защитить ваши секреты (приватные ключи).

TREZOR – U2F “по-нашенски”

TREZOR представляет собой маленькое отдельное аппаратное решение, разработанное для хранения приватных ключей и работы в качестве изолированного компьютерного окружения. Изначально разработанный, как безопасный “железный” кошелек для Биткойна, рамки его применения значительно расширились благодаря расширяемости асимметричной криптографии. Теперь, TREZOR может служить в качестве безопасного железного токена для U2F, вам также придётся дополнительно подтверждать логин нажатием кнопки на устройстве.

В отличии от некоторых других токенов, TREZOR всегда использует уникальную подпись для каждого зарегистрированного пользовательского аккаунта. Кроме прочего, устройство выводит U2F на совершенно новый уровень:

1. Легко бекапить и восстанавливать. TREZOR просит вас записать на листочке так называемое “зернышко” (recovery seed), в время первого запуска устройства. Это –, единственный одноразовый процесс из всех остальных на устройстве. Восстановительное зёрнышко представляет собой все секреты (приватные ключи), генерируемые устройством и могут быть использованы в любое время для “восстановления” вашего аппаратного (или “железного”) кошелька.

2. Неограниченное количество U2F личностей, все они сохраняются в рамках единого бэкапа.

3. Секрет безопасно хранится в TREZORе. Его никто никогда не узнает, так как он не может покинуть устройство. Их не смогут украсть ни вирусы, ни хакеры.

4. Защита от фишинга с подтверждением на экране. Кошелёк всегда отображает url веб-сайта, на котором вы логинитесь, а также то, что именно вы хотите авторизовать. Вы можете убедиться, что информация, отправленная в устройство, соответствует вашим ожиданиям.

5. Дополнительная информация по использовании U2F во время настройки, использования и восстановления TREZOR может быть найдена в нашем посте в блоге, или в Пользовательской Документации.

Безопасные характеристики асимметричной криптографии кореллируют с философией безопасности TREZOR. С поддержкой U2F в кошельке, мы вдохновляем пользователей использовать все доступные меры для защиты их аккаунтов и личных данных в онлайне.

Источник: blog.trezor.io

Поделиться ссылкой:

Что делать, если Google authenticator всегда выдает неправильные коды / Habr

Доброго времени суток.
Я хотел бы рассказать вам о проблемах 2FA аутентификации на устройствах Android 4.4.2 KitKat и о решении, которое в нашем случае прекратило долгие поиски.

Некоторое время назад мы с коллегами решили добавить Двухэтапную аутентификацию (Two factor authentication или для краткости 2FA) для нашего маленького офисного сервера на базе Ubuntu Server.

2FA это дополнительный уровень безопасности и приятное дополнение к уже существующему механизму аутентификации. Кроме обычной пары логин + пароль от пользователя, выполняющего авторизацию, требуется цифровой ключ, который динамически изменяется каждые 30 секунд и генерируется устройством, находящимся во владении пользователя. Для генерации ключа мы использовали Приложение Google authenticator и мобильный телефон на платформе Android. После разовой настройки приложение генерирует коды, имеющие срок жизни в 30 секунд, точно такие же коды генерирует сервер. При аутентификации коды сравниваются.

Так как данные не передаются от сервера и хранятся только на устройстве — этот механизм является более безопасным, чем отправка кодов подтверждения (например, как 3D-secure SMS подтверждение в банковских системах).

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

После настроек сервера установили на телефон Lenovo p780 приложение Google Authenticator, «прочитали» телефоном с монитора QR-code и получили заветные циферки для авторизации. Перед тем как перезагрузить SSH не забывайте сохранить резервные ключи для восстановления доступа.

И вот, все готово к использованию! Перезагружаем SSH, заходим на сервер, указываем пароль, после пароля нас просят предъявить Verification code, переписываем его с телефона и… снова просят указать пароль?!!! Выглядит это так:

ssh [email protected]
Password: <вводим пароль>
Verification code: <вводим код с телефона>
Password: <?!!, вводим пароль еще раз>
Verification code: <вводим код с телефона>
Password: <еще раз вводим пароль>
Verification code: <еще раз вводим код>
[email protected]’s password: <еще раз пароль>
Permission denied, please try again.
[email protected]’s password: <снова вводим пароль>
Received disconnect from xx.xxx.xx.xx: 2: Too many authentication failures for user

Вначале думали, что ошибка допущена в настройках, но испробовав несколько мобильных устройств стало очевидно, что коды генерируемые на Android 4.4.2 KitKat приложением Google Authenticator всегда ошибочны.

«Решения», которые удалось найти и их результаты:

Если откатить версию Android, начинает работать корректно. (с этим «решением» работали какое то время, но решили двигаться дальше)
Так как проблема сводится к некорректным часовым поясам — многие решения направлены именно на их исправление. Приложение TimeZone Fixer действительно может помочь с этой проблемой, однако часть приложений после его использования начинает отображать ошибочное время и потребуется чинить их вручную. (решение имеет свои минусы и риски. вся информация о приложении доступна на сайте 4pda)
Подгонять время вручную. Если честно этот способ у нас так и не заработал. Перевести часы вручную и тем самым синхронизировать время на телефоне и сервере. Увы, все попытки ничего не дали, хотя были люди утверждающие, что у них заработало. В любом случае перспектива потерять функцию часов в телефоне не самая приятная…
Синхронизация часов внутри настроек приложения Google authenticator (в нашем случае без результатов, однако были комментарии, что кому то помогло)

Финальное решение проблемы: FreeOTP

За время поиска решения в сети я уже натыкался на GitHub приложения Google Authenticator, в трекинге ошибок есть наша, и в качестве решения предложено:

«You can used FreeOTP Authenticator(by Red Hat) instead of Google Authenticator until someone fix it.»

Долгое время мне казалось, что рекомендуется использовать другой механизм-аутентификатор, который нужно ставить на сервер вместо Google, поэтому я усердно искал другие решения. Хотелось заставить работать именно Google authenticator, но на самом же деле рекомендуют использовать другое приложение для Android, а серверная часть остается без изменений.

Приложение FreeOTP Authenticator от компании Red Hat. После настройки по тому же QR-коду все начало работать без необходимости что то корректировать.

К сожалению я не могу указать вам причину возникновения ошибки в приложении Google authenticator, но надеюсь, что мой печальный опыт поможет сэкономить чье-то время.

Буду рад вашим комментариям! Спасибо за внимание.