Токен для устройства — Технологии Яндекса

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

Чтобы отозвать токен, нужно передать его в Яндекс.OAuth с идентификатором и паролем приложения.

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

В запросе их можно передать разными способами:

• В заголовке Authorization, в строке <client_id>:<client_secret>, закодированной методом base64. При этом следует указывать базовый (Basic) метод авторизации.

  Пример заголовка:

  Authorization: Basic NDc2MDE4N2Q4MWJjNGI3Nzk5NDc2YjQycjUxMDM3MTM6ZjI1YmViZjk5MWZmNDE5ODkzZGIyNTU3MjhlNGUxZGU= 

• В теле POST-запроса, в параметрах client_id и client_secret. Эти параметры обязательно должны передаваться одновременно.

Если Яндекс.OAuth получает заголовок Authorization, параметры client_id и client_secret в теле запроса игнорируются.

Запрос следует отправлять по протоколу HTTPS c помощью метода POST.

Формат запроса для отзыва токена:

POST /revoke_token HTTP/1.1
Host: oauth.yandex.ru
Content-type: application/x-www-form-urlencoded
Content-Length: 
 <длина тела запроса>
[Authorization: Basic <закодированная строка client_id:client_secret>]

   =<отзываемый токен>
[& =<идентификатор приложения>]
[& =<пароль приложения>]

Параметр	Описание
Обязательный параметр
access_token	OAuth-токен, который нужно отозвать.
Дополнительные параметры
client_id	Идентификатор приложения. Доступен в свойствах приложения (нажмите название приложения, чтобы открыть его свойства). Параметр обязателен, если в запросе не был указан заголовок Authorization.
client_secret	Пароль приложения. Доступен в свойствах приложения (нажмите название приложения, чтобы открыть его свойства). Параметр обязателен, если в запросе не был указан заголовок Authorization.

Яндекс.OAuth возвращает ответ в JSON-документе.

Возвращается ответ с HTTP-кодом 200 и следующим телом:

{
  "status": "ok"
}

Если запрос выполнить не удалось, то ответ возвращается с HTTP-кодом ошибки и ее описанием:

 {
  "": "Client not found",
  "": "invalid_client"
}

Ключ	Описание
error_description	Описание ошибки на естественном языке.
error	Код ошибки. Список возможных кодов приведен в таблице ниже.

HTTP-код ответа	Код ошибки	Описание
400	invalid_request	Неверный формат запроса (не указан обязательный параметр и т. п.).
400	invalid_grant	Переданный токен не принадлежит указанному приложению.
400 или 401	invalid_client	Возвращается в следующих случаях: Приложение с указанным идентификатором не найдено или заблокировано. Передан неверный пароль для заданного идентификатора приложения. HTTP-код ответа 401 возвращается, если идентификатор и пароль приложения были переданы в заголовке Authorization. В противном случае возвращается HTTP-код 400.
400	unsupported_token_type	Токен не может быть отозван, так как при запросе этого токена не был указан идентификатор устройства (параметр device_id). Если токен нельзя отозвать, его можно просто удалить из локального хранилища, чтобы приложение потеряло доступ к данным пользователя.

Справочник анонима. Как работают токены аутентификации и в чем их отличия от паролей

Содержание статьи

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

 

Справочник анонима

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

Другие статьи цикла:

Если для тебя эти материалы тривиальны — отлично! Но ты сделаешь доброе дело, отправив ссылку на них своим друзьям, знакомым и родственникам, менее подкованным в технических вопросах.

 

Подписываемся под данными

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

Схема генерации HMAC (hash-based message authentication code), кода аутентификации сообщений с использованием хеш-функции

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

 

Придумываем коды доступа

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

Создание безопасных одноразовых паролей состоит из двух этапов:

1. Первичная настройка — включение двухфакторной аутентификации.
2. Использование пароля — непосредственный ввод кода и отправка для проверки.

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

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

