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

Аутентифика́ция (англ. authentication < греч. αὐθεντικός [authentikos] «реальный, подлинный» < αὐτός [autos] «сам; он самый») — процедура проверки подлинности, например:

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

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

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

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

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

Документы, определяющие стандарты аутентификации

ГОСТ Р ИСО/МЭК 9594-8-98 — Основы аутентификации[править | править код]

Настоящий стандарт:

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

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

FIPS 113 — COMPUTER DATA AUTHENTICATION[править | править код]

Настоящий стандарт устанавливает Data Authentication Algorithm(DAA), который может быть использован для обнаружения несанкционированных изменений данных, как преднамеренных, так и случайных, стандарт основан на алгоритме, указанном в Data Encryption Standard(DES) Federal Information Processing Standards Publication(FIPS PUB) 46, и совместим как с Department of the Treasury’s Electronic Funds and Security Transfer Policy and the American National Standards Institute(ANSI) так и с Standard for Financial Institution Message Authentication.

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

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

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

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

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

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

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

Федеральный закон от 06.04.2011 N 63-ФЗ «Об электронной подписи» (с изменениями) предусматривает следующие виды электронной подписи:

• Простая электронная подпись
   — электронная подпись, которая посредством использования кодов, паролей или иных средств подтверждает факт формирования электронной подписи определенным лицом.
• Неквалифицированная электронная подпись — электронная подпись, которая:

1. получена в результате криптографического преобразования информации с использованием ключа электронной подписи;
2. позволяет определить лицо, подписавшее электронный документ;
3. позволяет обнаружить факт внесения изменений в электронный документ после момента его подписания;
4. создается с использованием средств электронной подписи.

• Квалифицированная электронная подпись — электронная подпись, которая соответствует всем признакам неквалифицированной электронной подписи и следующим дополнительным признакам:

1. ключ проверки электронной подписи указан в квалифицированном сертификате;
2. для создания и проверки электронной подписи используются средства электронной подписи, получившие подтверждение соответствия требованиям, установленным в соответствии с настоящим Федеральным законом.

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

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

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

Форма ввода связки логин-пароля

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

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

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

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

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

Защищённость[править | править код]

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

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

Базы учетных записей[править | править код]

На компьютерах с ОС семейства 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-код и секретный ключ субъекта из своей базы и генерирует случайное число, основываясь на параметрах секретного ключа из базы и текущего времени. Далее проверяется идентичность сгенерированного числа и числа, введённого субъектом.

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

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

Аутентификация с помощью SMS[править | править код]

Актуальность обеспечения безопасности мобильных средств коммуникации, например, ip-phone, стимулирует новые разработки в этой области. Среди них можно назвать аутентификацию с помощью SMS-сообщений.

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

1. Ввод имени пользователя и пароля
2. Сразу после этого PhoneFactor (служба безопасности) присылает одноразовый аутентификационный ключ в виде текстового SMS-сообщения.
3. Полученный ключ используется для аутентификации

Привлекательность данного метода заключается в том, что ключ получается не по тому каналу, по которому производится аутентификация (out-of-band), что практически исключает атаку типа «человек посередине». Дополнительный уровень безопасности может дать требование ввода PIN-кода мобильного средства.

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

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

Методы аутентификации, основанные на измерении биометрических параметров человека, обеспечивают почти 100 % идентификацию, решая проблемы утраты паролей и личных идентификаторов.

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

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

Наиболее используемые биометрические атрибуты и соответствующие системы[править | править код]

