Hacker News Digest

В ответ на вирусную публикацию «Passkeys — это ловушка, не используйте их» автор разбирает её центральный тезис. Утверждается, что passkeys поддерживают аттестацию — криптографическое доказательство того, чем создан ключ, — и сайты якобы будут постепенно ужесточать требования, пока вход не останется только с одобренного ПО на одобренной ОС, без LineageOS и без передачи пароля от Netflix. Вывод: passkeys «не созданы для защиты ваших интересов».

Однако это не соответствует реальности. Большинство используют синхронизируемые passkeys (iCloud Keychain, Google Password Manager, 1Password, Bitwarden), а они вообще не передают аттестацию: в ответ на запрос приходит лишь none. Если потребительский сайт завтра потребует аттестованные ключи, он мгновенно заблокирует почти всех своих пользователей, а рекомендации для таких сайтов уже много лет — вообще не запрашивать аттестацию. Когда аттестация есть, она сообщает лишь производителя и модель аутентификатора по AAGUID с цепочкой сертификатов — ничего об ОС, браузере, расширениях, рут-доступе или прошивке. Особенно странно, что для усиленной защиты советуют YubiKey: именно эти ключи и поставляются с аттестационным сертификатом Yubico.

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

Обсуждение дополняет статью критическим взглядом на UX и реальные риски вендор-лока, утверждая, что аттестация уже используется для ограничений, а не только в будущем. Спор: Автор статьи утверждает, что аттестация не раскрывает данные об ОС или руте, но @tennysont и @the_mitsuhiko указывают, что Pixel может передать статус verifiedBootState, а в Австрии аттестация уже используется для блокировки определенных провайдеров. Пользователи (@bonzog, @hbn, @woeirua) жалуются на запутанный UX: неочевидно, где хранится ключ (браузер, ОС или облако), и возникают сложности при кросс-платформенном использовании. Спор: Спор о безопасности: @class3shock и @hbn считают, что уникальные длинные пароли в менеджере дают сопоставимую защиту при гораздо меньшем трении, чем passkeys. Существует серьезный риск «ловушки» из-за отсутствия обязательной переносимости ключей между провайдерами (@glaslong, @sega_sai), что ведет к зависимости от экосистемы Apple, Google или Microsoft. Совет: По опыту @lokar, passkeys стоит использовать только для 2-3 критически важных ресурсов (почта, банк, DNS), где выигрыш в безопасности перевешивает проблемы с удобством. Пользователи отмечают, что многие сайты навязывают «облачные» passkeys и игнорируют поддержку аппаратных ключей вроде Yubikey (@abraxas). Практический опыт (@dllu, @benlivengood) показывает проблемы совместимости: Firefox на Linux может не предлагать QR-код для подключения телефона или отклонять ключи из Keepass на Facebook. К автору статьи высказывают недоверие из-за его коммерческого интереса: он владелец Report URI, который продает услуги защиты passkeys (@freakynit). Риск потери доступа: @sdcfgy и @rietta подчеркивают, что обычный пользователь может потерять устройство и доступ к iCloud, что сделает восстановление аккаунта невозможным. Пример @YakBizzarro с SwissPass подтверждает, что белые списки провайдеров WebAuthn существуют уже сейчас, отсекая такие инструменты, как Bitwarden.

Пароли постепенно вытесняются «пасключами» (passkeys), которые подаются как более безопасная и удобная альтернатива. Однако, в отличие от паролей, приложений-аутентификаторов или физических ключей, пользователь не имеет полного контроля над пасключами: у сайтов есть скрытый механизм, позволяющий постепенно отбирать у вас возможность распоряжаться ими по своему усмотрению. Технологию продвигает альянс FIDO — консорциум, куда входят корпорации, спецслужбы, банки и госструктуры, но не входит ни одна организация по защите прав потребителей. У каждой стороны свой интерес: реклама, слежка, снятие ответственности.

В комментариях отмечают ещё одну опасность: в США для разблокировки устройства по биометрии не нужен ордер — полиция может просто поднести телефон к лицу и получить доступ к данным. Пароль же, будучи «речью», принудительно выдать сложнее, а данные можно шифровать несколькими паролями, контролируя, что именно раскрывается. К тому же биометрия уступает хорошему паролю по стойкости: подделать отпечаток или лицо несопоставимо проще, чем взломать надёжный пароль.