На самом деле весь секрет — последовательность из случайных символов, которые закодированы в формате Base32. Суммарно они занимают не меньше 128 бит, а чаще и все 190 бит. Эту последовательность и видит пользователь как текст или QR-код.

Так выглядит код QR для обмена секретом
Тот же самый секрет, только текстом

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

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

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

Возьмем время празднования Нового года в формате UNIX (1577811600000) и посчитаем порядковый номер нашего пароля: поделим на 30 секунд — 52593720. Воспользуемся нашим секретом и вычислим хеш — по стандарту RFC 6238 это функция SHA-1:

$ echo -n '52593720' | openssl sha1 -hmac 'QWERTYUI12345678'
e818e7f3efcb625658c603b08b12522f1e4d160a

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

Теперь дело за малым: нужно получить шесть цифр, которые мы и будем отправлять на сервер при авторизации. Возьмем последние четыре бита хеша — сдвиг, — это будет число a, или 10. Именно по этому сдвигу расположен наш код, который пока в виде байтов, — 03b08b12 = 61901586. Отбросим все цифры этого числа, кроме шести последних, и получим наш новенький, готовый к использованию одноразовый код — 901586.

 

Входим в приложение

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

 

Как работает JWT?

Если есть данные, достоверность которых следует подтвердить, нам надо подписать их секретным ключом, используя HMAC. Для этого применяется такой же способ хеширования, что и для одноразовых паролей, только вместо шести цифр берется весь хеш целиком. Единственная разница — это сам алгоритм хеширования: в таких токенах SHA-1 считают слишком коротким и небезопасным, поэтому обычно используют SHA-256.

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

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

Любой токен состоит из трех частей: заголовка со служебной информацией, данных и подписи. Так как стандартом безопасности считается SHA-256, то мы запишем его в наш заголовок.

{
  "alg": "HS256"
}

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

{
  "user_id": 123456
}

Закодируем наши данные и заголовок в Base64 и соединим их через точку. Это делается, чтобы безопасно пересылать данные через HTTP: eyJhbGciOiJIUzI1NiJ9.eyJ1c2VyX2lkIjogMTIzNDU2fQ. Теперь, зная и данные, и заголовок, мы можем посчитать ее хеш, который содержит наш пароль — строку QWERTYUI12345678.

$ echo -n 'eyJhbGciOiJIUzI1NiJ9.eyJ1c2VyX2lkIjogMTIzNDU2fQ' | openssl sha256 -hmac 'QWERTYUI12345678'
e0a6b48a961ee3fc7eb38afcdb1a8ef22efb0572e1d5333b85db2aa66919e98e

Этот хеш нам тоже надо перевести в кодировку Base64 и затем присоединить к уже имеющейся строке из заголовка и данных: eyJhbGciOiJIUzI1NiJ9.eyJ1c2VyX2lkIjogMTIzNDU2fQ.4Ka0ipYe4/x-s4r82xqO8i77BXLh2TM7hdsqpmkZ6Y4 — это и есть наш токен. Можно пользоваться!

Так выглядит наш токен

 

Заключение

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

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

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

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

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

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

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

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

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

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

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

HTTP authentication

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

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

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

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

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

Forms authentication

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

Работает это по следующему принципу: в веб-приложение включается HTML-форма, в которую пользователь должен ввести свои username/password и отправить их на сервер через HTTP POST для аутентификации. В случае успеха веб-приложение создает session token, который обычно помещается в browser cookies. При последующих веб-запросах session token автоматически передается на сервер и позволяет приложению получить информацию о текущем пользователе для авторизации запроса.

Пример forms authentication.

Приложение может создать session token двумя способами:

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

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

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

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

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

1. URL query — считается небезопасным вариантом, т. к. строки URL могут запоминаться браузерами, прокси и веб-серверами.
2. Request body — безопасный вариант, но он применим только для запросов, содержащих тело сообщения (такие как POST, PUT, PATCH).
3. HTTP header —оптимальный вариант, при этом могут использоваться и стандартный заголовок Authorization (например, с Basic-схемой), и другие произвольные заголовки.