• Отпечатки пальцев. Такие сканеры имеют небольшой размер, универсальны, относительно недороги. Биологическая повторяемость отпечатка пальца составляет 10⁻⁵ %. В настоящее время пропагандируются правоохранительными органами из-за крупных ассигнований в электронные архивы отпечатков пальцев.
• Геометрия руки. Соответствующие устройства используются, когда из-за грязи или травм трудно применять сканеры пальцев. Биологическая повторяемость геометрии руки около 2 %.
• Радужная оболочка глаза. Данные устройства обладают наивысшей точностью. Теоретическая вероятность совпадения двух радужных оболочек составляет 1 из 10⁷⁸.
• Термический образ лица. Системы позволяют идентифицировать человека на расстоянии до десятков метров. В комбинации с поиском данных по базе данных такие системы используются для опознания авторизованных сотрудников и отсеивания посторонних. Однако при изменении освещенности сканеры лица имеют относительно высокий процент ошибок.
• Распознавание по лицу. Системы на основе данного подхода позволяют идентифицировать персону в определенных условиях с погрешностью не более 3 %. В зависимости от метода позволяют идентифицировать человека на расстояниях от полуметра до нескольких десятков метров. Данный метод удобен тем, что он позволяет реализацию штатными средствами (веб-камера и т. п.). Более сложные методы требуют более изощренных устройств. Некоторые (не все) методы обладают недостатком подмены: можно провести идентификацию подменив лицо реального человека на его фотографию.
• Голос. Проверка голоса удобна для использования в телекоммуникационных приложениях. Необходимые для этого 16-разрядная звуковая плата и конденсаторный микрофон стоят менее 25 $. Вероятность ошибки составляет 2 — 5 %. Данная технология подходит для верификации по голосу по телефонным каналам связи, она более надежна по сравнению с частотным набором личного номера. Сейчас развиваются направления идентификации личности и его состояния по голосу — возбужден, болен, говорит правду, не в себе и т. д.
• Ввод с клавиатуры. Здесь при вводе, например, пароля отслеживаются скорость и интервалы между нажатиями.
• Подпись. Для контроля рукописной подписи используются дигитайзеры

В то же время биометрическая аутентификация имеет ряд недостатков:

1. Биометрический шаблон сравнивается не с результатом первоначальной обработки характеристик пользователя, а с тем, что пришло к месту сравнения. За время пути может много чего произойти.
2. База шаблонов может быть изменена злоумышленником.
3. Следует учитывать разницу между применением биометрии на контролируемой территории, под бдительным оком охраны, и в «полевых» условиях, когда, например, к устройству сканирования могут поднести муляж и т. п.
4. Некоторые биометрические данные человека меняются (как в результате старения, так и травм, ожогов, порезов, болезни, ампутации и т. д.), так что база шаблонов нуждается в постоянном сопровождении, а это создает определенные проблемы и для пользователей, и для администраторов.
5. Если у Вас крадут биометрические данные или их компрометируют, то это, как правило, на всю жизнь. Пароли, при всей их ненадежности, в крайнем случае можно сменить. Палец, глаз или голос сменить нельзя, по крайней мере быстро.
6. Биометрические характеристики являются уникальными идентификаторами, но их нельзя сохранить в секрете.

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

• Аутентификация посредством GPS
• Аутентификация, основанная на местоположении выхода в интернет

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

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

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

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

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

Аутентификация, основанная на местоположении выхода в интернет[править | править код]

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

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

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

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

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

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

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

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

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

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

Таким образом, можно выделить несколько семейств аутентификации:

Аутентификация пользователя на PC:

• Шифрованное имя (login)
• Password Authentication Protocol, PAP (связка логин-пароль)
• Карта доступа (USB с сертификатом, SSO)
• Биометрия (голос, отпечаток пальца/ладони/радужки глаза)

Аутентификация в сети:

В операционных системах семейства 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.
• под. редакцией А.А. Шелупанова, С.Л. Груздева, Ю.С. Нахаева. Аутентификация. Теория и практика обеспечения доступа к информационным ресурсам. = Authentication. Theory and practice of ensuring access to information resources.. — М.: Горячая линия – Телеком, 2009. — С. 552. — ISBN 978-5-9912-0110-0.
• Шнайер Б. Прикладная криптография. Протоколы, алгоритмы, исходные тексты на языке Си = Applied Cryptography. Protocols, Algorithms and Source Code in C. — М.: Триумф, 2002. — 816 с. — 3000 экз. — ISBN 5-89392-055-4.
• Linn J. Common Authentication Technology Overview,.
• Bellovin S. and M. Merritt. Limitations of the Kerberos Authentication System.
• Kaufman, C. Distributed Authentication Security Service (DASS).
• Anderson, B.,. TACACS User Identification Telnet Option. — December 1984.
• Tardo J. and K. Alagappan. SPX: Global Authentication Using Public Key Certificates. — М.California, 1991. — С. pp.232-244.
• А.А. Гладких, В.Е. Дементьев. Базовые принципы информационной безопасности вычислительных сетей.. — Ульяновск: УлГТУ, 2009. — С. 156.

ru.wikipedia.org

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

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

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

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

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

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

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

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

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

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

HTTP authentication

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

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

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

1. Basic — наиболее простая схема, при которой username и password пользователя передаются в заголовке Authorization в незашифрованном виде (base64-encoded). Однако при использовании HTTPS (HTTP over SSL) протокола, является относительно безопасной.
   
   Пример HTTP аутентификации с использованием Basic схемы.
