Аутентификация vs авторизация: что это такое? в чем разница?

Содержание:

Комбинированные решения биометрической аутентификации

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

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

Комбинированные системы биометрической аутентификации значительно эжффективнее мономодальных решений. Это подтверждает множество исследований, в том числе опыт одного банка, который установил сперва систему аутентификации пользователей по лицу (частота ошибок за счет низкого качества камер 7 %), затем по голосу (частота ошибок 5% из-за фоновых шумов), а после, комбинировав эти два метода, достигли почти 100 % эффективности.

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

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

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

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

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

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

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

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

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

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

Какие могут быть Ошибки

Одной из самых распространённых ошибок аутентификации является невозможность подключения к домашнему WiFi-роутеру.

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

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

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

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

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

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

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

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

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

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

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

Запросы к страницам с ограниченным доступом успешно перехватываются и перенаправляются контроллеру 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. Браузер перенаправит вас на страницу входа, где необходимо ввести данные пользователя, которого мы создали ранее при тестировании панели администратора:

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

В начале 2014 года Федеральная служба по техническому и экспортному контролю (ФСТЭК) утвердила методический документ о мерах защиты информации в государственных информационных системах. Документ прояснил многие аспекты, касающихся организационных и технических мер защиты информации, принимаемых в государственных информационных системах, в соответствии с утверждённым приказом ФСТЭК России от 11 февраля 2013 г. No17.

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

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

  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. Используется для создания единой учетной записи для аутентификации на разных ресурсах.

Функциональные возможности и системные требования ESET Secure Authentication

В ESET Secure Authentication 2.8 можно выделить следующие основные функции:

  • Защита двухфакторной аутентификацией доступа к офисным приложениям Microsoft. Таких как: Microsoft Exchange Server 2007 (Outlook Web Access — Exchange Client Access Server) (64-разрядная версия); Microsoft Exchange Server 2010, 2013, 2016, 2019 (Outlook Web App — Exchange Client Access Server); Microsoft Dynamics CRM 2011, 2013, 2015, 2016; Microsoft SharePoint Server 2010, 2013, 2016, 2019; Microsoft SharePoint Foundation 2010, 2013.
  • Защита двухфакторной аутентификацией доступа к удаленному рабочему столу, при использовании платформы VMware Horizon View и Citrix XenApp.
  • Защита двухфакторной аутентификацией входа в операционную систему Microsoft Windows.
  • Добавление двухфакторной аутентификации в аутентификацию виртуальной частной сетей компании (VPN), при использовании таких платформ как: Barracuda, Cisco ASA, Citrix Access Gateway, Citrix NetScaler, Check Point Software, Cyberoam, F5 FirePass, Fortinet FortiGate, Juniper, Palo Alto, SonicWall. Добавление двухфакторной аутентификации в пользовательские приложения, например, «1С:Предприятие».
  • Защита входа двухфакторной аутентификацией в облачные сервисы, такие как Office 365 и Google G Suite.
  • Управление пользователями и тонкая настройка отдельных модулей ESA.
  • Поддержка любых аппаратных токенов, поддерживающих стандарт OATH.
  • Подтверждение аутентификации пользователя при помощи push‑сообщений.

ESET Secure Authentication не требовательна к системным ресурсам. Основные требования предъявляются к платформе, на которую будет интегрироваться клиентская и серверная части продукта. Поддерживаемые платформы для установки серверной и клиентской части указаны в таблице 1.

Таблица 1. Перечень поддерживаемых платформ, необходимый для инициализации клиентской и серверной части ESET Secure Authentication 2.8

Поддерживаемые платформы
Клиентская часть ESET Secure Authentication 2.50

с iOS 8 до iOS 12; с Android 4.1 до Android 9.0 (сервисы Google Play начиная с версии 10.2.6); с Windows Phone 8.1 до Windows 10 Mobile.

Серверная часть ESET Secure Authentication 2.8

Windows Server 2008, 2008 R2, 2012, 2012 R2, 2012 Essentials, 2012 R2 Essentials, 2016, 2016 Essentials 2019, 2019 Essentials; Windows Small Business Server 2008, 2011.

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

Таблица 2. Необходимые системные элементы для корректного функционирования отдельных компонентов ESET Secure Authentication 2.8

Необходимые элементы системы

Модуль ESA Web Application

Windows Server 2008 или версия новее, либо Windows 7 или более новая версия; .NET Framework версия 4.5; Internet Information Services 7 или версия новее

Модуль ESA Remote Desktop

Windows Server 2008 или версия новее, либо Windows 7 или более новая версия; (в обоих случаях поддерживаются только 64-разрядные операционные системы); Протокол Remote Desktop (RDP); Веб‑доступ к удаленному рабочему столу Microsoft; Веб‑доступ к службам терминалов Microsoft; удаленный веб‑доступ Microsoft; .NET Framework версия 4.5

Модуль ESA Windows Login

Windows 7, 8, 8.1, 10 (включая обновление Fall Creators или Redstone 3); Windows Server 2008 R2 или версия новее; .NET Framework версия 4.5