Распространенные уязвимости и ошибки реализации

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

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

• Веб-приложение позволяет пользователям создавать простые пароли.
• Веб-приложение не защищено от возможности перебора паролей (brute-force attacks).
• Веб-приложение само генерирует и распространяет пароли пользователям, однако не требует смены пароля после первого входа (т.е. текущий пароль где-то записан).
• Веб-приложение допускает передачу паролей по незащищенному HTTP-соединению, либо в строке URL.
• Веб-приложение не использует безопасные хэш-функции для хранения паролей пользователей.
• Веб-приложение не предоставляет пользователям возможность изменения пароля либо не нотифицирует пользователей об изменении их паролей.
• Веб-приложение использует уязвимую функцию восстановления пароля, которую можно использовать для получения несанкционированного доступа к другим учетным записям.
• Веб-приложение не требует повторной аутентификации пользователя для важных действий: смена пароля, изменения адреса доставки товаров и т. п.
• Веб-приложение создает session tokens таким образом, что они могут быть подобраны или предсказаны для других пользователей.
• Веб-приложение допускает передачу session tokens по незащищенному HTTP-соединению, либо в строке URL.
• Веб-приложение уязвимо для session fixation-атак (т. е. не заменяет session token при переходе анонимной сессии пользователя в аутентифицированную).
• Веб-приложение не устанавливает флаги HttpOnly и Secure для browser cookies, содержащих session tokens.
• Веб-приложение не уничтожает сессии пользователя после короткого периода неактивности либо не предоставляет функцию выхода из аутентифицированной сессии.

Аутентификация по сертификатам

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

На стороне клиента сертификат вместе с закрытым ключом могут храниться в операционной системе, в браузере, в файле, на отдельном физическом устройстве (smart card, USB token). Обычно закрытый ключ дополнительно защищен паролем или PIN-кодом.

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

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

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

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

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

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

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

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

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

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

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

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

Аппаратный токен RSA SecurID генерирует новый код каждые 30 секунд.

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

Аутентификация по ключам доступа

Этот способ чаще всего используется для аутентификации устройств, сервисов или других приложений при обращении к веб-сервисам. Здесь в качестве секрета применяются ключи доступа (access key, API key) — длинные уникальные строки, содержащие произвольный набор символов, по сути заменяющие собой комбинацию username/password.

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

Хороший пример применения аутентификации по ключу — облако Amazon Web Services. Предположим, у пользователя есть веб-приложение, позволяющее загружать и просматривать фотографии, и он хочет использовать сервис Amazon S3 для хранения файлов. В таком случае, пользователь через консоль AWS может создать ключ, имеющий ограниченный доступ к облаку: только чтение/запись его файлов в Amazon S3. Этот ключ в результате можно применить для аутентификации веб-приложения в облаке AWS.

Пример применения аутентификации по ключу.

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

С технической точки зрения, здесь не существует единого протокола: ключи могут передаваться в разных частях HTTP-запроса: URL query, request body или HTTP header. Как и в случае аутентификации по паролю, наиболее оптимальный вариант — использование HTTP header. В некоторых случаях используют HTTP-схему Bearer для передачи токена в заголовке (Authorization: Bearer [token]). Чтобы избежать перехвата ключей, соединение с сервером должно быть обязательно защищено протоколом SSL/TLS.

Пример аутентификации по ключу доступа, переданного в HTTP заголовке.

Кроме того, существуют более сложные схемы аутентификации по ключам для незащищенных соединений. В этом случае, ключ обычно состоит их двух частей: публичной и секретной. Публичная часть используется для идентификации клиента, а секретная часть позволяет сгенерировать подпись. Например, по аналогии с digest authentication схемой, сервер может послать клиенту уникальное значение nonce или timestamp, а клиент — возвратить хэш или HMAC этого значения, вычисленный с использованием секретной части ключа. Это позволяет избежать передачи всего ключа в оригинальном виде и защищает от replay attacks.

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