2. Digest — challenge-response-схема, при которой сервер посылает уникальное значение nonce, а браузер передает MD5 хэш пароля пользователя, вычисленный с использованием указанного nonce. Более безопасная альтернативв Basic схемы при незащищенных соединениях, но подвержена man-in-the-middle attacks (с заменой схемы на basic). Кроме того, использование этой схемы не позволяет применить современные хэш-функции для хранения паролей пользователей на сервере.
3. NTLM (известная как Windows authentication) — также основана на challenge-response подходе, при котором пароль не передается в чистом виде. Эта схема не является стандартом HTTP, но поддерживается большинством браузеров и веб-серверов. Преимущественно используется для аутентификации пользователей Windows Active Directory в веб-приложениях. Уязвима к pass-the-hash-атакам.
4. 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 двумя способами:

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

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

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

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

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

1. URL query — считается небезопасным вариантом, т. к. строки URL могут запоминаться браузерами, прокси и веб-серверами.
2. Request body — безопасный вариант, но он применим только для запросов, содержащих тело сообщения (такие как POST, PUT, PATCH).
3. 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. Этот механизм также хорошо поддерживается браузерами, которые позволяют пользователю выбрать и применить сертификат, если веб-сайт допускает такой способ аутентификации.

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

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

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

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

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

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

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

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

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

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

1. Аппаратные или программные токены, которые могут генерировать одноразовые пароли на основании секретного ключа, введенного в них, и текущего времени. Секретные ключи пользователей, являющиеся фактором владения, также хранятся на сервере, что позволяет выполнить проверку введенных одноразовых паролей. Пример аппаратной реализаций токенов — RSA SecurID; программной — приложение Google Authenticator.
2. Случайно генерируемые коды, передаваемые пользователю через SMS или другой канал связи. В этой ситуации фактор владения — телефон пользователя (точнее — SIM-карта, привязанная к определенному номеру).
3. Распечатка или 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) приложение использует этот токен для идентификации, аутентификации и авторизации пользователя.
На общем уровне, весь процесс выглядит следующим образом:

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

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

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

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

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

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

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

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

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

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

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

1. 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

   
   
2. 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

3. 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 г.

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

1. Assertions — собственный формат SAML токенов в XML формате.
2. Protocols — набор поддерживаемых сообщений между участниками, среди которых — запрос на создание нового токена, получение существующих токенов, выход из системы (logout), управление идентификаторами пользователей, и другие.
3. Bindings — механизмы передачи сообщений через различные транспортные протоколы. Поддерживаются такие способы, как HTTP Redirect, HTTP POST, HTTP Artifact (ссылка на сообщения), SAML SOAP, SAML URI (адрес получения сообщения) и другие.
4. 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). В общем виде весь процесс состоит из нескольких шагов:

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

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

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

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

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

1. Зачастую API сервера ресурсов включает операцию, предоставляющую информацию о самом пользователе (например, /me в Facebook API). Приложение может выполнять эту операцию каждый раз после получения токена для идентификации клиента. Такой метод иногда называют псевдо-аутентификацией.
2. Использовать стандарт 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.

habr.com

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

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

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

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

Тип ресурса	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) следует использовать в случае, если пользователи должны вводить важные личные данные — адрес, номер кредитной карты или банковские сведения. Однако использование данного протокола значительно ^{[насколько?][источник не указан 1095 дней]} замедляет скорость доступа.

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

Механизмы аутентификации с применением цифровых сертификатов, как правило, используют протокол с запросом и ответом. Сервер аутентификации отправляет пользователю последовательность символов, так называемый запрос. В качестве ответа выступает запрос сервера аутентификации, подписанный с помощью закрытого ключа пользователя. Аутентификация с открытым ключом используется как защищенный механизм аутентификации в таких протоколах как 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 секунд), либо по запросу (при нажатии на кнопку). Каждый такой пароль можно использовать только один раз. Проверку правильности введённого значения на стороне сервера проверяет специальный сервер аутентификации, вычисляющий текущее значение одноразового пароля программно. Для сохранения принципа двухфакторности аутентификации помимо сгенерированного устройством значения пользователь вводит постоянный пароль.

ru.wikipedia.org

Как ты реализуешь аутентификацию, приятель? / Mail.ru Group corporate blog / Habr

