Аутентификация

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

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

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

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

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

Аутентификация на основе JWT (Json Web Tokens)

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. К тому же токены проще реализовать для приложений и сервисов интернета вещей, в которых не предусмотрено хранение кук.

Защиты

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

• Атака « человек посередине»: атаки « человек посередине» (MITM) — это когда третья сторона желает подслушать или перехватить сообщение, а иногда и изменить предназначенное для получателя сообщение. Обе стороны открыто получают сообщения, не проверяя отправителя, поэтому они не понимают, что злоумышленник вставил себя в линию связи. Взаимная проверка подлинности может предотвратить атаки MITM, потому что и отправитель, и получатель проверяют друг друга перед отправкой им своих ключей сообщений, поэтому, если одна из сторон не проверена на предмет того, кем они являются, сеанс завершится.
• Атаки с воспроизведением: атака с воспроизведением похожа на атаку MITM, при которой более старые сообщения воспроизводятся вне контекста, чтобы обмануть сервер. Однако это не работает против схем, использующих взаимную аутентификацию, поскольку временные метки являются фактором проверки, который используется в протоколах. Если изменение времени превышает максимально допустимую временную задержку, сеанс будет прерван. Точно так же сообщения могут включать в себя случайно сгенерированный номер, чтобы отслеживать, когда сообщение было отправлено.
• Атаки с использованием спуфинга: атаки с использованием спуфинга основаны на использовании ложных данных, чтобы выдать себя за другого пользователя, чтобы получить доступ к серверу или быть идентифицированным как кто-то другой. Взаимная аутентификация может предотвратить атаки спуфинга, поскольку сервер также аутентифицирует пользователя и проверяет, что у них есть правильный сеансовый ключ, прежде чем разрешать дальнейшее взаимодействие и доступ.
• Атаки олицетворения: когда каждая сторона аутентифицирует другую, они отправляют друг другу сертификат, который только другая сторона знает, как расшифровать, подтверждая себя как надежный источник. Таким образом, злоумышленники не могут использовать атаки олицетворения, потому что у них нет правильного сертификата, чтобы действовать так, как если бы они были другой стороной.

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

Как злоумышленники обходят даже двухступенчатую защиту

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

1. Захват контроля над учетной записью выполняется следующим образом: заходим на адрес почтового сервиса, сбрасываем пароль. Получаем код доступа на заблокированное устройство. Просим Siri(голосовой помощник) озвучить пришедший код. Для этого не нужно гаджет снимать с блокировки. Вводим код в соответствующее поле, получаем доступ к почте. Отсюда уже отправляем запрос на сброс пароля от самого аккаунта. После чего успешно меняем его на свой и свободно пользуемся “учеткой”.
2. Взлом личного кабинета на сайте сотового оператора. Мошенник заранее получает ответы на вопросы от владельца телефона. Этот способ доступен для человека, который знает, кто станет жертвой взлома (это может быть даже знакомый или родственник).Все что нужно — позвонить оператору и ответить на все секретные вопросы для сброса пароля. После этого меняется старый шифр на новый. Далее можно пользоваться учетной записью: заказывать пакеты услуг, СМС, дополнительные услуги.
3. Имея личный телефон сотрудника крупной финансовой компании или владельца лицевого счета, легко произвести взлом последнего. С целью подключить услуги или перевести деньги на личный счет, злоумышленник делает запрос на предоставление логина или пароля, дублирует номер телефона или устанавливает переадресацию вызовов и СМС с помощью специальных приложений. После этого с легкостью получает все секретные одноразовые коды. Такая операция производится обычно с целью наживы.

Образцы разделов авторизации

Ниже приведены несколько примеров разделов авторизации в документации API.

SendGrid

API ключ SendGrid

SendGrid предлагает подробное объяснение ключей API, начиная с основ, поясняя: «Что такое ключи API?». Контекстно раздел ключей API появляется вместе с другими разделами по управлению учетными записями.

авторизация Twitter

В Twitter подробный пример оправдан и предоставлен, поскольку требования к авторизации OAuth 2.0 немного сложнее.

Amazon Web Services

авторизация Amazon

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

Dropbox

Авторизация в Dropbox

