otp

RUEN

Главная » Блоги » otp

В массовых информационных системах для проверки подлинности клиентов перед серверами чаще всего используется парольная аутентификация. Пароль – это классический секрет, c обработкой которого может справиться обычный человек. Пароль достаточно легко запомнить, для его хранения не нужны дополнительные устройства, пароль легко ввести практически в любой программно-аппаратной среде. Но парольная аутентификация обладает и существенными недостатками. Во-первых, пользователь не способен запомнить сильный высокоэнтропийный секрет. Пароль – это всегда слабый секрет, и у противника появляется возможности угадать его. Во-вторых, парольная аутентификация теряет надежность в агрессивной среде, т. е. там, где противник может перехватывать вводимые пользователем данные. Аутентификация может быть усилена, если пользователь применяет специальные устройства, которые способны хранить сильные секреты и проводить с ними криптографические вычисления. С помощью этих устройств можно организовать надежный криптографический протокол аутентификации. Но такой протокол, как правило, будет иметь высокую вычислительную сложность. Поэтому устройство должно обладать достаточно серъезными вычислительными ресурсами, что повышает его стоимость и во многих случаях делает его применение экономически неоправданным. Кроме этого, для выполнения сложного протокола устройство должно быть плотно сопряжено с информационной системой, в которой пользователь работает, а это оказывается не всегда возможным. Выходом является упрощение криптографических вычислений и выдача их результата в виде короткого пароля с малым сроком действия. Такой пароль принято называть одноразовым (one-time password, OTP). Даже если одноразовый пароль будет скомпрометирован, компрометация затронет только конкретный сеанс пользователя или даже определенный промежуток этого сеанса. Средства формирования одноразовых паролей получили широкое распространение в связи с массовой аутентификацией в сети Интернет. Эти средства могут быть аппаратными (пример – токен SecureID компании RSA) или программными (приложение Authenticator компании Google). Унификация средств требует стандартизации алгоритмов формирования одноразовых паролей, правил формирования их входных данных, правил кодирования паролей, правил аутентификации и пр. Основные шаги по стандартизации были сделаны международным комитетом OATH (Open AuTHentication). Под эгидой этого комитета были разработаны 3 основных стандарта: RFC 4226, RFC 6238 и RFC 6287. В стандартах определены алгоритмы HOTP, TOTP и OCRA. Алгоритмы строят пароль по общему для клиента и сервера ключу и дополнительным  уникальным данным:  монотонному счетчику, отметке времени,  случайному запросу.  Алгоритмы по сути определяют 3 типа систем  аутентификации: на  основе событий,  на основе времени и на основе запросов. В системах первого типа пароль меняется при возникновении определенных событий. Как правило, таким событием для клиента является любая попытка аутентификации, а для сервера – успешная попытка. В системе S/KEY, которая используется для аутентификации в операционных системах Linux, одноразовый пароль является результатом многократного хэширования мастер-пароля X0. Клиент хэширует мастер-пароль n раз c помощью функции h и отправляет полученное значение Xn = hn(X0) серверу. В первой попытке аутентификации клиент предъявляет одноразовый пароль Xn-1 = hn–1(X0). Сервер признает его правильным и меняет Xn на Xn-1, если h(Xn-1) = Xn. В следующей попытке клиент предъявляет X n-2, а сервер меняет Xn-1 на Xn-2, и т. д. Противнику, который перехватывает текущий одноразовый пароль Xi, для успешной аутентификации требуется найти предыдущий пароль Xi-1, а для этого обратить h. Задача обращения будет вычислительно трудной, если h – криптографически стойкая функция хэширования. В системах на основе событий противник может предъявлять серверу пароли до тех пор, пока целевое событие не произошло и, таким образом, возникают предпосылки для перебора паролей. Для защиты от перебора сервер должен предусмотреть блокировку ввода пароля на некоторое время или до возникновения определенного события, например, разблокировки. События для клиента и сервера могут различаться, их пароли могут разойтись, и поэтому система аутентификации нуждается в дополнительных механизмах синхронизации. В системах на основе алгоритма HOTP клиент и сервер хранят счетчики попыток аутентификации. Синхронизация состоит в том, что сервер проверяет пароль не только на текущем значении счетчика, но и на d будущих значениях. Фактически сервер проверяет будущие пароли, которые могут оказаться текущими  относительно клиента. Если i-й будущий пароль отказался подходящим, то сервер восстанавливает синхронизацию, увеличивая счетчик не на 1, а на i + 1. Синхронизация будет полностью потеряна, если клиент выполнил более d попыток аутентификации, о которых не  известно серверу. В системах на основе времени одноразовый пароль обновляется каждые t секунд (на практике t = 30 или 60). Устройство должно быть снаряжено достаточно точным таймером, что может привести к значительному его удорожанию. С другой стороны, системы на основе времени имеют ряд преимуществ относительно систем на основе событий. Во-первых, возможности противника по перебору паролей ограничены – он должен успеть подобрать пароль в течение t секунд. Во-вторых, опасность рассинхронизации не столь велика, как в предыдущем случае. Для синхронизации клиенту и серверу достаточно согласовать показания времени.  В системах на основе запросов одноразовый пароль строится на основании случайного запроса сервера. Фактически одноразовый пароль превращается в ответ протокола «запрос – ответ».  Таймер не нужен, но  дополнительно к интерфейсу вывода пароля должен быть предусмотрен интерфейс ввода запроса. Проблемы с синхронизацией отсутствуют, но противник может перебирать пароли относительно текущего запроса сколь угодно долго. Серверу следует ограничивать число  попыток ввода пароля, иначе система перестанет быть стойкой. Подведем итоги: Система Аппаратные требования Синхронизация Надежность на основе событий интерфейс вывода (дисплей) динамически по правильным паролям, возможна потеря средняя на основе времени интерфейс вывода, таймер согласование времени высокая на основе запросов интерфейс вывода, интерфейс ввода (миниклавиатура) не нужна высокая