Все знают о стандартной аутентификации пользователя в приложении. Это олдскульная процедура регистрации — пользователь вводит адрес почты, пароль и т. д., — а затем при входе мы сравниваем почту и/или пароль с сохранёнными данными. Если совпадает, даём доступ. Но времена изменились, и сегодня появилось много других методов аутентификации. Если хотите оставаться востребованным программистом/разработчиком в этом меняющемся, словно калейдоскоп, мире разработки ПО, то вы должны знать обо всех этих новых методах.

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

Здесь я постараюсь рассказать о большинстве распространённых сегодня методов аутентификации. Это не подробное техническое руководство, а лишь способ познакомить вас с ними. Хотя методы описаны с учётом применения в вебе, эти идеи можно реализовать и в других условиях.

Будем считать, вы уже знаете о том, что большая часть веба/интернета построена на протоколе HTTP. Также вам нужно знать, как работают веб-приложения, что означает аутентификация пользователя в приложении и что такое клиент-серверная архитектура.

Готовы? Поехали.

Аутентификация на основе сессий

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

Чтобы избавиться от этого неудобства, придумали аутентификацию на основе сессий/кук, с помощью которых реализовали отслеживание состояний (stateful). Это означает, что аутентификационная запись или сессия должны храниться и на сервере, и на клиенте. Сервер должен отслеживать активные сессии в базе данных или памяти, а на фронтенде создаётся кука, в которой хранится идентификатор сессии. Это аутентификация на основе куки, самая распространённый и широко известный метод, используемый уже давно.

Процедура аутентификации на основе сессий:

1. Пользователь вводит в браузере своё имя и пароль, после чего клиентское приложение отправляет на сервер запрос.
2. Сервер проверяет пользователя, аутентифицирует его, шлёт приложению уникальный пользовательский токен (сохранив его в памяти или базе данных).
3. Клиентское приложение сохраняет токены в куках и отправляет их при каждом последующем запросе.
4. Сервер получает каждый запрос, требующий аутентификации, с помощью токена аутентифицирует пользователя и возвращает запрошенные данные клиентскому приложению.
5. Когда пользователь выходит, клиентское приложение удаляет его токен, поэтому все последующие запросы от этого клиента становятся неаутентифицированными.

У этого метода несколько недостатков.

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

Аутентификация на основе токенов

Аутентификация на основе токенов в последние годы стала очень популярна из-за распространения одностраничных приложений, веб-API и интернета вещей. Чаще всего в качестве токенов используются Json Web Tokens (JWT). Хотя реализации бывают разные, но токены JWT превратились в стандарт де-факто.

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

Процедура аутентификации на основе токенов:

1. Пользователь вводит имя и пароль.
2. Сервер проверяет их и возвращает токен (JWT), который может содержать метаданные вроде user_id, разрешений и т. д.
3. Токен хранится на клиентской стороне, чаще всего в локальном хранилище, но может лежать и в хранилище сессий или кук.
4. Последующие запросы к серверу обычно содержат этот токен в качестве дополнительного заголовка авторизации в виде Bearer {JWT}. Ещё токен может пересылаться в теле POST-запроса и даже как параметр запроса.
5. Сервер расшифровывает JWT, если токен верный, сервер обрабатывает запрос.
6. Когда пользователь выходит из системы, токен на клиентской стороне уничтожается, с сервером взаимодействовать не нужно.

Более подробное описание.

У метода есть ряд преимуществ:

• Главное преимущество: поскольку метод никак не оперирует состояниями, серверу не нужно хранить записи с пользовательскими токенами или сессиями. Каждый токен самодостаточен, содержит все необходимые для проверки данные, а также передаёт затребованную пользовательскую информацию. Поэтому токены не усложняют масштабирование.
• В куках вы просто храните ID пользовательских сессий, а JWT позволяет хранить метаданные любого типа, если это корректный JSON.
• При использовании кук бэкенд должен выполнять поиск по традиционной SQL-базе или NoSQL-альтернативе, и обмен данными наверняка длится дольше, чем расшифровка токена. Кроме того, раз вы можете хранить внутри JWT дополнительные данные вроде пользовательских разрешений, то можете сэкономить и дополнительные обращения поисковые запросы на получение и обработку данных.
  Допустим, у вас есть API-ресурс /api/orders, который возвращает последние созданные приложением заказы, но просматривать их могут только пользователи категории админов. Если вы используете куки, то, сделав запрос, вы генерируете одно обращение к базе данных для проверки сессии, ещё одно обращение — для получения пользовательских данных и проверки, относится ли пользователь к админам, и третье обращение — для получения данных.
  А если вы применяете JWT, то можете хранить пользовательскую категорию уже в токене. Когда сервер запросит его и расшифрует, вы можете сделать одно обращение к базе данных, чтобы получить нужные заказы.