Такой способ аутентификации чаще всего применяется при построении распределенных систем Single Sign-On (SSO), где одно приложение (service provider или relying party) делегирует функцию аутентификации пользователей другому приложению (identity provider или authentication service). Типичный пример этого способа — вход в приложение через учетную запись в социальных сетях. Здесь социальные сети являются сервисами аутентификации, а приложение доверяет функцию аутентификации пользователей социальным сетям.

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

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

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

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

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

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

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

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

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

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

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

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

1. Simple Web Token (SWT) — наиболее простой формат, представляющий собой набор произвольных пар имя/значение в формате кодирования HTML form. Стандарт определяет несколько зарезервированных имен: Issuer, Audience, ExpiresOn и HMACSHA256. Токен подписывается с помощью симметричного ключа, таким образом оба IP- и SP-приложения должны иметь этот ключ для возможности создания/проверки токена.

   Пример SWT токена (после декодирования).
   

   Issuer=http://auth.myservice.com&
   Audience=http://myservice.com&
   ExpiresOn=1435937883&
   UserName=John Smith&
   UserRole=Admin&
   HMACSHA256=KOUQRPSpy64rvT2KnYyQKtFFXUIggnesSpE7ADA4o9w

   
   
2. JSON Web Token (JWT) — содержит три блока, разделенных точками: заголовок, набор полей (claims) и подпись. Первые два блока представлены в JSON-формате и дополнительно закодированы в формат base64. Набор полей содержит произвольные пары имя/значения, притом стандарт JWT определяет несколько зарезервированных имен (iss, aud, exp и другие). Подпись может генерироваться при помощи и симметричных алгоритмов шифрования, и асимметричных. Кроме того, существует отдельный стандарт, отписывающий формат зашифрованного JWT-токена.

   Пример подписанного JWT токена (после декодирования 1 и 2 блоков).
   

   { «alg»: «HS256», «typ»: «JWT» }.
   { «iss»: «auth.myservice.com», «aud»: «myservice.com», «exp»: «1435937883», «userName»: «John Smith», «userRole»: «Admin» }.
   S9Zs/8/uEGGTVVtLggFTizCsMtwOJnRhjaQ2BMUQhcY

3. Security Assertion Markup Language (SAML) — определяет токены (SAML assertions) в XML-формате, включающем информацию об эмитенте, о субъекте, необходимые условия для проверки токена, набор дополнительных утверждений (statements) о пользователе. Подпись SAML-токенов осуществляется при помощи ассиметричной криптографии. Кроме того, в отличие от предыдущих форматов, SAML-токены содержат механизм для подтверждения владения токеном, что позволяет предотвратить перехват токенов через man-in-the-middle-атаки при использовании незащищенных соединений.

Стандарт SAML

Стандарт Security Assertion Markup Language (SAML) описывает способы взаимодействия и протоколы между identity provider и service provider для обмена данными аутентификации и авторизации посредством токенов. Изначально версии 1.0 и 1.1 были выпущены в 2002 – 2003 гг., в то время как версия 2.0, значительно расширяющая стандарт и обратно несовместимая, опубликована в 2005 г.

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

1. Assertions — собственный формат SAML токенов в XML формате.
2. Protocols — набор поддерживаемых сообщений между участниками, среди которых — запрос на создание нового токена, получение существующих токенов, выход из системы (logout), управление идентификаторами пользователей, и другие.
3. Bindings — механизмы передачи сообщений через различные транспортные протоколы. Поддерживаются такие способы, как HTTP Redirect, HTTP POST, HTTP Artifact (ссылка на сообщения), SAML SOAP, SAML URI (адрес получения сообщения) и другие.
4. Profiles — типичные сценарии использования стандарта, определяющие набор assertions, protocols и bindings необходимых для их реализации, что позволяет достичь лучшей совместимости. Web Browser SSO — один из примеров таких профилей.

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

