что такое mfa код

Многофакторная идентификация в ASP.NET Core

Многофакторная идентификация (MFA) — это процесс, в ходе которого пользователь запрашивается во время события входа, чтобы получить дополнительные формы идентификации. Этот запрос может быть использован для ввода кода из целлфоне, использования ключа FIDO2 или для обеспечения сканирования отпечатков пальцев. Если требуется Вторая форма проверки подлинности, Безопасность улучшена. Злоумышленник не может легко получить или продублировать дополнительный фактор.

В этой статье рассматриваются следующие вопросы:

MFA, 2FA

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

Двухфакторная проверка подлинности (2FA) похожа на подмножество MFA, но в этом случае в MFA может потребоваться два или более фактора для подтверждения личности.

MFA TOTP (алгоритм одноразового пароля на основе времени)

Сведения о реализации см. по следующей ссылке:

FIDO2 MFA или безпарольный

FIDO2 в настоящее время:

в настоящее время ASP.NET Core не поддерживает FIDO2 напрямую. FIDO2 можно использовать для MFA или беспарольных потоков.

Azure Active Directory обеспечивает поддержку для FIDO2 и безпарольных потоков. Дополнительные сведения см. в разделе Параметры проверки подлинности, не имеющие пароля, для Azure Active Directory.

SMS ДЛЯ MFA

MFA с SMS значительно повышает безопасность с помощью проверки пароля (один фактор). Однако использовать SMS в качестве второго фактора больше не рекомендуется. Для этого типа реализации существует слишком много известных векторов атак.

Настройка MFA для страниц администрирования с помощью ASP.NET Core Identity

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

Расширение имени входа с помощью утверждения MFA

демонстрационный код — это программа установки, использующая ASP.NET Core со Identity Razor страницами и. AddIdentity Метод используется вместо AddDefaultIdentity одного, поэтому IUserClaimsPrincipalFactory реализация может использоваться для добавления утверждений в удостоверение после успешного входа.

AdditionalUserClaimsPrincipalFactory Класс добавляет amr утверждение в утверждения пользователя только после успешного входа. Значение утверждения считывается из базы данных. Утверждение добавляется здесь, так как пользователь должен получить доступ к более защищенному представлению, если удостоверение было зарегистрировано с помощью MFA. Если представление базы данных считывается непосредственно из базы данных, а не с помощью утверждения, можно получить доступ к представлению без MFA непосредственно после активации MFA.

Также назначайте макет для всех страниц управления со Identity страниц:

Проверка требования MFA на странице «Администрирование»

Логика пользовательского интерфейса для переключения сведений для входа пользователя

Затем эту политику можно использовать в представлении, _Layout чтобы показать или скрыть меню администрирования с предупреждением:

Если удостоверение было зарегистрировано с помощью MFA, меню Admin отображается без предупреждения о подсказке. Когда пользователь вошел в систему без MFA, меню Администратор (не включено) отображается вместе с подсказкой, которая информирует пользователя (объяснение предупреждения).

Если пользователь входит в систему без MFA, отображается предупреждение:

Пользователь перенаправляется в представление включения MFA при щелчке ссылки администратора :

отправка требования к входу MFA в openid connect Подключение server

acr_values Параметр можно использовать для передачи mfa требуемого значения с клиента на сервер в запросе проверки подлинности.

чтобы acr_values это работало, параметр должен быть обработан на сервере openid connect Подключение.

openid connect Подключение ASP.NET Core клиента

Razorклиентское приложение ASP.NET Core pages openid connect Подключение использует AddOpenIdConnect метод для входа на сервер Подключение openid connect. acr_values Параметр задается со mfa значением и отправляется с запросом проверки подлинности. OpenIdConnectEvents Используется для добавления этого.

Рекомендуемые acr_values значения параметров см. в разделе Ссылочные значения метода проверки подлинности.

пример openid connect Подключение Identity server 4 server сASP.NET Core Identity

в Login методе IIdentityServerInteractionService реализация интерфейса _interaction используется для доступа к параметрам запроса openid connect Подключение. acr_values Доступ к параметру осуществляется с помощью AcrValues Свойства. После отправки клиентом mfa значения SET его можно проверить.

