Есть ли замена Google Authenticator?

Многие онлайн-сервисы позволяют — а иногда даже требуют — настроить двухфакторную аутентификацию с помощью одноразовых кодов. Среди пользователей самым известным и распространенным приложением-аутентификатором, генерирующим эти самые коды, стал Google Authenticator. Почти все сервисы совместимы с ним, а некоторые и вовсе дают ссылку на приложение при настройке двухфакторной аутентификации. Но обязательно ли пользоваться именно аутентификатором Google или можно предпочесть ему одну из многочисленных альтернатив вроде Microsoft Authenticator или Twilio Authy?

Раз эти альтернативные аутентификаторы существуют и имеют какую-то аудиторию, логично предположить, что они вполне могут быть полноценной заменой Google Authenticator. Но нет ли тут каких-нибудь подводных камней? Для тех, кому некогда читать, могу сразу ответить на этот вопрос: можете не переживать, никаких камней, и даже дно не илистое — чистый песочек. Ну а если интересно разобраться, что, почему да как — читайте дальше.

Как работают аутентификаторы

Начнем с того, как вообще работают приложения-аутентификаторы. Несколько открытых стандартов надежной аутентификации были созданы так называемой «Инициативой за открытую аутентификацию» (Initiative for Open Authentication, OATH), объединяющей несколько десятков организаций по всему миру. Именно эти стандарты и лежат в основе приложений-аутентификаторов (на самом деле не только их, но не будем отходить слишком далеко от темы поста).

Стандарт аутентификации OATH HOTP

Еще в далеком 2005 году появился стандарт OATH HOTP (HMAC-based one-time password, одноразовый пароль на основе хеш-функции). В нем и были заложены базовые принципы работы аутентификации с помощью одноразовых кодов, которые синхронно генерируются на стороне клиента и сервера.

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

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

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

Стандарт аутентификации OATH TOTP

В 2011 году был представлен новый стандарт — OATH TOTP (Time-based one-time password, одноразовый пароль на основе времени), в котором в качестве счетчика используется текущее время. Принцип работы остается тем же самым — все так же используется секретный ключ, известный обеим сторонам, на основе которого вычисляется одноразовый код с помощью того же самого криптоалгоритма. А поскольку счетчик основан на Unix-времени, то через равные промежутки времени код автоматически меняется, вне зависимости от того, был он использован или нет.

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

Основные принципы работы аутентификаторов

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

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

Что содержит QR-код для подключения аутентификатора

Если я не ошибаюсь, эта часть не входит в число разработанных OATH стандартов, а является скорее добровольным следованием формату, заданному Google Authenticator. Но так или иначе системы аутентификации на основе приложения, как правило, оперируют QR-кодами, в которых закодирована ссылка (строго говоря, URI — Uniform Resource Identifier), содержащая всю необходимую информацию. Ссылка эта выглядит, например, вот так:

otpauth://totp/Google:alanna@gmail.com?secret=IN2XE2LPOVZSYIDBOJSW4J3UEB4W65J7&issuer=Google&algorithm=SHA1&digits=6&period=30

Как видите, в QR-коде передается целая куча параметров, указывающих на:

• то, что данный URI служит для создания аутентификационного токена — об этом говорит otpauth в самом начале;
• стандарт аутентификатора, HOTP или TOTP — в данном случае это TOTP;
• название токена, которое будет отображаться внутри приложения, в нашем примере — Google;
• имя пользователя — в данном случае alanna@gmail.com;
• секретный ключ, на основе которого генерируются коды (в формате Base32), — самая важная часть, длинная строка случайных символов;
• имя сервиса, создавшего данный URI, — в нашем примере это опять Google;
• алгоритм, используемый для генерации кодов, в данном случае — SHA1;
• количество символов в генерируемых кодах — обычно их 6, как и в нашем случае, но допустимы и другие варианты;
• период времени, через который у кода «истекает срок годности», — опять же, обычно это 30 секунд, но можно выбирать и другие промежутки времени.

А вот так выглядит соответствующий QR-код:

В QR-коде можно передать целую кучу параметров аутентификационного токена

На самом деле многие из этих параметров, как мы уже писали выше, могут быть опущены. Во-первых, название токена и имя пользователя могут быть произвольными, а имя сервиса указывать вообще не обязательно — вся эта информация никак не влияет на генерацию кода и нужна скорее для удобства. Во-вторых, некоторые параметры вообще не обязательно указывать. Аутентификатор будет использовать дефолтный алгоритм генерации кодов (по умолчанию это SHA1) и создавать код в 6 цифр длиной с периодом обновления 30 секунд, если в URI не закодировано иное.

По сути, сервису и аутентификатору нужно договориться только о том, какой используется стандарт (HOTP или TOTP), и передать секретный ключ. Поэтому следующие URI и QR-код дадут на выходе точно такой же с функциональной точки зрения аутентификационный токен, как и предыдущая пара:

otpauth://totp/Whenever:Wherever?secret=IN2XE2LPOVZSYIDBOJSW4J3UEB4W65J7

Можно опустить существенную часть параметров в QR-коде или указать произвольные значения. Что действительно важно — это передать секретный ключ и договориться о стандарте (HOTP или TOTP)

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

Некоторые исключения: сервисы, которые несовместимы с обычными аутентификаторами

По совершенно непонятной мне причине далеко не все в IT-индустрии следуют описанным выше стандартам: некоторые придумывают вместо них что-то свое. Приведу несколько примеров компаний, сервисы и программы которых несовместимы с приложениями-аутентификаторами (всеми сразу, включая Google Authenticator).

• Apple. У ребят из Купертино полностью своя система двухфакторной аутентификации, которая вообще не использует каких-то внешних приложений. Вместо этого одноразовые коды генерируются операционной системой, причем одновременно на всех устройствах, привязанных к Apple ID. Могут себе позволить!
• Valve и Blizzard. Для двухфакторной аутентификации в Steam и Battle.net игроделы предлагают использовать их собственные разработки — Steam Guard (встроен в приложения Steam для Android и iOS) и Battle.net Authenticator соответственно. Насколько мне известно, существует только одно стороннее приложение-аутентификатор, которое поддерживает эти системы — WinAuth.
• Microsoft. Для аутентификации в аккаунте Microsoft придется устанавливать Microsoft Authenticator — но зато при его использовании не требуется вводить никаких кодов, достаточно просто подтвердить вход нажатием кнопки в приложении. Отмечу, что в качестве бонуса Microsoft Authenticator генерирует и стандартные аутентификационные токены, что делает его неплохой альтернативой Google Authenticator. Учeтка Microsoft для этого, кстати, вообще не требуется.
• Adobe. Разработчик графического софта также использует собственное приложение Adobe Account Access, которое по логике работы похоже на Microsoft Authenticator: вход в учетную запись Adobe подтверждается кнопкой, а не кодом. В теории приложение поддерживает и создание токенов для аутентификации в сторонних сервисах. Однако, чтобы Adobe Account Access работал, пользователь должен сначала привязать приложение к своей учетной записи Adobe — чего, если верить отзывам в App Store и Google Play, лучше не делать.

Так обязательно ли пользоваться Google Authenticator?

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

Кстати, у нас есть пост, в котором мы перечислили самые интересные аутентификаторы для каждой из актуальных операционных систем — Android, iOS, Windows и macOS. Если вы прочитали этот текст целиком, то что-то мне подсказывает, вас могут заинтересовать andOTP, если вы пользуетесь Android, и OTP auth, если вы предпочитаете iOS.