Новости 29.04.2023 TIBO 2023 читать дальше 02. 01.2023 Программный комплекс ЭАДП читать дальше 27.12.2022 С Новым годом! читать дальше 21.11.2022 Программный инструментарий читать дальше 13.09.2022 XIII Международная научная конференция читать дальше 05.09.2022 Компьютерный анализ данных и моделирование читать дальше 21.02.2022 Вакансии читать дальше 17.12.2021 Избрание директора НИИ ППМИ Ю.С. Харина академиком НАН Беларуси читать дальше 22.11.2021 Награждение сотрудников НИИ ППМИ читать дальше

OATH-парадокс | Power Security

OATH, унифицируя строгую аутентификацию и продвигая идею полной совместимости OPT-генераторов (one-time password, генераторы одноразовых паролей) и серверов аутентификации, породила парадокс: OATH-сертифицированный OTP-генератор зачастую работает только с переделённым сервером аутентификации и наоборот: OATH-сертифицированный сервер аутентификации  поддерживает только определенный перечень генератор одноразовых паролей. Как объяснить эту ситуация?

Начнем с начала. Фундаментально описывая платформу строгой аутентификации на базе одноразовых паролей необходимо упомянуть 2 базовых компонента: сервер аутентификации (или проверки, в английском Authentication или Validation) и устройство аутентификации (аутентификатор)— генератор одноразовых паролей. В обоих случаях, когда речь идет об одноразовых паролях на основе события (HOTP) или на основе времени (TOTP), оба основных компонента (сервер и генератор) должны использовать общий секрет — симметричный ключ, который задействован при расчете одного и того же одноразового пароля по тому или иному алгоритму для конкретного пользователя. Именно уникальность этого симметричного ключа, что видно при анализе обоих алгоритмов, и определяет уникальность каждого генератора. Как правило, этот параметр определяется и жестко прошивается производителем. Таким образом, возникает необходимость в транспортировке и загрузке этого секретного значения до/в сервер аутентификации (на самом деле, для каждого генератора загружается не только этот секрет, но и начальное состояние счетчика событий и некоторые другие параметры, то есть речь идет о конфиге).

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

Вот тут-то, хе-хе, и начинается самое интересное: каждый производитель использует свой собственный формат конфигурационного файла, что делает крайне затруднительным поддержку одним сервером аутентификации всех производителей генераторов.  Для решения это задачи OATH разработала RFC 6063, описывающий PSKC-формат (Portable Symmetric Key Container, перемещаемый контейнер симметричного ключа) — формат конфигурационного файла, что и обеспечит сквозную совместимость серверов аутентификации и генераторов одноразовых паролей разных вендоров (при условии правильной реализации импорта и экспорта XML-конфигов, выполненных в этом формате). По своей сути это просто контейнер, опционально зашифрованный, который содержит симметричный ключ и мета-данные.

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