Если требуется MFA и для пользователя в ASP.NET Core Identity включено MFA, то вход будет продолжен. Если для пользователя не включено MFA, пользователь перенаправляется к пользовательскому представлению ErrorEnable2FA. cshtml. Затем ASP.NET Core Identity подписывает пользователя в.

ExternalLoginCallback Метод работает как локальное Identity имя входа. AcrValues Свойство проверяется на наличие mfa значения. Если указано mfa значение, MFA выполняется перед завершением имени входа (например, перенаправлено в ErrorEnable2FA представление).

Если пользователь уже вошел в систему, клиентское приложение:

принудительное ASP.NET Core openid connect Подключение клиента для запроса MFA

в этом примере показано, как Razor приложение ASP.NET Core страниц, использующее openid connect Подключение для входа, может потребовать, чтобы пользователи прошли проверку подлинности с помощью MFA.

Для проверки требования MFA IAuthorizationRequirement создается требование. Это будет добавлено на страницы с помощью политики, требующей MFA.

возвращаемое значение зависит от того, как удостоверение прошло проверку подлинности и в реализации сервера openid connect Подключение.

В Startup.ConfigureServices методе AddOpenIdConnect метод используется в качестве схемы запроса по умолчанию. Обработчик авторизации, который используется для проверки amr утверждения, добавляется в инверсию контейнера управления. Затем создается политика, которая добавляет RequireMfa требование.

Затем эта политика используется на Razor странице при необходимости. Кроме того, политику можно добавить глобально для всего приложения.

При входе без MFA (например, при использовании только пароля):

amr Имеет pwd значение:

Отказано в доступе:

Также можно войти в систему с использованием OTP с помощью Identity :

Источник

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

Пора взять систему MFA на вооружение