Рассмотрим краткий пример использования SAML для сценария Single Sign-On. Пользователь хочет получить доступ на защищенный ресурс сервис-провайдера (шаг № 1 на диаграмме аутентификации пассивных клиентов). Т. к. пользователь не был аутентифицирован, SP отправляет его на сайт identity provider’а для создания токена (шаг № 2). Ниже приведен пример ответа SP, где последний использует SAML HTTP Redirect binding для отправки сообщения с запросом токена:

В случае такого запроса, identity provider аутентифицирует пользователя (шаги №3-4), после чего генерирует токен. Ниже приведен пример ответа IP с использованием HTTP POST binding (шаг № 5):

После того как браузер автоматически отправит эту форму на сайт service provider’а (шаг № 6), последний декодирует токен и аутентифицирует пользователя. По результатам успешной авторизации запроса пользователь получает доступ к запрошенному ресурсу (шаг № 7).

Стандарты WS-Trust и WS-Federation

WS-Trust и WS-Federation входят в группу стандартов WS-*, описывающих SOAP/XML-веб сервисы. Эти стандарты разрабатываются группой компаний, куда входят Microsoft, IBM, VeriSign и другие. Наряду с SAML, эти стандарты достаточно сложные, используются преимущественно в корпоративных сценариях.

Стандарт WS-Trust описывает интерфейс сервиса авторизации, именуемого Secure Token Service (STS). Этот сервис работает по протоколу SOAP и поддерживает создание, обновление и аннулирование токенов. При этом стандарт допускает использование токенов различного формата, однако на практике в основном используются SAML-токены.

Стандарт WS-Federation касается механизмов взаимодействия сервисов между компаниями, в частности, протоколов обмена токенов. При этом WS-Federation расширяет функции и интерфейс сервиса STS, описанного в стандарте WS-Trust. Среди прочего, стандарт WS-Federation определяет:

• Формат и способы обмена метаданными о сервисах.
• Функцию единого выхода из всех систем (single sign-out).
• Сервис атрибутов, предоставляющий дополнительную информацию о пользователе.
• Сервис псевдонимов, позволяющий создавать альтернативные имена пользователей.
• Поддержку пассивных клиентов (браузеров) посредством перенаправления.

Можно сказать, что WS-Federation позволяет решить те же задачи, что и SAML, однако их подходы и реализация в некоторой степени отличаются.

Стандарты OAuth и OpenID Connect

В отличие от SAML и WS-Federation, стандарт OAuth (Open Authorization) не описывает протокол аутентификации пользователя. Вместо этого он определяет механизм получения доступа одного приложения к другому от имени пользователя. Однако существуют схемы, позволяющие осуществить аутентификацию пользователя на базе этого стандарта (об этом — ниже).

Первая версия стандарта разрабатывалась в 2007 – 2010 гг., а текущая версия 2.0 опубликована в 2012 г. Версия 2.0 значительно расширяет и в то же время упрощает стандарт, но обратно несовместима с версией 1.0. Сейчас OAuth 2.0 очень популярен и используется повсеместно для предоставления делегированного доступа и третье-сторонней аутентификации пользователей.

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

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

Как раз эту проблему и позволяет решить стандарт OAuth: он описывает, как приложение путешествий (client) может получить доступ к почте пользователя (resource server) с разрешения пользователя (resource owner). В общем виде весь процесс состоит из нескольких шагов:

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

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

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

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

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

1. Зачастую API сервера ресурсов включает операцию, предоставляющую информацию о самом пользователе (например, /me в Facebook API). Приложение может выполнять эту операцию каждый раз после получения токена для идентификации клиента. Такой метод иногда называют псевдо-аутентификацией.
2. Использовать стандарт OpenID Connect, разработанный как слой учетных данных поверх OAuth (опубликован в 2014 г.). В соответствии с этим стандартом, сервер авторизации предоставляет дополнительный identity token на шаге № 2. Этот токен в формате JWT будет содержать набор определенных полей (claims) с информацией о пользователе.