• У использования кук на мобильных платформах есть много ограничений и особенностей. А токены сильно проще реализовать на iOS и Android. К тому же токены проще реализовать для приложений и сервисов интернета вещей, в которых не предусмотрено хранение кук.

Благодаря всему этому аутентификация на основе токенов сегодня набирает популярность.

Беспарольная аутентификация

Первой реакцией на термин «беспарольная аутентификация» может быть «Как аутентифицировать кого-то без пароля? Разве такое возможно?»

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

Беспарольная аутентификация — это способ конфигурирования процедуры входа и аутентификации пользователей без ввода паролей. Идея такая:

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

Есть похожий метод, при котором вместо одноразовой ссылки по SMS отправляется код или одноразовый пароль. Но тогда придётся объединить ваше приложение с SMS-сервисом вроде twilio (и сервис не бесплатен). Код или одноразовый пароль тоже можно отправлять по почте.

И ещё один, менее (пока) популярный (и доступный только на устройствах Apple) метод беспарольной аутентификации: использовать Touch ID для аутентификации по отпечаткам пальцев. Подробнее о технологии.

Если вы пользуетесь Slack, то уже могли столкнуться с беспарольной аутентификацией.

Medium предоставляет доступ к своему сайту только по почте. Я недавно обнаружил, что Auth0, или Facebook AccountKit, — это отличный вариант для реализации беспарольной системы для вашего приложения.

Что может пойти не так?

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

В чём преимущества?

Как часто вы пользуетесь ссылкой «забыли пароль» для сброса чёртового пароля, который так и не смогли вспомнить после нескольких неудачных попыток входа на сайт / в приложение? Все мы бываем в такой ситуации. Все пароли не упомнишь, особенно если вы заботитесь о безопасности и для каждого сайта делаете отдельный пароль (соблюдая все эти «должен состоять не менее чем из восьми символов, содержать хотя бы одну цифру, строчную букву и специальный символ»). От всего этого вас избавит беспарольная аутентификация. Знаю, вы думаете сейчас: «Я использую менеджер паролей, идиот». Уважаю. Но не забывайте, что подавляющее большинство пользователей не такие техногики, как вы. Это нужно учитывать.

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

Если вы думаете, что какие-то пользователи предпочтут старомодные логин/пароль, то предоставьте им оба варианта, чтобы они могли выбирать.

Сегодня беспарольная аутентификация быстро набирает популярность.

Единая точка входа (Single Sign On, SSO)

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

Этот метод называется единой точкой входа (Single Sign On, SSO).

Реализовать его можно по-разному. Например, использовать центральный сервис для оркестрации единого входа между несколькими клиентами. В случае с Google этот сервис называется Google Accounts. Когда пользователь логинится, Google Accounts создаёт куку, которая сохраняется за пользователем, когда тот ходит по принадлежащим компании сервисам. Как это работает:

1. Пользователь входит в один из сервисов Google.
2. Пользователь получает сгенерированную в Google Accounts куку.
3. Пользователь идёт в другой продукт Google.
4. Пользователь снова перенаправляется в Google Accounts.
5. Google Accounts видит, что пользователю уже присвоена кука, и перенаправляет пользователя в запрошенный продукт.