Как и Twitter, Dropbox также использует OAuth 2.0. Их документация включает в себя не одну, а две диаграммы и подробное объяснение процесса.

Ошибки аутентификации при подключении к беспроводным сетям

Подключаясь к беспроводной сети, пользователь также проходит через процесс аутентификации. Существует несколько способов проверки подлинности такого типа. Они зависят от настроек роутера, количества абонентов, вида беспроводной сети (домашняя, общественная, корпоративная). Чаще всего используется тип шифрования WPA-PSKWPA2-PSK2 mixed. Он является достаточно защищенным и подходит для применения в различных видах сетей. Для большей безопасности многие частные организации используют шифрование, где каждый пользователь имеет индивидуальный пароль, привязанный к ПК.

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

Как убрать ошибки аутентификации на компьютере

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

• правильность написания ключевой фразы (возможно, была допущена ошибка или включена неверная раскладка);
• отключен ли Caps Lock;
• верно ли выбрана беспроводная сеть, к которой вы подключаетесь.

Как узнать пароль от Wi-Fi?

Если вы забыли свою парольную фразу, то узнать ее можно в настройках роутера. Для этого подключитесь к нему при помощи кабеля и откройте любой интернет-браузер. Напишите IP маршрутизатора в адресной строке. Посмотреть его можно в инструкции или на корпусе роутера. Еще один способ узнать IP-адрес — использовать командную строку. Для этого используйте комбинацию Win+R и в появившемся окне введите команду «CMD». Запустится командная строка, где вам необходимо будет ввести «ipconfig». Строка «Основной шлюз» является требуемым IP-адресом.

Введите IP-адрес в адресной строке браузера. В появившемся окне введите логин и пароль для входа (по умолчанию admin и admin соответственно). В меню выберите пункт «Расширенные настройки» и перейдите в подраздел «Wi-Fi». Найдите параметры безопасности — именно здесь можно обнаружить тип шифрования, название сети и пароль.

Пароль введен правильно, но войти в сеть не удается

Аутентификация может не состояться при сбое самого роутера. Решается простой перезагрузкой девайса. В таких ситуациях также рекомендуется проверить канал роутера. Для этого в настройках WiFi перейдите в раздел «Основные настройки», а там — в подпункт «Канал». Желательно установить значение «Автоматически».

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

Проблемы с аутентификацией на мобильном устройстве

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

1. Устройство производит поиск сетей, после чего владелец телефона или планшета выбирает необходимый Wi-Fi.
2. Пользователь вводит пароль беспроводной сети.
3. Статус соединения изменяется: подключение, аутентификация, сохранено (с указанием вида шифрования сети).

Что значит уведомление «Ошибка аутентификации»? Данное сообщение показывает, что проблема кроется в неправильно введенном пароле или параметрах безопасности роутера. Неработающий Wi-Fi после уведомления «Сохранено» свидетельствует о неполадках самой беспроводной сети.

Как исправить?

Прежде чем изменять параметры роутера, убедитесь, что пароль введен правильно, у вас не включен Caps Lock или кириллица/латынь. Только после этого обращайтесь к настройкам Wi-Fi:

• убедитесь, что режим Wi-Fi сети поддерживается — попробуйте переключить его на 802.11 b/g;
• смените регион — попробуйте переключить Россию на США и обратно;
• измените тип шифрования: если у вас стоит WPA2-Personal, то замените его на WPA с шифрованием AES;
• если ошибка аутентификации сочетается со слабым сигналом беспроводной сети, то попробуйте выбрать свободный канал и расширить его на 20 МГц.

Еще один вариант, который может вам помочь — это специальное приложение для устройств Android — Wi-Fi Fixer (доступен для скачивания в Google Play). Оно автоматически исправляет ошибки беспроводной сети и позволяет вам подключиться к роутеру при ошибке аутентификации.

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

1. Субъект — пользователь
2. Характеристика субъекта — информация, предоставляемая пользователем для проверки подлинности.
3. Владелец системы аутентификации — владелец ресурса.
4. Механизм аутентификации — принцип проверки
5. Механизм авторизации — управление доступом

Методы аутентификации

1. Парольные
2. Комбинированные
3. Биометрические
4. Информация о пользователе
5. Пользовательские данные

