Пароли устарели: как перейти на passkeys и YubiKey

Reading time: 8 minutes

Last modified:

Пароль придумали в 1960-х. Система CTSS в MIT использовала его, чтобы разделить пользователей одного мейнфрейма. Шестьдесят лет спустя мы всё ещё просим людей придумывать, запоминать и не повторять десятки секретов, а когда секреты крадут, виним пользователей.

Вина лежит не на них. Сама модель паролей сломана, и никакая политика её не чинит.

Почему пароли не работают по замыслу

Пароль — это общий секрет. Его знаете вы, и его проверяет сервер. Из такой схемы вытекают четыре проблемы, которые не решают никакие правила сложности.

Узнавший пароль может им пользоваться. Сервер хранит хеш, но при каждом входе вы отправляете сам секрет. Фишинговые страницы, кейлоггеры, инфостилеры и скомпрометированный обратный прокси перехватывают его по дороге. В отчёте Verizon Data Breach Investigations Report за 2025 год злоупотребление учётными данными стоит на первом месте среди способов первоначального доступа: 22% взломов.

Вы повторяете пароли. Запомнить 150 уникальных строк по 16 символов невозможно. Поэтому утечка на забытом форуме превращается в утечку в вашем банке. Инструменты credential stuffing автоматизируют это: они подставляют пары «почта + пароль» из утечек в тысячи сервисов в час. Have I Been Pwned индексирует миллиарды утёкших аккаунтов, и ваш почтовый адрес десятилетней давности, скорее всего, там есть.

Правила сложности делают хуже. «Восемь символов, заглавная буква, спецсимвол» дают Summer2026!. NIST SP 800-63B отказался от обязательных правил состава и периодической смены паролей именно поэтому. Принудительная смена приучает людей дописывать цифру в конец.

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

Менеджеры паролей решают проблему повторов и слабых паролей. Но пользователь, который вставит идеальный 24-символьный пароль на убедительной подделке, всё равно его отдаст. Чтобы закрыть эту дыру, нужно убрать общий секрет.

Passkeys: открытые ключи вместо секретов

Passkey — это учётные данные FIDO2 на основе стандарта WebAuthn, который разработали FIDO Alliance и W3C. Механизм тот же, что защищает SSH-ключи и TLS-сертификаты: асимметричная криптография.

  1. При регистрации устройство создаёт пару ключей для конкретного сайта.
  2. Приватный ключ остаётся на устройстве. Сайт получает публичный.
  3. При входе сайт присылает случайный запрос (challenge). Устройство подписывает его после того, как вы подтвердили вход отпечатком, лицом или PIN-кодом.
  4. Сайт проверяет подпись публичным ключом.
Вход по passkey: устройство хранит приватный ключ и подписывает запрос сайта

У такой схемы три свойства.

По сети не уходит ничего, что можно использовать повторно. Подписанный запрос действует один раз и только для одного сайта. Из утёкшей базы злоумышленник получит публичные ключи, а они ему бесполезны.

Фишинг перестаёт работать. Браузер привязывает ключ к настоящему домену. На examp1e.com passkey для example.com не появится, и пользователю нечего отдавать. Это главное отличие passkeys от любого способа, где пользователь вводит код.

Биометрия остаётся на устройстве. Отпечаток пальца не покидает устройство. Он разблокирует приватный ключ и больше ничего.

Фишинг против пароля и против passkey: поддельному домену passkey не предлагается

Синхронизируемые passkeys и привязанные к устройству

Passkeys бывают двух видов:

  • Синхронизируемые хранятся в связке ключей iCloud, Google Password Manager, в экосистеме Microsoft или в менеджере паролей вроде 1Password и Bitwarden. Они следуют за вами между устройствами и переживают потерю телефона.
  • Привязанные к устройству живут на одном физическом устройстве, например на аппаратном ключе, и никуда с него не уходят.

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

Apple, Google и Microsoft встроили passkeys в операционные системы и браузеры. GitHub, PayPal, Amazon, Shopify и большинство крупных провайдеров идентификации их принимают. Новые аккаунты Microsoft по умолчанию беспарольные.

YubiKey: passkey, который можно взять в руку

YubiKey — аппаратный ключ безопасности от Yubico. Он хранит учётные данные в защищённом от вскрытия чипе и подписывает запросы после касания. Приватный ключ нельзя экспортировать, скопировать или синхронизировать, даже вам самим.

Аппаратный ключ безопасности в ноутбуке, телефон со сканером отпечатка и запасной ключ на подставке

