не входите через google (the smart ape, 2026)

Тред в X от the-smart-ape (the_smart_ape) о том, что происходит, когда аккаунт Google исчезает за одну ночь, почему тезис "вход через Google безопаснее паролей" ошибочен и в каких случаях SSO всё же допустим. Архитектурный аргумент: клик по кнопке "Sign in with Google" - это не создание аккаунта, а указание приложению "Google за меня поручится". Когда Google перестаёт ручаться, все зависимые сервисы перестают работать в то же мгновение. Пример каскадной потери сервисов задаёт масштаб проблемы; архитектурные аргументы и анализ поверхности атак обосновывают итоговые рекомендации.

Трёхлетний SaaS приятеля

Основатель получает одно письмо: "ваш аккаунт заблокирован за нарушение наших правил". Ни номера обращения, ни живого человека, ни возможности подать апелляцию. Восемь лет истории в Gmail - пропали. Drive, YouTube, покупки в Play Store - пропали. Сам трёхлетний SaaS - тоже пропал, потому что основатель завязал все рабочие инструменты на вход через Google:

• Notion - три года спецификаций продукта, заметок о клиентах, контрактов и финансовых прогнозов.
• Figma - дизайн-система, материалы бренда, все макеты.
• Linear - дорожная карта, все баги, все обращения клиентов.
• Vercel - продакшен-развёртывание, привязанное к аккаунту GitHub, чей резервный адрес для восстановления вёл на заблокированный Gmail. Он видит, что сайт работает, но не может ничего изменить.
• Stripe - авторизация в панели управления шла через Google. Он не может сделать возврат, не может даже посмотреть собственный MRR.

Он до сих пор не знает, в чём провинился. Google так и не объяснил.

Главный тезис треда: нет ни договора, ни SLA, ни суда. Есть форма, форму читает модель, модель отвечает отказом.

Известный прецедент

Эндрю Спинкс (Andrew Spinks), разработчик Terraria, потерял свой аккаунт в январе 2021 года. 15 лет на Gmail, никаких объяснений. Доступ удалось вернуть, но только после публичной отмены порта игры для Stadia и огласки в медиа. Стандартная процедура апелляции не дала ничего. Подразумеваемый вывод: это правило, а не исключение; процесс апелляции не рассчитан на работу с частными лицами без медийного веса.

Архитектурный аргумент

Тезис "SSO безопаснее паролей" сравнивает лишь половину картины (сам пароль) с целой системой (менеджер паролей + уникальный псевдоним почты на каждый сервис + аппаратный ключ 2FA). При правильной настройке второй вариант выигрывает по всем параметрам, кроме удобства. SSO меняет распределённый риск на концентрированный: статистически ожидаемый ущерб одинаков, но эмоционально и операционно разница огромна - потерять 1/20 стека неприятно, потерять 20/20 означает закрытие бизнеса. См. концепцию sso-concentration-risk.

Захват домена через уязвимость от Truffle Security (январь 2025)

Стартап закрывается. Его домен попадает в открытую продажу. Кто-то покупает его за $12, разворачивает Google Workspace на том же домене и воссоздаёт адреса alice@deadstartup, bob@deadstartup. Затем злоумышленник заходит в Slack, Notion, Zoom и ChatGPT умершей компании, просто нажимая "Sign in with Google" - ведь SaaS-приложения проверяют лишь адрес почты и подтверждение домена от Google, а они не изменились.

Первой реакцией Google было закрыть отчёт со статусом "won't fix", классифицировав проблему как мошенничество и злоупотребление (fraud-and-abuse), а не как баг в OAuth. Расследование возобновили только после того, как доклад исследователей приняли на Shmoocon, а история разошлась по сети. Итоговое вознаграждение составило $1337. Оценка автора треда: мемная сумма за уязвимость масштаба всей индустрии говорит об архитектурных приоритетах команды. См. google-oauth-domain-takeover.

Векторы атак после сброса пароля

Убеждение "у меня включена 2FA, со мной всё в порядке" ошибочно, поскольку современный класс атак вообще не затрагивает процесс ввода пароля.

