Авторизация и аутентификация для всех и каждого, часть 2

Токен безопасности, или секьюрити токен (англ. Security token) – это физическое или цифровое устройство, которое обеспечивает двухфакторную аутентификацию (2FA) для пользователя, чтобы подтвердить его личность в процессе входа в систему. Обычно он используется как форма идентификации для физического доступа или как метод доступа к компьютерной системе. Токен может быть предметом или картой, которая отображает или содержит информацию о безопасности пользователя и может быть проверена системой.

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

Как работают токены безопасности?

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

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

JWT

Теперь давайте начнем изучать JWT. Спецификация веб-токена JSON (RFC 7519) была впервые опубликована 28 декабря 2010 г. и последний раз обновлялась в мае 2015 г.

У JWT есть много преимуществ перед ключами API, в том числе:

• Ключи API — это случайные строки, тогда как JWT содержат информацию и метаданные. Эта информация и метаданные могут описывать широкий спектр вещей, таких как личность пользователя, данные авторизации и срок действия токена в пределах временного интервала или по отношению к домену.
• Для JWT не требуется централизованный орган выдачи или отзыва.
• JWT совместимы с OAUTH2.
• Данные JWT можно проверить.
• У JWT есть элементы управления сроком действия.
• JWT предназначены для сред с ограниченным пространством, таких как заголовки авторизации HTTP.
• Данные передаются в формате JavaScript Object Notation (JSON).
• JWT представлены с использованием кодировки Base64url/

Типы токенов безопасности

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

• Одноразовые пароли (OTP). Одной из форм токена цифровой безопасности являются одноразовые пароли. Они действительны только для одного сеанса входа в систему, то есть они используются один раз и никогда больше. После первоначального использования сервер аутентификации уведомляется о том, что OTP не следует использовать повторно. OTP обычно генерируются с использованием криптографического алгоритма из общего секретного ключа, состоящего из двух уникальных и случайных элементов данных. Один элемент – это случайный идентификатор сеанса, а другой – секретный ключ.
• Отключенные токены. Это форма цифрового токена безопасности, который физически или логически не подключается к компьютеру. Устройство может генерировать OTP или другие учетные данные. Приложение для ПК, которое отправляет текстовое сообщение на смартфон, которое пользователь должен ввести при входе в систему, использует отключенный токен.
• Подключенные токены. Подключенный токен – это физический объект, который напрямую подключается к компьютеру или сенсору. Устройство считывает подключенный токен и предоставляет или запрещает доступ. YubiKey – это пример подключенного токена.
• Бесконтактные токены. Бесконтактные токены образуют логическое соединение с компьютером, не требуя физического соединения. Эти токены подключаются к системе по беспроводной сети и разрешают или запрещают доступ через это соединение. Например, Bluetooth часто используется как метод установления соединения с бесконтактным токеном.
• Программные токены системы единого входа (SSO). Программные токены системы единого входа хранят цифровую информацию, такую ​​как имя пользователя или пароль. Они позволяют людям, которые используют несколько компьютерных систем и несколько сетевых служб, входить в каждую систему без необходимости запоминать несколько имен пользователей и паролей.
• Программируемые токены. Программируемый токен безопасности многократно генерирует уникальный код, действительный в течение определенного периода времени, часто 30 секунд, для предоставления доступа пользователю. Например, AWS Security Token Service – это приложение, которое генерирует коды 2FA, необходимые администраторам информационных технологий для доступа к некоторым облачным ресурсам Amazon Web Services.

Как выглядит JWT?

Вот пример JWT:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpYXQiOjE0MTY5MjkxMDksImp0aSI6ImFhN2Y4ZDBhOTVjIiwic2NvcGVzIjpbInJlcG8iLCJwdWJsaWNfcmVwbyJdfQ.XCEwpBGvOLma4TCoh36FU7XhUbcskygS81HE1uHLf0E

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

Заголовок JWT

Первая строка — это заголовок JWT. Это строка JSON в кодировке Base64 с кодировкой URL. Он указывает, какой криптографический алгоритм использовался для генерации подписи, и тип токена, который всегда имеет значение JWT. Алгоритм может быть, как симметричным, так и асимметричным.

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

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

Полезная нагрузка JWT

Вторая строка — это полезная нагрузка JWT. Это также строка JSON в кодировке Base64 с кодировкой URL. Он содержит несколько стандартных полей, которые называются «претензиями». Есть три типа требований: зарегистрированные, публичные и частные.

Зарегистрированные претензии предопределены. Вы можете найти их список в RFC JWT. Вот некоторые из наиболее часто используемых:

• iat: отметка времени выпуска токена.
• key: уникальная строка, которая может использоваться для проверки токена, но противоречит отсутствию централизованного органа эмитента.
• iss: строка, содержащая имя или идентификатор эмитента. Может быть доменным именем и может использоваться для удаления токенов из других приложений.
• nbf: отметка времени, когда токен должен считаться действительным. Должно быть равно или больше iat.
• exp: отметка времени, когда токен должен перестать быть действительным. Должно быть больше iatи nbf.

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

Подпись JWT

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

Подпись JWT — это комбинация трех вещей:

• заголовок JWT
• полезная нагрузка JWT
• секретное значение

Преимущества токена безопасности

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

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

Смена PIN-кода на токене

Для обеспечения информационной безопасности каждый токен обладает паролем — PIN-кодом.

По умолчанию токен имеет стандартный PIN-код:

• PIN-код пользователя по умолчанию — 12345678;
• PIN-код администратора по умолчанию — 87654321. PIN-код администратора даёт право использовать дополнительные функции: разблокировка PIN-кода пользователя, настройка параметров PIN-кодов и др.