Поэтому для аккаунтов с высокой ценой взлома это самый сильный вариант. Доказательства конкретные. В 2018 году Google сообщил, что после перехода 85 000+ сотрудников на физические ключи безопасности компания не зафиксировала ни одного подтверждённого захвата аккаунтов с начала внедрения в 2017 году. Исследование Google 2019 года о захвате аккаунтов сравнило методы на трёх типах атак:

Метод Автоматические боты Массовый фишинг Целевые атаки
SMS-код 100% блокируется 96% 76%
Подтверждение на устройстве 100% 99% 90%
Ключ безопасности 100% 100% 100%

Один ключ умеет больше, чем FIDO2. YubiKey серии 5 поддерживает FIDO2/WebAuthn, FIDO U2F, смарт-карту PIV, OpenPGP и одноразовые коды OATH. Им можно входить в Google и GitHub, подписывать Git-коммиты, аутентифицироваться по SSH и хранить секреты TOTP: всё на одном устройстве.

Практические советы

  • Купите минимум два. Зарегистрируйте оба на каждом важном аккаунте. Второй храните в сейфе, банковской ячейке или в ящике офиса.
  • Выберите форм-фактор под своё железо. USB-C для современных ноутбуков и телефонов, USB-A для старых машин, NFC для касания телефоном. YubiKey Bio добавляет сканер отпечатка вместо подтверждения касанием.
  • Задайте PIN для приложения FIDO2. Тогда одного физического владения украденным ключом мало.
  • Расставьте приоритеты. Начните с основной почты, менеджера паролей, облачной консоли, регистратора доменов, хостинга кода и банка. Почта идёт первой, потому что через неё проходит любой сброс пароля.
  • Создайте резервные коды там, где сервис их выдаёт, и храните их офлайн.

Базовый ключ FIDO стоит от $29, YubiKey 5 NFC около $58, YubiKey Bio $98. Один взломанный админский аккаунт обойдётся дороже всей коробки ключей.

Альтернативы: OTP из приложения и из почты

Не каждый сервис можно перевести на passkeys уже сегодня. Если лучшего варианта нет, берите эти, в порядке предпочтения.

TOTP из приложения-аутентификатора

Одноразовые пароли по времени (RFC 6238) — это шестизначные коды в Google Authenticator, Microsoft Authenticator, Aegis, 2FAS или 1Password. Приложение и сервер при настройке обмениваются секретом, а потом оба считают код из этого секрета и текущего 30-секундного окна.

Плюсы:

  • Работает офлайн и на любом сервисе с поддержкой TOTP.
  • Не зависит от SIM-карты, поэтому защищён от SIM-swap.
  • Бесплатен, настройка занимает две минуты.

Минусы:

  • Код вводит человек, поэтому фальшивая страница входа соберёт его и передаст настоящему сайту в пределах тех же 30 секунд. Инструменты вроде Evilginx делают это автоматически.
  • Секрет лежит на телефоне. Потеряете телефон без резервной копии, потеряете доступ.
  • Google Authenticator умеет синхронизировать секреты с аккаунтом Google. Это удобно, но второй фактор переезжает в облачный аккаунт. Решите, устраивает ли вас такой риск.

Берите приложение с зашифрованными бэкапами или экспортом (Aegis, 2FAS, 1Password) и храните коды восстановления офлайн.

Сервер присылает код или одноразовую ссылку на почту. В потребительских продуктах это убирает пароль из регистрации, а пользователи уже понимают, как это работает.

Плюсы:

  • Не нужны ни приложение, ни устройство, ни запоминаемый секрет.
  • Мало трения при редких входах.

Минусы:

  • Фишинг работает так же, как против TOTP.
  • Защита равна защите почтового ящика. Если ящик закрыт слабым паролем, OTP из почты — это слабый пароль с лишними шагами.
  • Задержки доставки и спам-фильтры ломают вход в самый неудобный момент.
  • Письмо проходит через несколько серверов, обычно без сквозного шифрования.

Используйте OTP из почты как запасной вариант и канал восстановления для аккаунтов с низким риском, а сам ящик защитите passkey или аппаратным ключом.

Чего избегать: SMS-коды

SMS лучше голого пароля и хуже всего, что описано выше. SIM-swap, уязвимости SS7 и перевыпуск номеров дают атакующим лазейки. NIST относит SMS к «ограниченным» аутентификаторам в SP 800-63B. Оставляйте SMS, только если сервис не предлагает ничего другого, и уходите с него, как только появится выбор.

Лестница методов

Метод Защита от фишинга Защита от повторного использования паролей Усилия на восстановление
Только пароль Нет Нет Низкие
Пароль + SMS Нет Частично Низкие
OTP из почты Нет Да Низкие
Пароль + TOTP Нет Частично Средние
Синхронизируемый passkey Да Да Низкие
Аппаратный ключ (YubiKey) Да Да Средние