Сейчас, оба компонента:  сервер аутентификации и аутентификаторы (генераторы одноразовых паролей) для прохождения сертификации должны поддерживать стандарт PSKC. Имеется в виду следующее: производитель должен предоставлять конфиги в зашифрованном PSKC-формате, а разработчик сервера аутентификации должен реализовать возможность загрузки (импорта) этого формата. Однако, что интересно, OATH-сертифицированные серверы аутентфиикации могут прекрасно работать с OATH-генераторами, которые не сертифицированы сами по себе. На самом деле, на рынке масса производителей генераторов одноразовых паролей, которые реализуют тот или иной  OATH-алгоритм (HOTP RFC 4226 – по событию, TOTP RFC 6238 – по времени), но при этом используют проприетарные форматы конфигурационных файлов. Вопрос в том, почему?

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

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

rfc-6238 · Темы GitHub · GitHub

Вот 40 публичных репозиториев соответствует этой теме…

Спомки-Лабс / otphp

Звезда 1,1к

Nextcloud / twofactor_totp

Звезда 251

Бастиан Янсен / otp-java

Звезда 120

ЛэнсДжин / jsotp

Звезда 88

МинаОТП / MinaOTP-Shell

Звезда 60

jltorrem / отпго

Звезда 56

Рейк / login_otp

Спонсор Звезда 52

Атласский / 1 раз

Звезда 34

МинаОТП / МинаОТП

Звезда 33

наим94а / отп

Звезда 23

ЛэнсДжин / точка

Звезда 19

алгоритмическое пространство / криптой

Звезда 12

Йонфризен / отп

Звезда 10

Греймич / php-totp

Звезда 10

педросансао / php-otp

Звезда 10

ксаренард / простойотп

Звезда 9

ксандкар / эрланг-totp

Звезда 6

00-матовый / минитотп

Звезда 6

экамвалия / высший

Звезда 6

Робино / тотп-кт

Звезда 6

Улучшить эту страницу

Добавьте описание, изображение и ссылки на rfc-6238 страницу темы, чтобы разработчикам было легче узнать о ней.

Курировать эту тему

Добавьте эту тему в свой репозиторий

Чтобы связать ваш репозиторий с rfc-6238 тему, перейдите на целевую страницу репозитория и выберите «управление темами».

Узнать больше

Объяснение алгоритма TOTP — Protectimus Solutions

Опубликовано Максимом Олейником, 24 июня 2020 г. | 2 комментария

Алгоритм одноразового пароля на основе времени (TOTP) находится в центре внимания этого поста. Но прежде чем мы углубимся в смысл TOTP, мы хотели бы упомянуть организацию, которая способствует существованию алгоритмов одноразовых паролей — OATH или Open AuTHentication. OATH — это результат сотрудничества самых разных специалистов, которые поставили перед собой задачу создать по-настоящему безопасную и универсальную сеть для всех. Мы в Protectimus гордимся тем, что являемся частью этих совместных усилий.

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

Заказать программируемые и классические токены TOTP можно здесь

Содержание:

• Что такое TOTP
• Фон TOTP — HOTP
• TOTP vs HOTP
• Проблема синхронизации TOTP
• Токены TOTP Protectimus

Что такое алгоритм TOTP

Мы уже ответили на вопрос «что означает TOTP?» вопрос выше. Но что такое TOTP-аутентификация? Несложный ответ — это метод двухфакторной проверки, который использует время в качестве переменной. Давайте немного расширим это и разберем, как на самом деле работает аутентификация TOTP.

Алгоритм TOTP (RFC 6238) подразумевает, что OTP является произведением двух параметров, зашифрованных вместе. Это общее значение, которое является общим секретным ключом или начальным числом; и переменная, в данном случае – время работы. Эти параметры зашифрованы с помощью хеш-функции.

Вот пример алгоритма TOTP для иллюстрации:

1. Пользователь хочет войти в защищенное приложение или веб-сайт TOTP 2FA. Для запуска OTP-аутентификации пользователю и TOTP-серверу необходимо изначально совместно использовать статический параметр (секретный ключ).
2. Когда клиент входит на защищенный веб-сайт, он должен подтвердить, что владеет секретным ключом. Таким образом, их токен TOTP объединяет начальное значение и текущий временной шаг и генерирует значение HASH, запуская предопределенную функцию HASH. По сути, это значение является кодом одноразового пароля, который пользователь видит на токене.
3. Поскольку секретный ключ, функция HASH и временной шаг одинаковы для обеих сторон, сервер выполняет те же вычисления, что и генератор OTP пользователя.
4. Пользователь вводит OTP, и если он совпадает со значением сервера, доступ предоставляется. Если результаты вычислений не совпадают, доступ, естественно, запрещается.