Очень простое описание единой точки входа: пользователь входит один раз и получает доступ ко всем системам без необходимости входить в каждую из них. В этой процедуре используется три сущности, доверяющие другу прямо и косвенно. Пользователь вводит пароль (или аутентифицируется иначе) у поставщика идентификационной информации (identity provider, IDP), чтобы получить доступ к поставщику услуги (service provider (SP). Пользователь доверяет IDP, и SP доверяет IDP, так что SP может доверять пользователю.

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

Аутентификация в соцсетях

Уверен, эта картинка знакома всем:

Это часто называют аутентификацией в соцсетях (Social sign-in) или социальным логином (Social Login). Вы можете аутентифицировать пользователей по их аккаунтам в соцсетях. Тогда пользователям не придётся регистрироваться отдельно в вашем приложении.

Формально социальный логин — это не отдельный метод аутентификации. Это разновидность единой точки входа с упрощением процесса регистрации/входа пользователя в ваше приложение.

Лучшее из двух миров

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

Как использовать

Как разработчик вы должны разбираться в работе этого метода аутентификации. Большинство соцсетей в качестве механизма аутентификации используют авторизацию через OAuth3 (некоторые используют OAuth2, например Twitter). Разберёмся, что такое OAuth. Соцсеть — это сервер ресурсов, ваше приложение — клиент, а пытающийся войти в ваше приложение пользователь — владелец ресурса. Ресурсом называется пользовательский профиль / информация для аутентификации. Когда пользователь хочет войти в ваше приложение, оно перенаправляет пользователя в соцсеть для аутентификации (обычно это всплывающее окно с URL’ом соцсети). После успешной аутентификации пользователь должен дать вашему приложению разрешение на доступ к своему профилю из соцсети. Затем соцсеть возвращает пользователя обратно в ваше приложение, но уже с токеном доступа. В следующий раз приложение возьмёт этот токен и запросит у соцсети информацию из пользовательского профиля. Так работает OAuth (ради простоты я опустил технические подробности).

Для реализации такого механизма вам может понадобиться зарегистрировать своё приложение в разных соцсетях. Вам дадут app_id и другие ключи для конфигурирования подключения к соцсетям. Также есть несколько популярных библиотек/пакетов (вроде Passport, Laravel Socialite и т. д.), которые помогут упростить процедуру и избавят от излишней возни.

Двухфакторная аутентификация (2FA)

Двухфакторная аутентификация (2FA) улучшает безопасность доступа за счёт использования двух методов (также называемых факторами) проверки личности пользователя. Это разновидность многофакторной аутентификации. Наверное, вам не приходило в голову, но в банкоматах вы проходите двухфакторную аутентификацию: на вашей банковской карте должна быть записана правильная информация, и в дополнение к этому вы вводите PIN. Если кто-то украдёт вашу карту, то без кода он не сможет ею воспользоваться. (Не факт! — Примеч. пер.) То есть в системе двухфакторной аутентификации пользователь получает доступ только после того, как предоставит несколько отдельных частей информации.

Другой знакомый пример — двухфакторная аутентификация Mail.Ru, Google, Facebook и т. д. Если включён этот метод входа, то сначала вам нужно ввести логин и пароль, а затем одноразовый пароль (код проверки), отправляемый по SMS. Если ваш обычный пароль был скомпрометирован, аккаунт останется защищённым, потому что на втором шаге входа злоумышленник не сможет ввести нужный код проверки.

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

При двухфакторной аутентификации пользователь должен предоставить два из трёх:

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

Большинство хакеров охотятся за паролями и PIN-кодами. Гораздо труднее получить доступ к генератору токенов или биологическим свойствам, поэтому сегодня двухфакторка обеспечивает высокую безопасность аккаунтов.

То есть это универсальное решение? Возможно, нет.

И всё же двухфакторка поможет усилить безопасность аутентификации в вашем приложении. Как реализовать? Возможно, стоит не велосипедить, а воспользоваться существующими решениями вроде Auth0 или Duo.

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

Некоторые путают термины «аутентификация» и «авторизация». Это разные вещи.

• Аутентификация — это проверка вашей личности. Когда вы входите в приложение с именем и паролем, вы аутентифицируетесь.
• Авторизация — это проверка наличия у вас доступа к чему-либо. Это может быть набор разрешений на какие-то действия. Например, если вы создали в приложении ресурс, то вы можете быть единственным, кому разрешено удалять этот ресурс (потому что вы владелец), а другие пользователи для того не «авторизованы».

Ещё тут?

Поздравляю, вы успешно дочитали длинную, нудную и скучную статью.

habr.com

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

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

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

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

История

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Субъект запрашивает доступ в систему и вводит личный идентификатор и пароль
2. Введенные уникальные данные поступают на сервер аутентификации, где сравниваются с эталонными
3. При совпадении данных с эталонными, аутентификация признается успешной, при различии — субъект перемещается к 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). Работа протокола типа «запрос-ответ» может состоять минимум из четырех стадий:

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

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

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

1. Субъект отправляет системе запрос, содержащий его персональный идентификатор и случайное число N1
2. Система зашифровывает полученное число N1 на основе уникального ключа, генерирует случайное число N2, и отправляет их оба субъекту
3. Cубъект расшифровывает полученное число на основе своего уникального ключа и сравнивает результат с N1. Идентичность означает, что система обладает тем же уникальным ключом, что и субъект
4. Субъект зашифровывает полученное число N2 на основе своего уникального ключа и результат отправляет системе
5. Система расшифровывает полученное сообщение на основе того же уникального ключа. При совпадении результата с исходным числом 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