Парольные

Самый распространенный метод. Аутентификация может проходить по одноразовым и многоразовым паролям. Многоразовый пароль задает пользователь, а система хранит его в базе данных. Он является одинаковым для каждой сессии. К ним относятся PIN-коды, слова, цифры, графические ключи. Одноразовые пароли — разные для каждой сессии. Это может быть SMS с кодом. 

Комбинированные

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

Биометрические

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

Информация о пользователе

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

Пользовательские данные

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

Классификация видов аутентификации

В зависимости от политики безопасности систем и уровня доверия

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

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

Типы протоколов обусловлены тем, где происходит аутентификация — на PC или в сети.

Аутентификация на PC

• Login
• PAP (Password Authentication Protocol) — логин и пароль
• Карта доступа — USB и сертификаты
• Биометрические данные

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

• Cookies. Используются для отслеживания сеанса, сохранения предпочтений и сбора статистики. Степень защиты невысокая, однако привязка к IP-адресу решает эту проблему.
• Kerberos. Протокол взаимной аутентификации с помощью криптографического ключа.
• SAML (Security Assertion Markup Language) Язык разметки, который позволяет сторонам обмениваться данными аутентификации.
• SNMP (Simple Network Management Protocol) Протокол, который контролирует подключенные к сети устройства.
• Сертификаты X.509 Сертификаты с открытым ключом.
• OpenID Connect. Используется для создания единой учетной записи для аутентификации на разных ресурсах.

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

Аутентификация представляет собой процедуру подтверждения подлинности.

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

• Пароль – это введенное при регистрации слово, выданный графический ключ либо PIN-код.
• Механизм – в качестве такого устройства может быть использована карточка либо USB-ключ.
• Биометрика – это сетчатка глаза, отпечаток пальца, голос либо фото.

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

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

Аутентификация состоит из следующих операций:

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

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

Пароль проходит проверку:

В некоторых случаях вводимый вами пароль закрыт звездочками (или точками), будьте внимательны при вводе данных.

1. С применение шифров SSL или TLS.
2. В открытом виде.

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

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

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

Двухфакторная Аутентификация подразумевает высший уровень защиты и состоит из таких этапов:

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

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

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

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

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

https://youtube.com/watch?v=44TCi7O_oPk

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

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

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

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

Последствия нехватки безопасности API

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

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

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

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

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

Схемы на основе паролей

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

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

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

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

mTLS

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

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

mTLS также используется в приложениях на основе микросервисов, основанных на средах выполнения, таких как Dapr , через такие системы, как SPIFFE.

Код безопасности

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

1. Используйте многофакторный аутентификатор
2. Используйте комбинацию из двух или более однофакторных аутентификаторов.

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

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

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

Уровни надежности аутентификатора NIST

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

1. Многофакторный криптографический аппаратный аутентификатор
2. Однофакторный криптографический аппаратный аутентификатор, используемый вместе с другим аутентификатором (таким как аутентификатор пароля)

См. Руководство NIST по цифровой идентификации для дальнейшего обсуждения уровней гарантии аутентификатора.

Ограниченные аутентификаторы

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

В настоящее время использование коммутируемой телефонной сети общего пользования ограничено NIST. В частности, запрещена внеполосная передача одноразовых паролей (OTP) через записанные голосовые сообщения или SMS- сообщения. Более того, если агентство выбирает использование одноразовых паролей на основе голоса или SMS, это агентство должно проверить, что одноразовый пароль передается на телефон, а не на IP-адрес, поскольку учетные записи голосовой связи по IP (VoIP) обычно не защищены многофакторной защитой. аутентификация.

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

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

Самая простая часть — это проверка учетных данных, которую мы делаем с помощью метода FindAsync класса AppUserManager:

В дальнейшем мы будем многократно обращаться к экземпляру класса AppUserManager, поэтому мы создали отдельное свойство UserManager, который возвращает экземпляр класса AppUserManager с помощью метода расширения GetOwinContext() класса HttpContext.