Повторное использование refresh-токенов через multilogin. В конце 2023 года исследователи обнаружили недокументированный эндпоинт Google OAuth под названием multilogin, который по refresh-токену генерирует свежие сессионные cookie. К 2024 году его взяли на вооружение более десяти семейств вредоносного ПО (Lumma, Rhadamanthys и другие). Они крадут refresh-токен из Chrome, обновляют cookie и сохраняют сессию активной после того, как жертва сбросила пароль. Единственное реальное решение - вручную отозвать все активные сессии и все сторонние OAuth-разрешения на странице безопасности Google. Почти никто этого не делает, потому что пользователи просто не знают о такой необходимости.

Фишинг согласий (consent phishing). Злоумышленник даже не пытается войти под вашей учётной записью. Он показывает настоящий экран согласия Google - легитимный домен google.com, валидный сертификат, ваш аккаунт уже авторизован - и просит выдать своему вредоносному приложению разрешение вроде "читать вашу почту" или "управлять вашим диском". Вы нажимаете "Разрешить". Теперь у атакующего есть подписанный Google токен с этими правами, действующий месяцами. Пароль не помог. 2FA не помогла. От вас не требовалось аутентифицироваться - вас попросили авторизовать доступ. Это совершенно другой механизм.

Статистика индустрии из треда. Кража токенов составила 31% всех взломов Microsoft 365 в 2025 году. В марте 2025 года атакующие адаптировали фишинг через device-code под Google. В августе 2025 года в результате утечки у Salesloft/Drift были массово скомпрометированы токены OAuth для интеграций с Salesforce и Google Workspace. См. oauth-token-theft.

Кнопка как трекер

Кнопка "Sign in with Google" - это не картинка, а скрипт, загружаемый с серверов Google. Любая страница с такой кнопкой исполняет код Google, поэтому Google видит факт загрузки страницы, referrer, user-agent, а если в соседней вкладке выполнен вход в аккаунт, то и то, кто именно зашёл на сайт. Кликать по кнопке необязательно: достаточно просто открыть страницу.

Контраст с Apple

"Sign in with Apple" решает другую (и дополнительную) задачу с помощью функции Hide My Email: каждое приложение получает уникальный адрес-псевдоним с пересылкой. У Google нет аналогов. Ваш реальный, основной адрес почты передаётся каждому приложению навсегда, а этот основной адрес - мастер-ключ ко всем процедурам сброса паролей, которые вам когда-либо понадобятся.

Практическое правило

Не "никогда не используйте SSO", а "если потеря доступа к сервису на 30 дней нанесёт ущерб вашей работе или деньгам, не используйте SSO". Сортируйте сервисы по ущербу при восстановлении, а не по удобству кнопки входа. Практические шаги, которыми завершается тред:

• Аудит. Откройте myaccount.google.com/connections и отзовите всё незнакомое или неиспользуемое дольше шести месяцев.
• Разделение. Всё, что связано с деньгами или работой (Stripe, регистратор доменов, облачный провайдер, бухгалтерия, Slack), получает отдельный аккаунт, отдельный пароль и отдельную 2FA. Никакого Google.
• Псевдонимы. Перестаньте отдавать реальную почту каждому приложению. Proton, Fastmail, SimpleLogin и релей от Apple умеют генерировать уникальные псевдонимы для каждого сервиса. Скомпрометированный адрес можно просто отключить.
• Разрыв цепочки восстановления. Ни один резервный адрес для восстановления (в менеджере паролей, облаке или у регистратора доменов) не должен указывать на Gmail. Внезапная потеря Gmail не должна лишать доступа ко всему остальному.
• Премортем. Подумайте десять минут: если ваш аккаунт Google исчезнет сегодня ночью, что именно вы потеряете?

Связанные страницы

• sso-concentration-risk - зонтичная концепция: обмен распределённого риска на концентрированный.
• google-oauth-domain-takeover - уязвимость, обнаруженная Truffle Security.
• oauth-token-theft - multilogin и consent phishing как векторы атак.
• bitwarden / marius-bitwarden-not-recommended - смежные практические рекомендации по менеджерам паролей.
• long-lived-keys - refresh-токены как долгоживущие учётные данные, отзыв которых большинство пользователей никогда не производит.
• supply-chain-security - смежный класс рисков из категории "платформа, от которой вы зависите, может подвести".
• the-smart-ape - сущность автора.

Сохранено 2026-05-19 из smart-ape-dont-sign-in-with-google.