dic.academic.ru

Идентификация, аутентификация, авторизация — в чем разница?

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

Сегодня мы узнаем, что такое идентификация, аутентификация, авторизация и в чем разница между этими понятиями

Что такое идентификация?

Сначала давайте прочитаем определение:

Идентификация — это процедура распознавания субъекта по его идентификатору (проще говоря, это определение имени, логина или номера).

Идентификация выполняется при попытке войти в какую-либо систему (например, в операционную систему или в сервис электронной почты).

Сложно? Давайте перейдём к примерам, заодно разберемся, что такое идентификатор.

Пример идентификатора в социальной сети ВКонтакте

Когда нам звонят с неизвестного номера, что мы делаем? Правильно, спрашиваем “Кто это”, т.е. узнаём имя. Имя в данном случае и есть идентификатор, а ответ вашего собеседника — это будет идентификация.

Идентификатором может быть:

• номер телефона
• номер паспорта
• e-mail
• номер страницы в социальной сети и т.д.

Подробнее об идентификаторах и ID рекомендую прочитать здесь.

Что такое аутентификация?

После идентификации производится аутентификация:

Аутентификация – это процедура проверки подлинности (пользователя проверяют с помощью пароля, письмо проверяют по электронной подписи и т.д.)

Чтобы определить чью-то подлинность, можно воспользоваться тремя факторами:

1. Пароль – то, что мы знаем (слово, PIN-код, код для замка, графический ключ)
2. Устройство – то, что мы имеем (пластиковая карта, ключ от замка, USB-ключ)
3. Биометрика – то, что является частью нас (отпечаток пальца, портрет, сетчатка глаза)

Отпечаток пальца может быть использован в качестве пароля при аутентификации

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

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

Что такое авторизация?

Когда определили ID, проверили подлинность, уже можно предоставить и доступ, то есть, выполнить авторизацию.

Авторизация – это предоставление доступа к какому-либо ресурсу (например, к электронной почте).

Разберемся на примерах, что же это за загадочная авторизация:

• Открытие двери после проворачивания ключа в замке
• Доступ к электронной почте после ввода пароля
• Разблокировка смартфона после сканирования отпечатка пальца
• Выдача средств в банке после проверки паспорта и данных о вашем счете

Дверь открылась? Вы авторизованы!

Взаимосвязь идентификации, аутентификации и авторизации

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

1. Сначала определяют имя (логин или номер) – идентификация
2. Затем проверяют пароль (ключ или отпечаток пальца) – аутентификация
3. И в конце предоставляют доступ – авторизация

Инфографика: 1 — Идентификация; 2 — Аутентификация; 3 — Авторизация

Проблемы безопасности при авторизации

Помните, как в сказке «Красная Шапочка» бабушка разрешает внучке войти в дом? Сначала бабушка спрашивает, кто за дверью, затем говорит Красной Шапочке, как открыть дверь. Волку же оказалось достаточным узнать имя внучки и расположение дома, чтобы пробраться в дом.

Какой вывод можно сделать из этой истории?

Каждый этап авторизации должен быть тщательно продуман, а идентификатор, пароль и сам принцип авторизации нужно держать в секрете.

Заключение

Итак, сегодня вы узнали, что такое идентификация, аутентификация и авторизация.

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

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

P.S. Самые внимательные могут посчитать, сколько раз нарушены рассмотренные в данном уроке процедуры.

Автор: Сергей Бондаренко http://it-uroki.ru/

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

---

Поделитесь с друзьями:

---

Понравились IT-уроки?

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

---

Много интересного в соц.сетях:

it-uroki.ru

Двухфакторная аутентификация на сайте с использованием USB-токена. Как сделать вход на служебный портал безопасным?

Хакеры получили доступ к главному почтовому серверу международной компании Deloitte. Учетная запись администратора этого сервера была защищена только паролем.

Независимый австрийский исследователь Дэвид Винд получил вознаграждение в размере 5 тыс. долларов за обнаружение уязвимости на странице для ввода логина интранета Google.

91% российских компаний скрывают факты утечки данных.

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