Рекомендуется сменить стандартный PIN-код на уникальный. Чтобы сделать это, выполните следующие действия:

1. Подключите токен к компьютеру и откройте Панель управления Рутокен. В появившемся окне нажмите кнопку Ввести PIN-код… .

1. Далее введите PIN-код токена по умолчанию для пользователя или администратора.
2. После этого в блоке Управление PIN-кодами станет доступна кнопка Изменить… . Нажмите на неё.
3. В появившемся окне укажите новый PIN-код. отображает степень надёжности PIN-кода. Подтвердите новый PIN-код и нажмите ОК.

Уязвимости токенов безопасности

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

Сергей Воробьёв

Интернет-предприниматель, специалист по SEO и SMM, E-commerce, вебмастер, блогер.

JWT против сеансов

Но сначала, почему сеансы — не такая уж хорошая вещь? Что ж, есть три основных причины:

• Данные хранятся на сервере в виде обычного текста. Несмотря на то, что данные обычно не хранятся в общей папке, любой, у кого есть достаточный доступ к серверу, может прочитать содержимое файлов сеанса.
• Они включают запросы на чтение / запись файловой системы. Каждый раз, когда начинается сеанс или его данные изменяются, серверу необходимо обновить файл сеанса. То же самое происходит каждый раз, когда приложение отправляет файл cookie сеанса. Если у вас большое количество пользователей, вы можете получить медленный сервер, если не используете альтернативные варианты хранения сеансов, такие как Memcached и Redis.
• Распределенные / кластерные приложения. Поскольку файлы сеансов по умолчанию хранятся в файловой системе, трудно иметь распределенную или кластерную инфраструктуру для приложений высокой доступности — тех, которые требуют использования таких технологий, как балансировщики нагрузки и кластерные серверы. Необходимо реализовать другие носители данных и особые конфигурации — и делать это с полным осознанием их последствий.

P.S.

Мы разобрали основы JSON веб-токенов, но в этой теме еще много нюансов.

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

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

Хорошей практикой является установка небольшого срока действия JSON веб-токенов. При этом скомпрометированный JWT очень быстро станет недействительным.

OpenID Connect

Это подводит нас к спецификации под названием OpenID Connect, или OIDC. OIDC — это спецификация OAuth 2.0, в которой говорится, как аутентифицировать пользователей. OpenID Foundation (OIDF) является руководителем стандартов OIDC.

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

ID Токены

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

OIDC объявляет фиксированный формат для токенов ID, которым является JWT.

JSON Web Token (JWT)

JSON Web Tokens, или JWT (иногда произносится как «jot»), состоит из трех URL-безопасных сегментов строки, соединенных точками. Сегмент заголовка, сегмента полезной нагрузки и крипто сегмента.

Сегмент заголовка

Первый сегмент является сегментом заголовка (header segment). Он может выглядеть примерно так:

eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9

Сегмент заголовка — это объект JSON, содержащий в закодирован виде алгоритм и тип токена. Он закодирован в base64Url (байтовые данные представлены в виде текста, который является URL-адресом и безопасным для имени файла).

Декодированный заголовок выглядит примерно так:

{ «alg»: «RS256», «typ»: «JWT» }

Сегмент полезной нагрузки

Второй сегмент — это сегмент полезной нагрузки (payload segment). Он может выглядеть так:

eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWUsImlhdCI6MTUxNjIzOTAyMn0

Это объект JSON, содержащий фрагмент данных называемый claim, который содержат информацию о пользователе и событии аутентификации. Например:

{ «sub»: «1234567890», «name»: «John Doe», «admin»: true, «iat»: 1516239022 }

Оно также кодируется в base64Url.

Крипто сегмент

Последний сегмент — крипто сегмент (crypto segment) или подпись (signature). JWT подписаны, поэтому они не могут быть изменены в процессе использования. Когда сервер авторизации выдает токен, он подписывает его с помощью ключа.

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

Claim

Claim можно перевести как требование, утверждение или как заявление.

Теперь, когда мы знаем об анатомии JWT, давайте поговорим подробнее об claim, этом фрагменте данных из сегмента полезной нагрузки. Согласно его названию, токены ID предоставляют идентификационную информацию, которая присутствует в формуле claim.

Аутентификационный Claim

Начнем с информации о событии аутентификации. Вот несколько примеров:

{ «iss»: «https://{you}.authz-server.com», «aud»: «RxHBtq2HL6biPljKRLNByqehlKhN1nCx», «exp»: 1570019636365, «iat»: 1570016110289, «nonce»: «3yAjXLPq8EPP0S», … }

Некоторые строки аутентификации в токене ID включают:

• iss (issuer — эмитент): издатель JWT, например, сервер авторизации
• aud (audience — аудитория): предполагаемый получатель JWT; для идентификаторов токенов это должен быть идентификатор клиента приложения, получающего токен
• exp (expiration time — время истечения): время истечения; идентификационный токен не должен быть принят после этого времени
• iat (issued at time — время выпуска): время, когда выдан идентификационный токен

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

Идентификационные данные (Identity Claim)

Claim также включают информацию о конечном пользователе. Вот несколько примеров таких данных:

{ «sub»: «google-oauth2|102582972157289381734», «name»: «Kim Maida», «picture»: «https://gravatar[…]», «twitter»: «https://twitter.com/KimMaida», «email»: «[email protected]», … }

Некоторые из стандартных строк профиля в токене ID включают:

• sub (subject): уникальный идентификатор пользователя; строка обязательна
• email
• email_verified
• birthdate
• etc.

После того как мы рассмотрели спецификации OAuth 2.0 и OpenID Connect пришло посмотреть, как применить наши знания в области идентификации.