Прочитав на сайте Wired.com опубликованную еще в 2012 году статью Kill the Password: A String of Characters Won’t Protect You (http://www.wired.com/2012/11/ff-mat-honan-password-hacker/), я пересмотрел свое отношение к паролям. Никому сегодня не нужно объяснять, сколь важно ограждать информацию от посягательств злоумышленников, и я уже давно защищаю свои данные с помощью сложных паролей, которые к тому же часто меняю. Но, когда я прочел эту статью, мне стало буквально не по себе: с какой же легкостью злоумышленники взламывают защищенные паролями учетные записи!

Теперь везде, где только возможно, я защищаю свои данные с помощью средств многофакторной аутентификации Multi-Factor Authentication (MFA). И не могу понять, почему пользователи платформы Office 365 до сих пор удовлетворяются средствами парольной защиты. Должен признаться: у меня нет точных сведений относительно того, какой процент пользователей Office 365 применяет средства MFA. Но неофициальное исследование, проведенное мною среди знакомых, показывает, что использование средств MFA не является нормой. Возможно, все дело в опасениях, что необходимость выполнения дополнительных аутентификационных процедур будет раздражать пользователей и сбивать их с толку. Мой опыт показывает, что на практике дела обстоят иначе, однако я вполне понимаю тех, кто придерживается такой точки зрения. Но как бы то ни было, теперь, когда средства аутентификации на базе OAuth (иногда именуемые средствами современной аутентификации) реализованы как в последней версии Office 2013, так и в Office 2016, надо полагать, что для администраторов наступило самое время рассмотреть вопрос о том, смогут ли средства MFA обеспечить защиту пользовательских данных.

Знакомство со средствами MFA платформы Office 365

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

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

Вспомогательные методы аутентификации, реализованные в пакете Azure Active Directory, многообразны и включают в себя телефонный звонок, текстовое сообщение, оповещение средствами мобильного приложения, код верификации и маркеры OATH от независимых поставщиков (это не опечатка — между стандартом OAuth и маркерами OATH существует определенное различие). Более подробные сведения о средствах MFA, реализованных в пакете Azure Active Directory, можно найти на сайте разработчика.

Azure Active Directory — это служба подтверждения полномочий Office 365. Чтобы подтвердить свои права доступа к службам с помощью пакета OAuth 2.0, приложения, разработанные для взаимодействия с MFA, используют библиотеку Active Directory Authentication Library (ADAL). OAuth — это открытый стандарт предоставления прав доступа, поддерживаемый многими другими поставщиками. Используя библиотеку ADAL, клиентские приложения, такие как Outlook или Outlook Web App, получают доступ к данным пользователей с помощью маркеров доступа, выдаваемых в процессе аутентификации. Применение маркеров доступа обеспечивает приложениям возможность продолжать обращаться к данным, не расходуя ресурсы на хранение или предоставление учетной информации пользователей.

Применяется два типа маркеров. Маркер refresh token выдается после успешного подтверждения аутентичности пользователя. Это главный маркер, служащий для получения маркеров, которые необходимы для обращения к данным пользователя. Так, при первом подключении клиента Outlook к системе Office 365 и подтверждении прав доступа к ней маркер refresh token предоставляется службой Azure Active Directory. После этого Outlook может использовать данный маркер для получения маркеров доступа, действительных для системы Exchange. Тот же refresh token действителен на всем пространстве Office 365, так что, если у программ Word или Excel возникает необходимость обращения к данным SharePoint или OneDrive for Business, клиентские приложения могут запросить маркер доступа, действительный для упомянутых серверных приложений. На данную ситуацию можно взглянуть и под другим углом: маркер доступа всегда задается ресурсом — будь то Exchange, SharePoint или какая-либо другая программа.

Если маркер refresh token не используется, срок его действия составляет две недели. Однако, если этот маркер применяется для генерирования маркеров доступа, он обновляется средствами Azure Active Directory. Разумеется, если вы выйдете из системы на срок свыше двух недель и не будете обращаться к Office 365 на протяжении этого времени, срок действия refresh token истечет, и вам придется вновь создавать его в процессе аутентификации.

Активация MFA для учетных записей Office 365

Активация MFA для учетных записей Office 365 осуществляется без каких-либо затруднений. Зарегистрируйтесь в центре администрирования Office 365 Admin Center, перейдите на вкладку Users и щелкните ссылку Setup рядом со строкой Set multi-factor authentication requirements. Теперь вы сможете активировать средства MFA для целой группы учетных записей или для отдельных учетных записей по своему выбору. Запустите процесс, щелкнув на пункте Enable, а затем укажите учетные записи, для которых должны быть активированы средства MFA.

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

Экран 1. Выбор методов верификации для средств MFA

Разработчики Azure Active Directory объединили указываемый пользователем номер мобильного телефона с соответствующей учетной записью. Когда для той или иной записи требуется дополнительная проверка подлинности, служба Azure Active Directory направляет по заданному номеру код верификации, и пользователь может ввести данный код в ответ на запрос. Этот метод с успехом применяется в браузерных приложениях и в современных мобильных приложениях, которые используют библиотеку ADAL, например в приложении Office 365 Groups. Кроме того, телефоны могут использоваться в процессе аутентификации посредством реакции на звонок. В этом случае пользователь принимает телефонный вызов и завершает процесс подтверждения подлинности нажатием на экране набора номера значка «решетка» (#).

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

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

Иногда телефонные звонки и текстовые сообщения не могут быть применены в качестве механизмов проверки подлинности пользователей. Так, работающие с соединениями WiFi пассажиры авиалайнеров не имеют возможности завершить процесс аутентификации с помощью телефонного звонка или текстового сообщения. Но при наличии WiFi-соединения вы можете получать извещающие уведомления (push notifications) с помощью приложения Azure Authenticator (существуют версии для iOS, Android и Windows Phone). Это приложение, кстати, можно применять и в автономном режиме для генерации кодов, которые могут использоваться в процессе аутентификации. Понятно, что пользователям, не располагающим ни приложением Authenticator, ни доступом к сетевому соединению, придется довольствоваться теми вариантами автономного доступа, которые обеспечивают их клиенты.

Прежде чем воспользоваться средством аутентификации, вам придется из своей учетной записи Office 365 активировать его в качестве механизма верификации. Делается это так. Перейдите в раздел Office 365 Settings, выберите вкладку Additional security verification и щелкните на пункте Update your phone numbers used for account security. После этого вы сможете добавить приложение Azure Authenticator к списку программ, поддерживаемых вашей учетной записью, и завершить процесс настройки (см. экран 2).

Экран 2. Настройка приложения authenticator

Пароли приложений

Перечисленные выше методы верификации реализованы не во всех приложениях, и именно по этой причине существует такой механизм, как «пароль приложения». Пароль приложения, создаваемый на финальной стадии активации средств MFA (см. экран 3), представляет собой сложную текстовую строку, которую можно ввести для завершения процесса аутентификации. Пароли приложений были созданы для того, чтобы обеспечить приложениям, не оснащенным средствами аутентификации на основе стандарта OAuth, возможность создания действительных маркеров доступа, открывающих путь к данным Office 365.

Экран 3. Просмотр пароля приложения

Получив пароль приложения, пользователь должен обеспечить его неприкосновенность, поскольку этот пароль потребуется для проверки прав доступа средствами некоторых приложений, включая мобильные телефоны, оснащенные технологией ActiveSync. Освоить эту часть процесса труднее всего, поскольку, хотя у вас может быть несколько паролей приложений (скажем, по одному на каждое приложение или по одному на устройство), все эти пароли генерируются автоматически и, похоже, выдаются нам с гарантией: их ни за что не вспомнишь в тот момент, когда это потребуется. Средства MFA никак не проявляют себя сразу после активации: на данный момент у пользователей могут быть задействованы существующие соединения, срок действия которых должен истечь или которые должны быть разорваны перед тем, как новый режим аутентификации вступит в силу. Обычно первыми требуют использования средств MFA браузерные соединения (включая соединения с SharePoint и с OneDrive при открытии файлов, хранящихся в этих репозиториях). За ними следуют другие приложения, такие как Outlook 2016. После завершения проверки подлинности ее результаты остаются действительными в течение 14 дней.

Использование средств MFA

На то, чтобы привыкнуть к работе со средствами MFA, уходит некоторое время, но скоро эти навыки становятся вашей «второй натурой». Система не предлагает вам вводить свои учетные данные чаще, чем раньше, однако, когда это происходит, процесс проверки подлинности складывается из двух этапов. В большинстве случаев получение текстового сообщения с верификационным кодом (см. экран 4) никаких сложностей не вызывает. Единственная проблема, с которой мне приходилось сталкиваться при работе за пределами моей страны проживания, состояла в том, что иногда имела место некоторая задержка с передачей сигнала. Это телекоммуникационные компании прикидывали, как донести сообщение SMS с кодом верификации до моего мобильника. Что ж, таковы особенности роуминга. Пожалуй, в подобных случаях удобнее пользоваться приложением Azure Authenticator.

Экран 4. Введение одноразового кода, полученного через SMS

MFA и пакет PowerShell

Самая серьезная проблема, с которой мне довелось столкнуться, заключалась в отсутствии средств работы с многофакторной аутентификацией в среде PowerShell. Когда пользователь начинает сеанс удаленной работы с PowerShell с помощью подключения через Office 365, он может идентифицировать себя, только предоставив свое имя пользователя и пароль, так как механизм для передачи второго фактора аутентификации, включая пароли приложений, в этом случае не предусмотрен. Единственное решение — создать отдельную учетную запись для работы с PowerShell. Само по себе это несложно, к тому же отделение административных действий (которые вы будете выполнять с использованием PowerShell) от рутинных процедур взаимодействия с Office 365 отвечает требованиям безопасности. Кстати, специалисты Microsoft сейчас работают над оснащением PowerShell средствами MFA, так что в будущем вы сможете использовать различные методы верификации. Учтите, что, возможно, на первых порах модули PowerShell для различных приложений, включая Exchange, не будут поддерживать работу средств MFA. Но даже если такая поддержка и будет реализована, я все равно рекомендовал бы рассмотреть возможность использования отдельной учетной записи для работы с PowerShell.

Среда PowerShell может использоваться для просмотра учетных записей, настроенных для применения средств MFA. Как разъясняется в статье, подготовленной обладателем статуса Microsoft MVP Мишелем де Руиж, публикуемый в приведенном листинге код вы можете использовать для определения учетных записей Office 365, применяющих средства многофакторной аутентификации, а также для выявления методов, используемых для дополнительной проверки подлинности. Приведенные ниже данные показывают, что обе учетные записи настроены для использования аутентификации с помощью SMS (OneWaySMS), а также звонков по мобильному телефону (TwoWayVoiceMobile). Помимо прочего, вы можете использовать PowerShell для управления настройками MFA для учетных записей, хотя большинство пользователей устроит обращение в центр администрирования Office 365 Admin Center.

Казус с привередливым браузером

Более занятная проблема возникла в связи с тем, что Internet Explorer внезапно стал отказывать мне в соединении с использованием средств MFA (см. экран 5). Я работал под управлением новейшей версии Windows 10 (10586, или редакция Threshold 2); при этом, в отличие от IE, как Edge, так и Chrome работали с MFA без каких-либо нареканий. Я сделал все, что полагается в таких случаях: очистил кэш браузера и навел в Интернете справки по коду ошибки 50012, но оптимального решения так и не нашел. Проблема сохранялась в течение недели или чуть больше. В конце концов я решил деактивировать средства MFA для своей учетной записи и посмотреть, как на это отреагирует IE. Браузер работал после деактивации средств MFA и продолжал исправно функционировать и после ее повторного включения. Таким образом я получил еще одно подтверждение тому, что отключение функции с ее последующей активацией часто позволяет решить проблему.

Экран 5. Ошибка в работе IE

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

Вопрос планирования

Разумеется, реализация средств MFA — это не такой шаг, на который вы решаетесь просто потому, что вам очень захотелось. Здесь я не рассматриваю тот случай, когда кто-то хочет сокрушить справочную службу, обрушив на нее лавину звонков от возмущенных пользователей, желающих обратиться к своим почтовым ящикам. В таких делах требуется предварительная подготовка, и в первую очередь — уведомление пользователей. Все они должны иметь представление о том, что именно происходит и как нужно реагировать на приглашение к проведению дополнительной верификации. Кроме того, целесообразно удостовериться в том, что приложения нормально функционируют с активированными средствами MFA, и составить список ответов на часто задаваемые вопросы (возможно, по образцу списка, подготовленного по данной теме специалистами Microsoft, https://azure.microsoft.com/en-us/documentation/articles/multi-factor-authentication-end-user-manage-settings/). Ознакомившись с этим списком, пользователи будут знать, чего им следует ожидать в процессе выполнения процедуры аутентификации.

Хотя специалисты Microsoft реализовали средства MFA во всей платформе Office 365, рассматриваемая функция не ограничена «облачной» службой. Механизм многофакторной аутентификации Azure Active Directory можно настроить и для обслуживания почтовых ящиков, размещенных на локальном оборудовании. Обладатель статуса Microsoft MVP Брайан Рийд раскрывает эту тему в своем журнале по адресу http://www.c7solutions.com/2015/01/exchange-owa-and-multi-factor-authentication. Кроме того, дополнительную информацию по реализации MFA в локальных приложениях, а также по планированию развертывания гибридных систем можно получить в Microsoft (https://azure.microsoft.com/en-us/documentation/articles/multi-factor-authentication-get-started-server/и https://support.office.com/en-us/article/Plan-for-multi-factor-authentication-for-Office-365-Deployments-043807b2-21db-4d5c-b430-c8a6dee0e6ba).

Ну и, разумеется, если вы не работаете с Office 365, но хотите защитить системы Exchange с помощью средств MFA, к вашим услугам множество решений, предлагаемых независимыми поставщиками; в этом вы сможете убедиться сами, выполнив простую процедуру поиска в Интернете.

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

С течением времени функции многофакторной аутентификации реализуются во все большем числе приложений, и в конечном итоге их применение станет нормой. Для иллюстрации этой мысли отмечу, что недавно специалисты Microsoft оснастили функциями MFA средства защиты управления правами Windows Rights Management (http://blogs.technet.com/b/rms/archive/2015/10/14/fall-update-document-tracking-ga-multi-factor-authentication-outlook-android-support-and-public-preview-for-rms-sharing-app-for-non-admin-users.aspx) для целого ряда клиентов, включая приложения Office 2016. Это полезное решение, подчеркивающее уязвимость информации в представлении получателей, которые могут получить доступ к тому или иному защищенному файлу, только идентифицировав себя с помощью механизма MFA.

В целом корпорация Microsoft осуществила простую в обращении реализацию механизма MFA внутри Office 365 и выпускает приложения, использующие этот механизм. Предлагаемое решение характеризуется определенным уровнем гибкости: клиенты не обязаны применять средства MFA, а если эти средства активированы, число их пользователей может быть ограничено заданными учетными записями. Так что, если вы сегодня не пользуетесь средствами MFA, может быть, стоит испытать их на небольшом числе учетных записей. В конце концов, что вы потеряете, повысив свой уровень защищенности?

Источник