Обсуждение дополняет статью примерами плохого UX, опасениями по поводу вендор-лока и юридических рисков. Многие участники защищают passkeys как единственную эффективную защиту от фишинга и MITM-атак. Сторонники passkeys (@advisedwang, @ttul) утверждают, что TOTP уязвим для фишинга и MITM-атак, в то время как passkeys решают эти проблемы, делая их на порядок безопаснее. Пользователь @agwa считает сценарий массового переключения на аттестацию ключей маловероятным, так как Apple не поддерживает аттестацию, а браузеры запрашивают разрешение пользователя. Механизм удаленной аттестации (remote attestation) воспринимается как серьезная угроза приватности и инструмент усиления дуополии Apple и Google (@userbinator, @elric, @djfergus). Для минимизации рисков потери доступа рекомендуется использовать несколько passkeys для одного аккаунта, храня их в разных менеджерах паролей (@skybrian). Текущий UX passkeys оценивается как фрагментированный и неудобный: разные сайты реализуют разные сценарии входа, а процесс отмены подписки на passkeys часто скрыт в глубоких настройках (@tonymet, @bmitch3020). Существует проблема ограниченного объема памяти аппаратных ключей; например, дорогие YubiKey вмещают лишь около 100 passkeys, что недостаточно для пользователей с сотнями аккаунтов (@elric). По опыту @oefrha, внедрение требования userVerification в 1Password привело к необходимости вводить и мастер-пароль менеджера, и пароль сайта, что нарушает концепцию «одного пароля». Высказываются опасения, что централизация учетных данных через passkeys облегчит доступ правоохранительных органов к данным пользователей и станет шагом к внедрению государственных цифровых ID (@beaker52). Отмечается риск юридической незащищенности: в отличие от паролей, биометрическая разблокировка passkeys может не подпадать под защиту некоторых поправок к Конституции США (@waterheater).

Passkeys предлагают сильную защиту от фишинга и утечек данных благодаря привязке к сайту и асимметричной криптографии, но для личного использования они создают новые риски: высокая вероятность постоянной блокировки аккаунта при потере устройства, бана аккаунта в экосистеме Apple или Google (что влечёт потерю всех синхронизированных passkeys) или недостаточно надёжных методов восстановления (SMS, email, секретные вопросы). Аппаратные ключи не позволяют делать бэкапы passkeys, требуют отдельной регистрации для каждого сервиса и ограничены по количе accounts (25–300 на ключ), что делает их дорогими и непрактичными при большом числе аккаунтов. Синхронизация через ОС привязывает идентичность к платформе, а экспорт passkeys остаётся фрагментированным и непоследовательным — в отличие от паролей, которые легко переносить вручную. Сторонние менеджеры паролей пока не обеспечивают плавной интеграции с нативными приложениями и браузерами из-за незрелых API и недостатка UX-полировки. В сценариях использования чужих устройств (например, коллегиного компьютера) passkeys становятся неудобными: аппаратные ключи могут быть недоступны из-за отсутствия портов, а гибридный транспорт через QR-код и Bluetooth часто сталкивается с техническими сбоями. Хотя passkeys идеальны для корпоративной среды, где управляются устройства и восстановление централизовано, для обычных пользователей текущая экосистема создаёт больше проблем, чем решает: риск потери доступа превышает выгоду от защиты от фишинга. Надёжнее пока остаётся сочетание уникальных паролей из менеджера и независимого TOTP-приложения — оно даёт контроль, гибкость и избегает привязки к единственной точке отказа. Для тех, кто ранее использовал одинаковые пароли везде, passkeys — улучшение; для остальных — шаг назад.

Passkeys создают риск потери доступа к аккаунтам из-за зависимости от экосистем Apple/Google, плохой поддержки сторонних менеджеров паролей и отсутствия гибких механизмов резервного копирования. Потеря устройства или блокировка аккаунта в Apple/Google приводит к потере всех синхронизированных ключей. Большинство пользователей не осознают привязки passkeys к экосистеме и случайно их включают, усиливая проблему непрозрачности. Сайты вроде Amazon не распознают существующие passkeys в менеджерах паролей (Bitwarden, 1Password), предлагая создать новый ключ. Многие сервисы требуют только синхронизируемые ключи Apple/Google, блокируя использование аппаратных YubiKey и делая такие инвестиции бессмысленными. Отсутствие возможности добавить резервный ключ на другое устройство или в сейф делает passkeys непригодными для безопасного хранения. Пользователи с нестандартными устройствами (Linux, Xiaomi) сталкиваются с полным отсутствием поддержки. Passkeys не решают проблему слабых методов восстановления (SMS, email, вопросы), которые остаются уязвимыми. Зависимость от синхронизации между устройствами требует постоянного наличия нескольких исправных и заряженных гаджетов. Некоторые пользователи отмечают улучшение качества жизни: упрощение входа и устранение проблем с автозаполнением в 1Password при использовании iCloud/Google-синхронизации. Другие видят прогресс в использовании passkeys как основного фактора аутентификации, несмотря на проблемы с Google. Рекомендуется иметь несколько синхронизируемых устройств, хранить passkeys в менеджере паролей для кроссплатформенного доступа, возвращаться к аппаратным ключам как более интуитивной модели, отключать навязчивые запросы на создание passkeys в браузере и использовать non-resident U2F-ключи, которые не требуют хранения на устройстве и предлагают больше свободных слотов.

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

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

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

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

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

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