От фишинга защищают только две нижние строки. Остальные методы поднимают планку для ленивых атакующих и не спасают от настойчивых.

Что делать, если вы строите продукты

Вводите аутентификацию в таком порядке.

  1. Сделайте passkeys основным способом входа. Берите поддерживаемую библиотеку (SimpleWebAuthn для Node.js, py_webauthn для Python, webauthn-rs для Rust) или провайдер идентификации с passkeys (Auth0, Keycloak, AWS Cognito, Clerk). Проверку WebAuthn самим не пишите.
  2. Предлагайте регистрацию passkey сразу после успешного входа. Пользователь только что подтвердил личность, а страницу настроек никто не открывает.
  3. Поддержите аппаратные ключи рядом с платформенными passkeys. Требуйте их для админов, сотрудников и всех, у кого есть доступ к продуктовым данным.
  4. Оставьте TOTP запасным вариантом, а OTP из почты — для сценариев с низким риском. Новым пользователям SMS не предлагайте.
  5. Удаляйте пароль, когда пользователь зарегистрировал passkey. Пока старый пароль активен, атакующий воспользуется им, и новая защита ничего не даст. Дайте пользователю убрать пароль из аккаунта.
  6. Проектируйте восстановление первым. Когда вход защищён, атакующие идут через восстановление. Потребуйте несколько зарегистрированных аутентификаторов или резервные коды, добавьте задержку на восстановление и уведомляйте пользователя о каждом изменении. Восстановление в обход сильного фактора сводит работу на нет.
  7. Используйте step-up аутентификацию для чувствительных действий: смены счёта для выплат, выгрузки данных. Просите свежее касание ключа даже внутри активной сессии.
  8. Ограничивайте частоту запросов и логируйте все эндпоинты аутентификации, включая проверку OTP.

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

План, который можно выполнить за месяц

Для себя:

  1. Купите два ключа безопасности.
  2. Зарегистрируйте их на почте, в менеджере паролей, облаке, хостинге кода и банке.
  3. Включите passkeys в основном аккаунте Apple, Google или Microsoft и в менеджере паролей.
  4. Замените SMS-коды на TOTP или passkeys везде, где это возможно.
  5. Распечатайте резервные коды и уберите в сейф.

Для команды:

  1. Составьте список всех систем с входом и отметьте, какие факторы каждая поддерживает.
  2. Переведите провайдера идентификации на устойчивые к фишингу факторы: сначала для админов, потом для всех.
  3. Выдайте каждому по два аппаратных ключа.
  4. Отключайте SMS и входы только по паролю по одной системе за раз.
  5. Проверьте восстановление на человеке, который потерял всё.

Итоги

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

OTP из приложения и из почты помогают, когда сервис не предлагает лучшего. Считайте их ступенью и планируйте уход с неё.

Мы встраиваем аутентификацию в веб-платформы, мобильные приложения и IoT-продукты: от входа по passkey до аппаратной идентификации устройств. Если хотите увести продукт с паролей или проверить текущую схему, напишите нам.

Часто задаваемые вопросы

Что такое passkey?

Passkey — это учётные данные FIDO2/WebAuthn. Устройство создаёт для каждого сайта пару ключей, приватный ключ оставляет у себя, а сайту отдаёт публичный. Вы подтверждаете вход отпечатком, лицом или PIN-кодом устройства. По сети не уходит ничего, что можно использовать повторно.

Passkey надёжнее, чем пароль плюс код из приложения?

Да. Passkey привязан к настоящему домену, и поддельная страница входа его не получит. Пароль и шестизначный код можно ввести на фальшивой странице, и злоумышленник тут же перешлёт их настоящему сайту.

Нужен ли YubiKey, если я уже использую passkeys?

Не для каждого аккаунта. Большинству хватает синхронизируемых passkeys. YubiKey добавляет ключ, привязанный к устройству: облачный аккаунт его не раскроет. Ключ нужен для почты, менеджера паролей, облачных консолей, админских аккаунтов и людям с повышенными рисками.

Что делать, если потерял YubiKey?

Зарегистрируйте минимум два ключа на каждом важном аккаунте и храните второй в сейфе. Резервные одноразовые коды держите офлайн. Тогда потеря ключа стоит вам поездки к сейфу, а не аккаунта.

Достаточно ли безопасен OTP из почты?

Как запасной вариант и для аккаунтов с низким риском подходит, если сам почтовый ящик защищён passkey или аппаратным ключом. Код из письма можно выманить фишингом, и защита ровно такая же, как у ящика, куда он приходит.

Пароли устарели: как перейти на passkeys и YubiKey
Table of Contents