Стоит заметить, что OpenID Connect, заменивший предыдущие версии стандарта OpenID 1.0 и 2.0, также содержит набор необязательных дополнений для поиска серверов авторизации, динамической регистрации клиентов и управления сессией пользователя.

Заключение

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

Способ	Основное применение	Протоколы
По паролю	Аутентификация пользователей	HTTP, Forms
По сертификатам	Аутентификация пользователей в безопасных приложениях; аутентификация сервисов	SSL/TLS
По одноразовым паролям	Дополнительная аутентификация пользователей (для достижения two-factor authentication)	Forms
По ключам доступа	Аутентификация сервисов и приложений	—
По токенам	Делегированная аутентификация пользователей; делегированная авторизация приложений	SAML, WS-Federation, OAuth, OpenID Connect

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

Автор: Дмитрий Выростков, Solutions Architect в DataArt.

Что такое токен — Электронная подпись — СКБ Контур

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

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

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

В России два вида токенов:

• Рутокен – ключевой носитель, разработанный и широко применяемый в России. Продукты на базе Рутокена широко используются в коммерческих и государственных проектах. Кроме того, безопасность рутокенов постоянно повышается — в частности, в новых версиях операции шифрования документа выполняются не только на компьютере, но и в самом устройстве. Это делает электронную подпись более защищенной от вирусов и хакерских атак.
• Е-токен – европейский вариант ключевого носителя. Е-токены могут содержать практически любой дополнительный чип RFID (радио-метку) для интеграции с системами контроля и управления доступом в помещения.

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

УЦ СКБ Контур выпускает все виды электронных подписей.

Подобрать подпись

Токен (авторизации) — это… Что такое Токен (авторизации)?

У этого термина существуют и другие значения, см. Токен. eToken от Aladdin Knowledge Systems

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

Токены предназначены для электронного удостоверения личности (например, клиента, получающего доступ к банковскому счёту), при этом они могут использоваться как вместо, так и вместе с паролем. В некотором смысле токен — это электронный ключ для доступа к чему-либо.

Обычно аппаратные токены обладают небольшими размерами, что позволяет носить их в кармане или кошельке, часто они оформлены в виде брелоков. Некоторые предназначены для хранения криптографических ключей, таких как электронная подпись или биометрические данные (например, детали дактилоскопического узора). В одни встроена защита от взлома, в другие — мини-клавиатура для ввода PIN-кода или же просто кнопка вызова процедуры генерации и дисплей для вывода сгенерированного ключа. Токены обладают разъёмом USB, функциями RFID или беспроводным интерфейсом Bluetooth для передачи сгенерированной последовательности ключей на клиентскую систему.

См. также

Ссылки

Токен — что это такое?

Вопрос электронной безопасности – один из самых важных в современном мире. Было предложено множество различных способов его решения. Токен – это один из них. Что он собой представляет, и какие особенности его применения существуют?

Токен – что это?

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

Токены могут быть использованы вместо пароля или как дополнение к нему. Обычно они имеют незначительный размер и спокойно помещаются в кошелёк или карман. Более совершенные версии предлагают также возможность хранить криптографические ключи (электронную подпись, биометрические данные). Токен – что это внешне? Все ли они одинаковы? Разнятся они и по внешнему виду, а не только по функционалу: некоторые имеют только экран, другие дополнены миниатюрной клавиатурой, а третьи просто имеют небольшое кнопочное дополнение. Токены оборудованы функциями RFID, разъёмом USB или интерфейсом Bluetooth, чтобы передавать ключ на клиентскую систему. Их изготавливает довольно много компаний, и представлен широчайший ассортимент. Среди ведущих производителей есть такие предприятия: «Е Токен» и «RuToken»

Типы токенов

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

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

Уязвимости

Существует две основные проблемы при использовании токенов:

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

Мобильные устройства в роли токенов

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

