Авторский проект IT-специалиста Олега Барабанова Персональные публикации на тему IT и не только…
  1. Главная
  2. Проектирование
  3. Использование TOTP для 2FA в GitHub и не только

Использование TOTP для 2FA в GitHub и не только

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

В настоящее время GitHub допускает для 2FA использование нескольких способов на выбор:

Хотя дальше в статье и пойдет речь конкретно про TOTP, остальные вышеперечисленные способы вполне можно использовать в дополнение к TOTP, для повышения безопасности аккаунта. В таком случае это уже будет не двухфакторная (2FA), а многофакторная авторизация (MFA).

Что такое TOTP

TOTP (Time-based One-Time Password) — это метод реализации 2FA с помощью временных одноразовых паролей. В упрощенном варианте, логику алгоритма можно описать так:

  1. На сервере формируется следующая информация (большая часть из которой - опциональна):
    • название сервиса
    • название клиентского аккаунта
    • сгенерированный уникальный секретный ключ
    • период между генерацией нового пароля (фактически срок действия пароля) - по умолчанию 30 секунд, но может быть и любое другое значение.
    • длина генерируемого одноразового ключа - 6 или 8 символов (по умолчанию 6)
    • используемый алгоритм хеширования - допустимы SHA224, SHA256, SHA384, SHA512 (по умолчанию SHA-1).
  2. Вся эта сгенерированная вышеописанная информация передается в виде QR-кода клиентскому приложению-аутентификатору.
  3. В дальнейшем, при авторизации, пользователь с помощью приложения-аутентификатора, генерирует актуальный на данный период времени 6 или 8-значный цифровой пароль и передает его на сервер. Приложение при этом может информировать пользователя об оставшемся времени действия пароля. Если полученный пароль действителен пару секунд, тогда лучше дождаться начала следующего периода, при котором будет уже новый пароль и уже его передавать на сервер.
  4. На сервере также генерируется актуальный на данный период времени пароль и сравнивается с тем, какой пароль передал пользователь и в случае их совпадения, авторизация считается успешной.

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

Зачем этот TOTP нужен, особенно в случае GitHub?

В первую очередь TOTP, как и любой другой метод 2FA, нацелен на повышение безопасности аккаунтов разработчиков, что в свою очередь в определенной степени влияет на защиту от атак вида SSC (Supply chain attack). Это особенно актуально при использовании NPM с его бездонным node_modules, где каждый модуль при любом обновлении может стать зловредным, особенно с учетом того, что зловред может запуститься просто при установке NPM-пакета. В общем SSC является достаточной серьезной проблемой в современной разработке.

Например представим что вы пишите какой-то свой супер проект. Естественно вы используете всякие библиотеки, которые в свою очередь используют какие-то свои библиотеки. В общем тут полноценный граф зависимостей. И у разработчика какой-то из этих библиотек, злобные программисты тихо и незаметно угнали аккаунт и под именем этого разработчика закоммитили какую-то зловредную бяку (а сам разработчик в это время где-то тусит на пляже с текилой и даже не подозревает о происходящем). И ладно если это в виде собранных библиотек еще не успеет распространиться, а вот если там запустится какой-нить CI/CD с автоматической сборкой проекта и дистрибуцией? При этом у вашего проекта при его очередной установке (обновлении) скачается обновленная версия используемой библиотеки, которая по факту уже скомпрометирована. В итоге заложенная злобная бяка в любой момент может что-то сделать с вашим проектом или банально украсть какие-то конфиденциальные данные. В общем ничего хорошего не произойдет.

Конечно TOTP в полной мере не решает эту проблему. Но давайте посмотрим начистоту - GitHub безусловный лидер в своей сфере и там размещены репозитории большинства проектов. И каждый из этих репозиториев может быть скомпрометирован при угоне аккаунта сопровождающего его мейнтейнера. Поэтому в случае GitHub неудивительно, что они решили более настойчиво вводить 2FA, ибо это хоть ненамного, но повысит общую безопасность современной разработки. А разве это плохо? Ну и просто хорошо, что хотя бы не сделали жесткий вендорлок в виде привязки к тому же GitHub Mobile, а дали возможность использовать независимые от GitHub аутентификаторы.

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

Заключение

Честно говоря, ранее я не работал с TOTP, т.к. не было особой необходимости и для меня. Но все меняется со временем и поэтому учиться нужно постоянно. Вот и я вынужденно ознакомился с TOTP и по итогу мне такой метод 2FA понравился.

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

↑ ↓