Hacker News Digest

Passkeys и современная аутентификация
Armin Ronacher, 2 сентября 2025

Индустрия стремится отказаться от паролей в пользу passkeys (WebAuthn). Это в целом полезно для обычных пользователей, но стандарт содержит подводные камни.

Аттестации

Аттестация позволяет сайту узнать, какое именно устройство используется: аппаратный ключ или программный менеджер. Австрийское правительство, например, запрещает вход в налоговую и медицинские сервисы без аппаратного токена из «белого списка». Apple и Google не передают аттестацию в своих потребительских решениях, но делают это для корпоративных MDM. Такой механизм уже используется для ограничения выбора устройств.

Блокировка в экосистеме

Нет способа экспортировать приватные ключи между менеджерами паролей. Приходится регистрировать каждое устройство заново. Попытка открытого менеджера добавить экспорт была признана небезопасной. Уходя из экосистемы Apple, я обнаружил, что десятки сервисов привязаны к iCloud-passkey; без подписки на iCloud переход на Android затруднён. Платные решения вроде 1Password доступны не всем.

Скрытая регистрация

Passkeys часто создаются автоматически. Amazon после каждого входа тихо предлагает добавить passkey, показывая лишь запрос отпечатка. Пользователи даже не замечают, что «подписались». Если у вас устройства разных платформ, вы можете оказаться привязаны сразу к нескольким экосистемам, что затруднит полный переход.

Корпорации как хранители

Люди ежедневно теряют доступ к Google-аккаунтам без объяснений и вместе с ними — ко всем связанным сервисам. Апелляций нет. Попытка восстановить доступ к аккаунту умершего ребёнка в Facebook превратилась в бюрократический кошмар. Чем сложнее система, тем труднее семьям получить доступ при утрате или смерти. Даже вход со стороннего устройства стал мучением: приходится прыгать между приложениями и потоками.

Сложность и посредники

Любительские эксперименты «с нуля» всё труднее: OAuth вытеснил простые логины-пароли, а теперь на смену приходят passkeys.

• Пользователи жалуются на головную боль при входе в свои аккаунты с устройств детей: 2FA, passkeys и смена prepaid-номеров всё усложняют.
• Основной упрек passkeys — «закрытые сады» Apple/Google и невозможность экспортировать ключи; это ограничивает свободу выбора экосистемы.
• Часть сообщества считает запрет экспорта «фичей» безопасности, другие требуют хотя бы зашифрованный экспорт и возможность регистрации нескольких passkey на один сервис.
• Практики безопасности в целом одобряют passkeys как способ избавиться от паролей, но признают, что UX и переходный период пока болезненны.
• Дешёвые или бесплатные решения (Keepass, Bitwarden) остаются популярной альтернативой платным менеджерам, особенно в малообеспеченных семьях.

Слишком многие сервисы используют такой вход:

• Введите email или телефон
• Сайт отправит 6‑значный код
• Введите код для входа

Пожалуйста, прекратите.

Почему это плохо для безопасности:

• Злоумышленник может отправить ваш email на легитимный сервис и заставить вас ввести присланный код в фишинговой форме. Вы не можете быть уверены, где именно нужно вводить код. Менеджеры паролей тут не помогают.
• Этот метод реально эксплуатируется: вход Microsoft для аккаунтов Minecraft использует такие коды, и уже множество аккаунтов было украдено (есть подтверждения на Reddit и YouTube, а также в документации Microsoft).

• Обсуждение критикует OTP по email (6-значные коды): уязвимость к фишингу через «партнёра-входа», спам-запросы на сброс пароля и навязывание пользователям вместо пароля/менеджеров паролей.
• Многие считают, что email-коды хуже UX: задержки, переключение аккаунтов, блокировки при путешествиях, навязчивая MFA/телефон, а также баги (отписка от рассылок ломает вход).
• Контраргументы: пароли тоже фишингуемы и часто слабые/повторяются; для нетехничных пользователей код/магическая ссылка понятнее.
• Предпочтения и альтернативы: магические ссылки вместо кодов (менее фишингуемы), TOTP, passkeys, соцлогин, менеджеры паролей, иногда даже IP-ограничения; просьбы дать выбор, а не форсить один метод.
• Безопасность email-OTP можно улучшать: сочетать короткий код и длинный одноразовый токен, строгие антифишинговые меры почтовых сервисов, ограничения на частоту запросов.
• Реальные негативные кейсы: принудительные схемы у банков/сервисов, невозможность входа без телефона, постоянные письма о сбросах, статические «коды» у некоторых приложений.
• В целом тренд: сервисы перекладывают риск на почту/Google; часть участников продвигает переход к passkeys и магссылкам как более безопасным и удобным компромиссам.