Просмотр исходного текста страницы TOTP (Time-based One-Time Password Algorithm)

[[Файл:345artem.jpg|мини|TOTP]]
'''TOTP ({{lang-en|Time-based One-Time Password Algorithm}})''' -  алгоритм создания одноразовых паролей для защищенной аутентификации. Является алгоритмом односторонней аутентификации — сервер удостоверяется в подлинности клиента. 

OATH c 2004 трудилась над созданием проектов одноразовых паролей  и первым результатом был НОТР (the Hash-based Message Authentication Code (HMAC) OTP algorithm). HOTP был представлен как проект IETF (The Internet Engineering Task Force).

Последующая работа OATH шла на улучшение НОТР и в 2008 году был представлен ТОТР.  Главное отличие заключается в том , что в ТОТР генерация пароля происходит на основе времени, то есть время является параметром. При этом обычно используется не точное указание времени, а текущий интервал с установленными заранее границами (например, 30 секунд). 

Алгоритм не использует счётчик для синхронизации клиента и сервера, а генерирует пароль в зависимости от времени, который действителен в течение некоторого интервала.<ref group="Источник"> Time-based One-Time Password Algorithm // Search Security. URL: https://searchsecurity.techtarget.com/definition/time-based-one-time-password-TOTP (Дата обращения: 16.05.2017).</ref>


== История создания ==

Алгоритм TOTP был разработан в сотрудничестве с несколькими членами OATH, чтобы создать стандарт, поддерживаемый промышленностью. Алгоритм дополняет одноразовый стандарт [[HOTP]] на основе событий и предлагает организациям и предприятиям конечных пользователей больше выбора в выборе технологий, которые наилучшим образом соответствуют их требованиям к приложениям и рекомендациям по безопасности. В 2008 году OATH представила проект спецификации спецификации IETF. Эта версия содержит все отзывы и комментарии, которые авторы получили от технического сообщества на основе предыдущих версий, представленных в IETF. В мае 2011 года '''TOTP''' официально стал стандартом '''RFC 6238'''

== Принцип работы ==

Алгоритм действует следующим образом: клиент берет текущее значение таймера и секретный ключ, хеширует их с помощью какой-либо хеш-функции и отправляет серверу, в свою очередь сервер проводит те же вычисления после чего ему остается только сравнить эти значения. Он может быть реализован не только на хеш-функции SHA-1(Secure Hash Algorithm 1 — алгоритм криптографического хеширования) в отличии от HOTP, поэтому хеш-функция также является входным параметром.

Позднее был представлен новый алгоритм,который  расширил TOTP ещё больше. Он был представлен в  2010 году и назван [[OATH]] -  Challenge-Response Algorithms (OCRA). Основным  отличием от предыдущих алгоритмов является то, что в проверке подлинности участвует и сервер. Поэтому клиент может быть также уверен в его подлинности.

Согласно стандарту RFC 6238, эталонная реализация выглядит следующим образом:

* Создайте ключ, '''K''', который является произвольной байтовой строкой, и надежно передайте его клиенту.
* Согласитесь на '''T0''' (время Unix) чтобы начать подсчет временных шагов и интервал ('''T1'''), который будет использоваться для вычисления значения счетчика - C (значения по умолчанию - это время [[UNIX]] как T0 и 30 секунд как T1)
* Согласовать криптографический хэш-метод (по умолчанию SHA-1)
* Согласитесь на длину токена, N (по умолчанию - 6)

Хотя RFC 6238 позволяет использовать разные параметры, реализация приложения аутентификатора Google не поддерживает значения '''T0''', '''T1''', хэш-методы и длины токенов, отличные от значения по умолчанию. Он также ожидает, что секретный ключ '''K''' будет введен (или поставлен в QR-коде) в кодировке base-32 согласно RFC 3548.

* Как только параметры согласованы, генерация токена выглядит следующим образом:

* Вычислите '''C''' как количество раз, когда '''T1''' истекло после '''T0'''.

* Вычислить HMAC хэш '''H''' с '''C''' в качестве сообщения и '''K''' как ключ (алгоритм HMAC определен в предыдущем разделе, но и большинство криптографических библиотек поддерживают его). '''K''' должен быть передан как есть, '''C''' должен быть передан как необработанное 64-разрядное целое число без знака.

* Возьмите минимум 4 значащих бит '''H''' и используйте его как смещение, О.

* Возьмите 4 байта из '''H''', начиная с байтов '''O''' байтов MSB, отбросьте самый старший бит и сохраните остальные как 32-битное целое число (без знака), '''I'''.
Знак - это младшие '''N''' цифр '''I''' в базе 10. Если результат меньше, чем '''N''', поместите его нулями слева.

И сервер, и клиент вычисляют токен, затем сервер проверяет, соответствует ли токен, предоставленный клиентом локально созданному токену. Некоторые серверы позволяют кодам, которые должны были быть созданы до или после текущего времени, чтобы учесть незначительные перекосы часов, задержку сети и задержки пользователей. <ref group="Источник"> Time-based One-Time Password Algorithm // Patent. URL: https://tools.ietf.org/html/rfc6238 (Дата обращения: 16.05.2017).</ref>

==Реализация в прjектах==

* Компания [[Google Inc.|Google]] реализовала версию TOTP в Google Authenticator;

* [[AWS (Amazon Web Services)|AWS]] также поддерживает TOTP для входа AWS-консоль ;

* Dropbox использовала TOTP для доступа к серверу;

* LastPass поддерживает TOTP использованием [[Google Inc.|Google]] Authenticator;

* Библиотека Liboath для создания как TOTP, так и HOTP паролей.

== Надежность ==

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

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

Также существует уязвимость связанная с синхронизацией таймеров сервера и клиента, так как существует риск рассинхронизации информации о времени на сервере и в программном и/или аппаратном обеспечении пользователя. Поскольку TOTP использует в качестве параметра время, то при не совпадении значений все попытки пользователя на аутентификацию завершатся неудачей. В этом случаи ложный допуск чужого также будет невозможен. Стоит отметить что вероятность такой ситуации крайне мала.<ref group="Источник">Time-based One-Time Password Algorithm // Wikipedia. URL: https://en.wikipedia.org/wiki/Time-based_One-time_Password_algorithm (Дата обращения: 16.05.2017).</ref>
== Источники ==
{{reflist|group=Источник}}