Метод FindAsync принимает в качестве параметров имя и пароль, введенные пользователем, и возвращает экземпляр класса пользователя (AppUser в примере) если учетная запись с такими данными существует. Если нет учетной записи с таким именем или пароль не совпадает, метод FindAsync возвращает значение null. В этом случае мы добавляем ошибку в метаданные модели, которая будет отображена пользователю.Если метод FindAsync возвращает объект AppUser, нам нужно создать файл cookie, который будет отправляться браузером в ответ на последующие запросы, благодаря чему пользователь будет автоматически аутентифицироваться в системе:

Первым шагом является создание объекта ClaimsIdentity, который идентифицирует пользователя. Класс ClaimsIdentity является частью ASP.NET Identity и реализует интерфейс IIdentity, который был описан ранее. Экземпляры ClaimsIdentity создаются путем вызова статического метода CreateIdentityAsync() класса UserManager. Этому методу передается объект пользователя (IdentityUser) и тип аутентификации в перечислении DefaultAuthenticationTypes.

Следующий шаг — удаление всех старых аутентифицирующих файлов cookie и создание новых. Мы добавили свойство AuthManager в контроллере Account, которое возвращает объект, реализующий интерфейс IAuthenticationManager, который отвечает за выполнение аутентификации в ASP.NET Identity. В таблице ниже перечислено несколько полезных методов этого интерфейса:

Наиболее полезные методы интерфейса IAuthenticationManager

Название	Описание
SignIn(options, identity)	Вход пользователя в систему, что фактически означает создание аутентифицирующего cookie-файла
SignOut()	Выход пользователя из системы, который обычно означает удаление файлов cookie

Аргументами метода SignIn являются объект AuthenticationProperties, определяющий свойства настройки процесса аутентификации и объект ClaimsIdentity. Мы задали свойству IsPersistent объекта AuthenticationProperties значение true — это означает, что файлы cookie будут сохраняться между сессиями пользователей. Благодаря этому, если пользователь выйдет из приложения и зайдет, например, на следующий день, он будет автоматически аутентифицирован. (Есть и другие полезные свойства, определенные в классе AuthenticationProperties, но свойство IsPersistent является единственным, который широко используется на данный момент.)

После воссоздания файлов cookie мы перенаправляем пользователя по URL-адресу, который он просматривал до аутентификации (используя параметр returnUrl).

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

Пользовательский AuthenticationProvider

Используется редко: например, для проверки надо передать как username, так и password внешнему сервису. Пример ниже не показательный.

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

В параметр Authentication уже приходят имя и пароль, взятые с запроса (в каком фильтре данные берутся из запроса, описано в статье про аутентификацию). Они приходят в поля principal и credentials объекта Authentication (который в аргументе). А сформировать и вернуть необходимо новый Authentication , где реальный пользователь лежит в Principal в виде UserDetails:

@Component
public class CustomAuthencationProvider implements AuthenticationProvider {
    @Autowired
    private MyUserRepository dao;

    @Override
    public Authentication authenticate(Authentication authentication) 
                                          throws AuthenticationException {
        String userName = authentication.getName();
        String password = authentication.getCredentials().toString();
        //получаем пользователя
        MyUser myUser = dao.findByLogin(userName);
        //смотрим, найден ли пользователь в базе

        if (myUser == null) {
            throw new BadCredentialsException("Unknown user "+userName);
        }
        if (!password.equals(myUser.getPassword())) {
            throw new BadCredentialsException("Bad password");
        }
        UserDetails principal = User.builder()
                .username(myUser.getLogin())
                .password(myUser.getPassword())
                .roles(myUser.getRole())
                .build();
        return new UsernamePasswordAuthenticationToken(
                principal, password, principal.getAuthorities());

    }

    @Override
    public boolean supports(Class<?> authentication) {
        return authentication.equals(UsernamePasswordAuthenticationToken.class);
    }
}

Настройка аутентификации теперь отличается одной строчкой:

@EnableWebSecurity(debug = true)
public class SecurityConfig extends WebSecurityConfigurerAdapter {
    
    //теперь внедряем свой провайдер   
    @Autowired
    private CustomAuthencationProvider customAuthencationProvider;


    @Override
    public void configure(AuthenticationManagerBuilder auth) throws Exception {
       //и добавляем его сюда
       auth.authenticationProvider(customAuthencationProvider);
    }
    ...
}