Токен (авторизации) — Википедия. Что такое Токен (авторизации)

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

Токены предназначены для электронного удостоверения личности (например, клиента, получающего доступ к банковскому счёту), при этом они могут использоваться как вместо пароля, так и вместе с ним. В некотором смысле токен — это электронный ключ для доступа к чему-либо.

Обычно аппаратные токены обладают небольшими размерами, что позволяет носить их в кармане или кошельке, часто они оформлены в виде брелоков. Некоторые предназначены для хранения криптографических ключей, таких как электронная подпись или биометрические данные (например, детали дактилоскопического узора). В одни встроена защита от взлома, в другие — мини-клавиатура для ввода PIN-кода или же просто кнопка вызова процедуры генерации и дисплей для вывода сгенерированного ключа. Токены обладают разъёмом USB, функциями RFID или беспроводным интерфейсом Bluetooth для передачи сгенерированной последовательности ключей на клиентскую систему.

Типы паролей

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

• Токен со статическим паролем.

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

• Токен с синхронно динамическим паролем.

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

• Токен с асинхронным паролем.

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

• Токен вызов-ответ.

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

А === Одноразовые пароли, синхронизированные по времени ===

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

Одноразовые пароли на основе математического алгоритма

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

Типы токенов

Токены могут содержать чипы с различными функциями от очень простых, до очень сложных, в том числе и несколько методов аутентификации. Простейшим токенам безопасности не нужны никакие подключения к компьютеру. Токены имеют физический дисплей; Пользователь просто вводит отображаемое число для входа. Другие токены подключаются к компьютерам, используя беспроводные технологии, такие как Bluetooth. Эти токены передают ключевую последовательность локальному клиенту или ближайшей точке доступа. Кроме того, другой широко доступной формой токена является мобильное устройство, которое взаимодействует с использованием внеполосного канала (например, SMS или USSD). Тем не менее, другие токены подключаются к компьютеру, и может потребоваться PIN-код. В зависимости от типа токена, операционная система компьютера или прочитает ключ от токена и выполнит криптографические операции на нём, или попросит, чтобы программируемое оборудование токена выполнило эти операции самостоятельно. Таким приложением является аппаратный ключ (электронный ключ), необходимый для некоторых компьютерных программ, чтобы доказать право собственности на программное обеспечение. Ключ помещается в устройство ввода, и программное обеспечение получает доступ к рассматриваемому устройству ввода / вывода, чтобы разрешить использование данного программное обеспечение. Коммерческие решения предоставляются различными поставщиками, каждый со своими собственными (и часто запатентованными) функциями безопасности. Проекты токенов, соответствующие определённым стандартам безопасности, удостоверены в Соединённых Штатах как совместимые с FIPS 140, федеральный стандарт безопасности США. Токены без какой-либо сертификации часто не отвечают стандартам безопасности принятым правительством США, они не прошли тщательное тестирование, и, вероятно, не могут обеспечить такой же уровень криптографической защиты, как токены, которые были разработаны и проверены сторонними агентствами.

Токены без подключения

Токены без подключения не имеют ни физического, ни логического подключения к компьютеру клиента. Как правило, они не требуют специального устройства ввода, а вместо этого используют встроенный экран для отображения сгенерированных данных аутентификации, которые, в свою очередь, пользователь вводит вручную с помощью клавиатуры. Токены без подключения являются наиболее распространённым типом токена (авторизации), используемый (обычно в сочетании с паролем) в двухфакторной аутентификации для онлайн-идентификации.^[1]

Модель RSA SecurID SID700 представляет собой небольшой брелок.^[2]

Токены с подключением

Пример схемы использования токена

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

PC Card широко используются в ноутбуках. Предпочтительными в качестве токена являются карты типа II, потому что они в 2 раза тоньше чем, карты типа III.

Аудио вход (audio jack port) может быть использован для установления связи между мобильными устройствами, такими как iPhone, iPad и Android. Наиболее известное устройство — это Square, карт ридер для iPhone и Android.