И чем крупнее компания, чем больше в ней сотрудников и сложнее внутренняя IT-инфраструктура, тем более актуальной для нее является проблема утечки информации. Какая информация интересна злоумышленникам и как защитить ее?

Утечка какой информации может нанести вред компании?

• информации о клиентах и сделках;
• технической информации о продуктах и ноу-хау;
• информации о партнерах и специальных предложениях;
• персональные данные и бухгалтерия.

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

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

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

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

Для примера мы возьмем самое подходящую для корпоративного применения модель Рутокен — криптографический USB-токен Рутокен ЭЦП PKI.

Давайте приступим к настройке.

Шаг 1 — Настройка сервера

Основа любого сервера — это операционная система. В нашем случае это Windows Server 2016. А вместе с ней и другими операционными системами семейства Windows распространяется IIS (Internet Information Services).

IIS представляет собой группу интернет-серверов, в том числе веб-сервер и FTP-сервер. IIS включает приложения для создания и управления веб-сайтами.

IIS разработана для построения веб-сервисов с использованием учетных записей пользователей, предоставляемой доменом или службой Active Directory. Это позволяет использовать существующие базы данных пользователей.

В первой статье мы подробно рассказали, как доустановить и настроить на вашем сервере Центр Сертификации (Certification Authority). Сейчас мы на этом подробно останавливаться не станем, а будем считать, что все уже настроено. HTTPS-сертификат для web-сервера должен быть выписан корректно. Лучше сразу это проверить.

В Windows Server 2016 встроен IIS версии 10.0.

Если IIS установлен, то осталось его правильно сконфигурировать.

На этапе выбора служб ролей мы поставили галочку Обычная проверка подлинности.

Затем в Диспетчере служб IIS включили Обычную проверку подлинности.

И указали домен в котором расположен веб-сервер.

Потом добавили привязку сайта.

И выбрали параметры SSL.

На этом настройка сервера завершена.

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

Мы еще раз напоминаем, что согласно первой статье, пользователю заранее был выдан токен с ключами и сертификатом, выписанным по шаблону типа Пользователь со смарт-картой.

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

Шаг 2 — Настройка компьютера пользователя

Для простоты предположим, что у нашего пользователя ОС Windows 10.

Также предположим, что у него установлен комплект Драйверы Рутокен для Windows.

Установка комплекта драйверов опциональна, так как скорее всего поддержка токена прилетит по Windows Update.

Но если этого вдруг не произошло, то установка комплекта Драйверов Рутокен для Windows решит все проблемы.

Подключим токен к компьютеру пользователя и откроем Панель управления Рутокен.

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

Тем самым мы проверили, что токен рабочий и содержит нужный сертификат.

Все браузеры, кроме Firefox, настраиваются автоматически.

 

Специально с ними делать ничего не нужно.

Теперь откроем любой браузер и введем адрес ресурса.

До того, как сайт загрузится у нас откроется окно для выбора сертификата, а затем окно для ввода PIN-кода токена.

Если для устройства в качестве криптопровайдера по умолчанию выбран Aktiv ruToken CSP, то для ввода PIN-кода откроется другое окно.

И только после успешного его ввода в браузере откроется наш сайт.

Для браузера Firefox следует выполнить дополнительные настройки.

В настройках браузера выбрать Приватность и Защита. В разделе Сертификаты нажать Устройство Защиты. Откроется окно Управление устройствами.

Нажать Загрузить, указать название Рутокен ЭЦП и путь C:\windows\system32\rtpkcs11ecp.dll.

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

Кстати вход по токену на веб-сайты работает и на Маках в браузере Safari, Chrome и Firefox.

Нужно лишь установить с сайта Рутокен модуль поддержки Связки Ключей и увидеть в нем сертификат на токене.

Настраивать браузеры Safari, Chrome, Яндекс и прочие не нужно, достаточно лишь открыть сайт в любом из этих браузеров.

Браузер Firefox настраивается почти также, как и в Windows (Настройки — Дополнительные — Сертификаты — Устройства защиты). Только путь к библиотеке немного другой /Library/Akitv Co/Rutoken ECP/lib/librtpkcs11ecp.dylib.

Выводы

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

Такую процедуру вы можете проделать с любым своим внутренним ресурсом, также вы гибко сможете настраивать группы пользователей, которые будут иметь доступ к сайту, впрочем как и везде в Windows Server-е.

Используете другую ОС для сервера?

Если вы хотите, чтобы мы написали про настройку других ОС, то напишите об этом в комментариях к статье.

habr.com