Чтобы немного пояснить приведенный выше пример, отметим, что упомянутое начальное число представляет собой строку случайных символов, обычно длиной 16–32 символа. «Совместное использование» ключа обычно подразумевает сканирование QR-кода, который показывает семя, сгенерированное сервером, с приложением TOTP клиента. Кроме того, ключ уже запрограммирован в их TOTP-устройстве. Временной шаг рассчитывается с использованием времени UNIX, которое начинается 1 января 19 года.70, Всемирное координированное время. Временные шаги должны составлять 30 или 60 секунд, поэтому значение времени, используемое для TOTP, представляет собой количество секунд, прошедших с 00:00 1 января 1970 года, деленное на 30 или 60. Наконец, упомянутая функция HASH является криптографической математической функцией. который просто меняет одно значение на другое и обычно сокращает результат до 6-8 символов. Этот результат мы назвали значением HASH выше.

Все это указано в TOTP RFC.

Предыстория алгоритма TOTP — HOTP

OATH активно работает над безопасным 2FA с 2004 года. Первый алгоритм, созданный организацией, — это HOTP — одноразовый пароль на основе HMAC, представленный в 2005 году. Этот метод использует счетчик как переменная и начальное значение в качестве общего значения для создания одноразового пароля.

Создание одноразового пароля является событием для счетчика в HOTP, поэтому каждый новый пароль увеличивает счетчик на 1. Этот алгоритм мы подробно описали в этой статье.

Метод на основе счетчика имеет ряд недостатков, их мы коснемся далее. Поэтому в 2008 году OATH представила TOTP как расширение родительского алгоритма, следующий шаг эволюции MFA.

| Читайте также: Объяснение алгоритма OCRA

TOTP против HOTP

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

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

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

В битве между HOTP и TOTP защита TOTP определенно выиграет. Срок действия TOTP-паролей ограничен. Если пароль, предоставленный генератором TOTP RFC6238, не используется в течение 30, а иногда и 60 секунд, срок его действия просто истекает, и его нельзя использовать для входа в систему. Таким образом, запись одноразовых паролей не принесет хакеру никакой пользы. Кнопку токена можно нажимать столько раз, сколько душе угодно, это не нарушит синхронизацию токена и сервера.

У токенов TOTP есть своя проблема — временной дрейф. Но мы уже решили это в программируемых токенах Protectimus Slim NFC. Давайте поговорим об этом дальше.

| Читайте также: Недостатки безопасности 2FA, о которых вы должны знать

Проблема синхронизации TOTP

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

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

У нас есть очень подробная запись в блоге об этой проблеме и о том, как нам удалось ее решить. Поэтому не будем вдаваться в подробности и скажем лишь, что с мая 2019 г.В устройствах Protectimus Slim NFC исправлена ​​проблема с синхронизацией.

| Читайте также: Токены TOTP Protectimus Slim NFC: FAQ

Токены Protectimus TOTP

Алгоритм OTP на основе времени — широко применяемое решение MFA, есть даже режим TOTP Google Authenticator. Protectimus может предложить вам три токена, разработанных в соответствии со спецификацией OTP RFC на основе времени.

Жетон	Описание
Protectimus Slim NFC	Токен-карта TOTP. Новый секретный ключ можно перепрограммировать сколько угодно раз. Это означает, что вы можете повторно использовать токен после прекращения его использования для одного веб-сайта. Более безопасная замена приложениям 2FA, таким как аутентификатор Google TOTP. Включена функция синхронизации времени. Водонепроницаемый. Срок службы батареи от 3 до 5 лет. $29,99 за токен Гарантия 12 месяцев.
Protectimus ДВА	Жетон-брелок. Может использоваться для входа на веб-сайт или в приложение, только если вы можете добавить его начальное значение на стороне сервера, поскольку начальное число жестко запрограммировано. Противоударный. Водонепроницаемый. Срок службы батареи от 3 до 5 лет. 11,99 за жетон Гарантия 12 месяцев.
Protectimus SMART OTP	Приложение генератора кодов. Добавить комментарий Отменить ответ Ваш адрес email не будет опубликован. Обязательные поля помечены * Комментарий * Имя * Email * Сайт