2FA без Google: как работать с Proton и другими сервисами

FLOSS 2FA-приложения генерируют коды локально и не требуют доверия Google или Microsoft.

2026-06-06 GIGATAP Team #tools
#2FA#F-Droid#TOTP

2FA без Google: как работать с Proton и другими сервисами

Пользователь форума F-Droid задал простой, но важный вопрос: если рабочий вход использует аккаунт Google и второе устройство для подтверждения, как бесплатное открытое 2FA-приложение может работать с Proton или другими сервисами без участия Google, Microsoft или других крупных платформ?

Краткий ответ: многие 2FA-приложения вообще не выступают как доверенный сервис. Они просто вычисляют одноразовые коды на основе секрета, который уже разделён между сервисом и приложением.

Это различие критично. Оно определяет, чему вы доверяете, что может сломаться и что нужно резервировать.

Что известно из источника#

Пост на форуме не является отчётом о уязвимости. Это попытка пользователя понять модель доверия 2FA, особенно в экосистеме F-Droid.

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

Он интересуется, как FLOSS 2FA-приложения работают без Google, Microsoft или других крупных провайдеров. Упоминает собственное 2FA-приложение Proton из F-Droid, но ищет решение, подходящее для нескольких сервисов. Не все 2FA одинаковы: одни используют удалённого провайдера, другие генерируют коды локально, третьи — криптографическое оборудование или passkeys. Все их называют «2FA», но модель доверия разная.

Общий случай: TOTP локальный#

Большинство универсальных аутентификаторов используют TOTP — одноразовые коды на основе времени. Это шестизначные коды, знакомые по Google Authenticator, Aegis, FreeOTP и аналогам.

При настройке TOTP сервис выдаёт секрет (обычно QR-код). Приложение сохраняет его. При входе код вычисляется из секрета и текущего времени. Сервис делает то же самое. Если числа совпадают в допустимом окне, вход разрешён.

Google или Microsoft не нужны для этого расчёта. Приложение не обращается к центральной службе за проверкой. Оно не требует доверия со стороны Proton или других сервисов как федеративный провайдер.

Сервис доверяет коду, потому что он доказывает владение секретом.

Поэтому универсальный аутентификатор работает с разными сервисами. Приложение реализует стандарт, сервису достаточно поддерживать TOTP.

Доверие к приложению#

Приложение важно: доверие локальное и узкое.

TOTP-приложение должно безопасно хранить секрет, показывать правильный код и не раскрывать секрет. Если приложение вредоносное, скомпрометированное или бэкап ненадёжен, второй фактор ослабевает. Потеря телефона без бэкапа может заблокировать пользователя.

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

Ключевые свойства хорошего аутентификатора:

  • локальное зашифрованное хранение секретов
  • понятный экспорт и бэкап
  • отсутствие лишней сетевой зависимости
  • активное сопровождение
  • понятное поведение восстановления
  • поддержка нужных сервисов

Лучший вариант не всегда сервис-специфичный. Универсальный аутентификатор сокращает количество приложений и работает с Proton, Git, менеджерами паролей, облачными аккаунтами. Риск: одно приложение становится высокоценным хранилищем, поэтому бэкап и безопасность устройства критичны.

Push-утверждение и TOTP — разные модели#

Пример рабочего места ближе к платформо-зависимому push-потоку: устройство получает запрос, PIN или одобрение. Провайдер проверяет сессию, привязку к устройству и инфраструктуру push.

Это удобно, но создаёт зависимость: если провайдер, аккаунт, push-канал или поток сломаются, вход невозможен.

TOTP проще. После настройки работает оффлайн: приложению нужен только секрет и время. Сервер и приложение не связываются напрямую. Код доказывает, что обе стороны знают секрет.

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

Чего не стоит утверждать#

Неверно делать вывод, что одно Proton-приложение, одно F-Droid-приложение или один метод 2FA полностью безопасны или опасны. Источник не содержит аудита, отчёта инцидента или сравнительной таблицы.

FLOSS не снимает все вопросы доверия. Open source помогает проверять код и воспроизводимость, но не отменяет необходимость безопасного хранения, правильных настроек, сопровождения и планирования восстановления.

Практический вывод: FLOSS-аутентификатор работает с разными сервисами, потому что TOTP — стандартный механизм с общим секретом, а не из-за доверия Google, Microsoft, Proton или другим.

Что проверить#

  • Проверьте, какие типы второго фактора поддерживает ваш аккаунт (TOTP, ключи безопасности, passkeys, коды восстановления, бэкап).
  • Настройте TOTP в поддерживаемом приложении с локальным шифрованием.
  • Храните коды восстановления отдельно от телефона.
  • Протестируйте восстановление доступа до того, как полностью полагаетесь на 2FA.
  • Не оставляйте единственный экземпляр секретов на одном устройстве без бэкапа.
  • Для высокорискованных аккаунтов рассмотрите ключи безопасности или passkeys для защиты от фишинга.

Чистая модель доверия:

  • Только пароль: доказывает знание пароля.
  • TOTP: знание пароля и владение секретом.
  • Push-одобрение: доступ к зарегистрированному устройству или поток через провайдера.
  • Ключи безопасности и passkeys: повышают защиту от фишинга при правильной реализации.

Главное: 2FA-приложение из F-Droid не требует благословления крупной платформы для генерации действительных кодов. Секрет разделён, приложение вычисляет, сервис проверяет. Сложность — хранение секрета, организация восстановления и выбор правильного второго фактора.