Технология передачи данных с помощью данного устройства скрыта патентом компании Apple, но преподаватели и студенты факультета электротехники и компьютерных наук Мичиганского университета разработали устройство «HiJack», которое позволяет обмениваться данными между периферическим устройством с низким энергопотреблением и i устройством. Небольшой мощности, которую получает HiJack с аудио порта, достаточно для питания микроконтроллера TI MSP430 и соединения HiJack со специально разработанным для iOS приложением.^[3]

Токены могут также использоваться в качестве фото удостоверения личности. Сотовые телефоны и PDAs могут служить токенами безопасности при правильном программировании.

Смарт-карты

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

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

Пример использования токена

С помощью токена можно защитить учётную запись на компьютере, используя сложный пароль, не запоминая его. Для этого вы должны купить программное обеспечение(например: eToken Network Logon) и токен, подходящий к нему. С помощью программы токен получит ключ для входа в систему. При повторном запуске вам потребуется вставить токен (например в USB порт) и ввести PIN. После проделанных операций вы получаете доступ к системе.

Беспроводные токены

В отличие от токенов с подключением, беспроводные токены формируют логическую связь с компьютером клиента и не требуют физического подключения. Отсутствие необходимости физического контакта делает их более удобными, чем токены с подключением и токены без подключения. В результате данный тип токенов является популярным выбором для систем входа без ключа и электронных платежей, таких как Mobil Speedpass, которые используют RFID, для передачи информации об аутентификации от токена брелока. Тем не менее существуют различные проблемы безопасности, после исследований в Университете имени Джона Хопкинса, и Лаборатории RSA обнаружили, что RFID метки могут быть легко взломаны.^[5] Ещё одной проблемой является то, что беспроводные токены имеют относительно короткий срок службы 3-5 лет, в то время как USB токены могут работать до 10 лет.

Bluetooth-токен Рутокен

Bluetooth-токены

Bluetooth-токены удобны в применении, поскольку для их использования не требуется физического подключения устройства, токен может находится в кармане пользователя. Также одним из преимуществ Bluetooth-токенов является возможность работы с мобильными устройствами, многие из которых не поддерживают возможность физического подключения. Стоит отметить, что Bluetooth-токенам необходимо собственный элемент питания для работы беспроводного модуля и криптографического устройства, поэтому в них устанавливается аккумулятор, который периодически необходимо заряжать (для современных устройств время работы составляет около 40 часов). Зарядка встроенного аккумулятора осуществляется либо с помощью специального блока питания, либо с помощью обычного USB-штекера, который одновременно позволяет использовать USB-подключение, если нет возможности подключения через Bluetooth. Bluetooth-аутентификация работает на расстоянии около 10 метров, что позволяет выполнять определённые действия, если пользователь отлучился (например, заблокировать рабочий компьютер).

Токен и технологии единого входа

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

Работа с веб-приложениями посредством плагина

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

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

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

Мобильные устройства в качестве токена

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

Уязвимости

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

Любая система, которая позволяет пользователям аутентифицироваться через ненадёжную сеть (например, Интернет) является уязвимой к атаке «человек посередине». MITM-атака (англ. Man in the middle) — термин в криптографии, обозначающий ситуацию, когда криптоаналитик (атакующий) способен читать и видоизменять по своей воле сообщения, которыми обмениваются корреспонденты, причём ни один из последних не может догадаться о его присутствии в канале. Метод компрометации канала связи, при котором взломщик, подключившись к каналу между контрагентами, осуществляет активное вмешательство в протокол передачи, удаляя, искажая информацию или навязывая ложную.

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

TrustScreen

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

• визуализация документа на экране с целью контроля корректности,
• вычисление хеша документа,
• подпись хеша документа производится на неизвлекаемом ключе,
• ввод PIN-кода или команды подтверждения подписи, минуя клавиатуру компьютера.

См. также

Примечания

Ссылки

Источники

Основной источник