Сервер защиты ESA RADIUS Server

Windows Server 2008 или версия новее; .NET Framework версия 4.5

Служба ESA Authentication Service

Windows Server 2008 или версия новее; .NET Framework версия 4.5

Средство управления ESA Management Tools

Windows 7 или версия новее, либо Windows Server 2008 или более новая версия; средства администрирования удаленного сервера Windows; служба доменов Active Directory; Java SE 11 или OpenJDK 11; .NET Framework версия 4.7.2

Доступ к ресурсным API

Допустим, мы хотим использовать токен доступа для вызова API из одностраничного приложения. Как это выглядит?

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

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

# HTTP заголовок запроса
Authorization: 'Bearer eyj'

Затем авторизованный запрос отправляется в API, который проверяет токен с помощью промежуточного программного обеспечения middleware. Если все проверено, то API возвращает данные (например, JSON) в приложение, запущенное в браузере.

Это замечательно, но есть кое-что, что может произойти с вами прямо сейчас. Ранее мы заявляли, что OAuth решает проблемы с излишним доступом. Как это решается здесь?

Типы аутентификации

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

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

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

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

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

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

Наиболее распространена ошибка аутентификации именно при использовании подключения к Сети, но это в основном относится только к неправильному вводу паролей.

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

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

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

API2:2019 — Broken User Authentication (Недостатки аутентификации пользователей)

OAuth 2.0, OpenID Connect, WebAuthn

  1. Пользователь заходит на сайт и нажимает кнопку «Зайти с помощью Google аккаунта»
  2. Сервер посылает запрос на Google.
  3. Google показывает пользователю свою форму логина.
  4. Пользователь вводит логин/пароль.
  5. Google проверяет логин/пароль и отправляет на наш сервер приложений access token и refresh token.
  6. Для аутентификации сервер расшифровывает token или получает информацию о пользователе по Google API.
  7. После этого при каждом запросе к серверу клиент будет передавать access token в запросе, а наш сервер проверять его на валидность в Google и только после этого передавать запрошенные данные.
  8. При окончании срока действия access токена сервер использует refresh токен для получения нового.

Какие плюсы Token-Based Authentication для сервера приложений:

  1. Не надо хранить пароли в базе данных на сервере, таким образом сразу избавляемся от уязвимости Insecure Passwords.
  2. В некоторых случаях можно вообще избавиться от базы данных на сервере и получать всю необходимую информацию из Google или других систем.
  3. Нет проблем с безопасностью, характерных для остальных методов:
  • При компрометации логина/пароля доступ к данным получается сразу и длится пока пользователь сам не заметит факт взлома, у токенов же есть время жизни, которое может быть небольшим.
  • Токен автоматически не уйдет на сторонний сайт, как Cookie.
  • Cookie-Based Authentication подвержена атаке Cross-Site Request Forgeries (CSRF) и, соответственно, необходимо использовать дополнительные механизмы защиты.
  • Можно не хранить сессию пользователя на сервере, а токен проверять каждый раз в Google.

Минус видится один:

Особенности аутентификации

Аутентифика́ция (англ. authentication от греческого : αὐθεντικός authentikos, “реальный, подлинный,” от αὐθέντης authentes, “автор”)  — процедура проверки подлинности, к примеру:

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

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

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

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

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

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

Сторонние приложения

Разумеется, Google – не единственная компания, предлагающая двухфакторную аутентификацию для своих сервисов. Большинство банковских приложений, например, предлагают такие же средства защиты вашей информации, а некоторые даже требуют его. У платежного сервиса PayPal, например, тоже есть такое. Существует также множество приложений, которые работают аналогично Google Authenticator, настройка которого как раз доступна в разделе “Двухэтапная аутентификация”, про который мы говорили выше.

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

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

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

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

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

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

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

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

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

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

Единая точка входа (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 может доверять пользователю.

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

Примечания

  1. Многофакторная аутентификация — отнюдь не панацея
  2. Chinese hacking group has found new way to bypass two-factor authentication
  3. Использование многофакторной аутентификации блокирует 99,9% взломов
  4. One simple action you can take to prevent 99.9 percent of attacks on your accounts
  5. По материалам Xakep.ru, PLUSworld.ru
  6. Исследователи продемонстрировали простую атаку для обхода двухфакторной аутентификации
  7. «Яндекс» запустил двухфакторную аутентификацию без паролей
  8. Николай Корабельников: Зачем нужен сервер аутентификации
  9. Google против паролей: Начались продажи USB-ключей для доступа к сайтам
  10. Двухфакторная аутентификация слишком сложна, считают администраторы

Биометрическая аутентификация

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

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

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

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

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

Понятие аутентификации

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

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

Итоги

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

Но имейте в виду: для SMS потребуется мобильная сеть, а для Push-сообщений – интернет-соединение. Чтобы не зависеть от покрытия сети и обезопасить свои аккаунты, установите приложение для аутентификации или используйте биометрический метод защиты. А в том случае, когда необходимо защитить очень важные сведения с повышенной секретностью, лучше купить ключ безопасности.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Adblock
detector