--- service: "Publicasta" schema_version: "1.0" article_id: 339 title: "Passkeys — не магия: что на самом деле меняет Pass-ta-key" language: "ru" default_language: "en" canonical_url: "https://publicasta.com/cybersecurity/passkeys_without_panic_pass_ta_key_webauthn_2026_08_16?lang=ru" json_url: "https://publicasta.com/cybersecurity/passkeys_without_panic_pass_ta_key_webauthn_2026_08_16.json?lang=ru" api_url: "https://publicasta.com/api/public/v1/channels/cybersecurity/articles/passkeys_without_panic_pass_ta_key_webauthn_2026_08_16?lang=ru" channel_url: "https://publicasta.com/api/public/v1/channels/cybersecurity" channel_articles: "https://publicasta.com/api/public/v1/channels/cybersecurity/articles" search_url: "https://publicasta.com/api/public/v1/search" documentation_url: "https://publicasta.com/api-docs#reading-publicasta" openapi_url: "https://publicasta.com/api-docs/openapi.json" published_at: "2026-08-16T17:34:05+00:00" updated_at: "2026-08-16T17:35:05+00:00" translations: - language: "ar" html_url: "https://publicasta.com/cybersecurity/passkeys_without_panic_pass_ta_key_webauthn_2026_08_16?lang=ar" markdown_url: "https://publicasta.com/cybersecurity/passkeys_without_panic_pass_ta_key_webauthn_2026_08_16.md?lang=ar" json_url: "https://publicasta.com/cybersecurity/passkeys_without_panic_pass_ta_key_webauthn_2026_08_16.json?lang=ar" - language: "de" html_url: "https://publicasta.com/cybersecurity/passkeys_without_panic_pass_ta_key_webauthn_2026_08_16?lang=de" markdown_url: "https://publicasta.com/cybersecurity/passkeys_without_panic_pass_ta_key_webauthn_2026_08_16.md?lang=de" json_url: "https://publicasta.com/cybersecurity/passkeys_without_panic_pass_ta_key_webauthn_2026_08_16.json?lang=de" - language: "en" html_url: "https://publicasta.com/cybersecurity/passkeys_without_panic_pass_ta_key_webauthn_2026_08_16?lang=en" markdown_url: "https://publicasta.com/cybersecurity/passkeys_without_panic_pass_ta_key_webauthn_2026_08_16.md?lang=en" json_url: "https://publicasta.com/cybersecurity/passkeys_without_panic_pass_ta_key_webauthn_2026_08_16.json?lang=en" - language: "es" html_url: "https://publicasta.com/cybersecurity/passkeys_without_panic_pass_ta_key_webauthn_2026_08_16?lang=es" markdown_url: "https://publicasta.com/cybersecurity/passkeys_without_panic_pass_ta_key_webauthn_2026_08_16.md?lang=es" json_url: "https://publicasta.com/cybersecurity/passkeys_without_panic_pass_ta_key_webauthn_2026_08_16.json?lang=es" - language: "fr" html_url: "https://publicasta.com/cybersecurity/passkeys_without_panic_pass_ta_key_webauthn_2026_08_16?lang=fr" markdown_url: "https://publicasta.com/cybersecurity/passkeys_without_panic_pass_ta_key_webauthn_2026_08_16.md?lang=fr" json_url: "https://publicasta.com/cybersecurity/passkeys_without_panic_pass_ta_key_webauthn_2026_08_16.json?lang=fr" - language: "pl" html_url: "https://publicasta.com/cybersecurity/passkeys_without_panic_pass_ta_key_webauthn_2026_08_16?lang=pl" markdown_url: "https://publicasta.com/cybersecurity/passkeys_without_panic_pass_ta_key_webauthn_2026_08_16.md?lang=pl" json_url: "https://publicasta.com/cybersecurity/passkeys_without_panic_pass_ta_key_webauthn_2026_08_16.json?lang=pl" - language: "ru" html_url: "https://publicasta.com/cybersecurity/passkeys_without_panic_pass_ta_key_webauthn_2026_08_16?lang=ru" markdown_url: "https://publicasta.com/cybersecurity/passkeys_without_panic_pass_ta_key_webauthn_2026_08_16.md?lang=ru" json_url: "https://publicasta.com/cybersecurity/passkeys_without_panic_pass_ta_key_webauthn_2026_08_16.json?lang=ru" - language: "zh" html_url: "https://publicasta.com/cybersecurity/passkeys_without_panic_pass_ta_key_webauthn_2026_08_16?lang=zh" markdown_url: "https://publicasta.com/cybersecurity/passkeys_without_panic_pass_ta_key_webauthn_2026_08_16.md?lang=zh" json_url: "https://publicasta.com/cybersecurity/passkeys_without_panic_pass_ta_key_webauthn_2026_08_16.json?lang=zh" --- # Passkeys — не магия: что на самом деле меняет Pass-ta-key > Спокойный разбор: какие атаки passkeys действительно закрывают, где остаётся риск endpoint и что проверять при WebAuthn. Августовская волна вокруг Pass-ta-key полезна именно тем, что снимает иллюзию без разрушения самой идеи passkeys. Unit 42 описала атаки на синхронизированные passkeys Google Password Manager в Chrome на Windows. Ars Technica затем остудила самый тревожный вывод: это не означает, что passkeys «сломаны», но показывает границу обещания “unphishable”. Passkeys хорошо режут фишинг, повторное использование паролей и credential stuffing. Они не превращают заражённый компьютер в безопасный и не исправляют слабое восстановление аккаунта. ![Схема: passkeys блокируют фишинг, заражённый endpoint остаётся риском, hardware keys нужны для важных аккаунтов](https://publicasta.com/storage/projects/9/pages/339/2026/08/647a35ae-2aea-4a2d-8fb9-5bb778734885.webp) ## Что произошло и какой вывод неверен Исследование Unit 42 от 3 августа рассматривает конкретную среду: Google Password Manager, Chrome на Windows, облачный authenticator и устройства с TPM. Описаны три класса атак — Pass-ta-key, Silver Pass-ta-key и Golden Pass-ta-key. Главное условие во всех вариантах не в названии, а в модели угроз: вредоносный код уже должен присутствовать на устройстве жертвы на начальном этапе. Это не удалённый взлом стандарта WebAuthn и не доказательство, что фишинговый сайт теперь может «попросить passkey как пароль». Корректная формулировка уже: локальная malware может злоупотреблять доверенным состоянием браузера, механизмами onboarding, recovery и user verification вокруг synced passkeys. В отдельных конфигурациях это может дать вход без нового действия пользователя, обход проверки пользователя или доступ к синхронизированному материалу. Для разработчиков и администраторов это серьёзно. Для обычного пользователя вывод другой: не отключать passkeys из-за заголовка, а понять, что заражённый endpoint остаётся опасным. Ars справедливо напоминает: если атакующий уже работает внутри доверенной пользовательской сессии, под ударом не только passkeys. Он может охотиться за cookies, токенами, файлами, браузерными профилями, уведомлениями, recovery flows и парольными хранилищами. Passkeys создавались как замена общему секрету и защита от фишинга. Они не были обещанием заменить антивирус, EDR, изоляцию ОС и расследование компрометации. ## Как passkey защищает вход Passkey — это FIDO/WebAuthn-учётные данные на основе пары ключей. При регистрации authenticator создаёт ключ для конкретного сайта. Сервис хранит public key, а private key остаётся у authenticator или passkey provider. При входе сайт отправляет challenge, браузер и authenticator подписывают данные для правильного origin, а пользователь подтверждает действие разблокировкой устройства, PIN, биометрией или касанием ключа, если политика этого требует. Именно поэтому passkeys сильны против массового фишинга. Поддельная страница не получает пароль, который можно повторно использовать. Утечка серверной базы не даёт хэши паролей для перебора. Credential stuffing теряет основу, потому что один и тот же секрет не ходит между сайтами. В терминах FIDO и W3C это phishing-resistant вход: ответ привязан к реальному origin и relying party, а не к красивой копии формы. Но phishing-resistant не значит malware-proof. Это означает, что удалённый фишинговый сайт не должен получить reusable secret. Это не означает, что заражённый ноутбук не сможет действовать внутри уже доверенного профиля, запускать разрешённые flows, ждать разблокировки, читать плохо защищённую локальную информацию или пользоваться активной сессией. У каждой защиты есть границы. У passkeys граница большая, но не бесконечная. ## Что именно показала Unit 42 Мартовская работа Unit 42 объясняла скрытые механизмы Google Cloud Authenticator для synced passkeys. Августовская работа показала, как Chrome на Windows, TPM-backed device trust, локальные sync records и облачная проверка могут создавать неожиданные пути атаки. Важно держать фокус: исследование отвечает за конкретный стек Google Password Manager в Chrome на Windows и прямо указывает prerequisite malware. Первый урок — доверие к устройству не должно превращаться в слепую веру. Если код атакующего уже работает там, где живёт браузер и аккаунт Google, он может пытаться провести новые шаги как будто из доверенного контекста. Второй урок — user verification нельзя оставлять “preferred” там, где бизнес ожидает сильную MFA. Третий урок — синхронизация удобна и часто безопаснее паролей, но recovery и backup становятся частью attack surface. Это не аргумент против synced passkeys для всех. Для обычных аккаунтов они часто лучший компромисс: люди не теряют доступ, не возвращаются к слабым паролям и меньше ловятся на фишинг. Для администраторов, финансовых ролей, разработчиков production-систем и руководителей нужен другой уровень: hardware security keys, managed devices, conditional access и строгая регистрация authenticator. ## Почему passkeys всё равно нужны Панический цикл опасен тем, что люди отказываются от слоя, который реально помогает. Password phishing остаётся массовым бизнесом. Повторное использование паролей всё ещё превращает одну утечку в несколько захватов аккаунтов. Одноразовые коды и SMS можно выманить через adversary-in-the-middle kits. Passkeys резко уменьшают эти риски. Для большинства пользователей включить passkey на почте, облаке, GitHub, банке или маркетплейсе безопаснее, чем остаться только с паролем. Правильная реакция — не «выключить passkeys», а «перестать считать их всей security program». Нужны обновления ОС и браузера, осторожность с расширениями, защита от infostealers, блокировка экрана, ревизия recovery email/phone, удаление старых устройств и проверка активных сессий. Нужна и хорошая серверная реализация WebAuthn: уникальные challenge, привязка к сессии, проверка origin и relying party ID, защита от replay и требование user verification для важных операций. Google Help говорит пользователям, что passkeys проще и безопаснее паролей, не могут быть случайно переданы как пароль и требуют доступа к устройству. Это полезное объяснение, но вокруг него есть инженерная реальность: synced passkeys включают облачное хранение, onboarding, recovery и локальное состояние браузера. Пользователь не печатает private key в фишинговую форму, но malware на доверенном endpoint может атаковать окружение вокруг него. ## Что делать обычному пользователю Оставьте passkeys включёнными на важных сервисах. Поставьте сильную блокировку экрана на все устройства, которые могут подтверждать вход. Удалите старые телефоны и ноутбуки из security pages аккаунтов. Проверьте recovery email, номера телефонов и резервные методы: часто именно восстановление становится слабой дверью после отказа от пароля. Не используйте общие и непроверенные компьютеры для главной почты, финансов и рабочих аккаунтов. Осторожнее с расширениями браузера. Расширение с широкими правами находится слишком близко к страницам, prompt и сессиям. Обновляйте Windows, macOS, Android, iOS и браузеры. Если устройство было заражено, относитесь к аккаунтам как к части уборки: revoke sessions, удалить неизвестные устройства, проверить новые passkeys, recovery methods, правила пересылки почты и OAuth grants. Чистить только malware и не смотреть identity state — половина работы. Для главной почты, облачной консоли, брокерского счёта или developer account полезен hardware security key. Лучше иметь два ключа: основной и резервный. Это менее удобно, чем synced passkey, но для crown-jewel accounts снижает зависимость от облачной синхронизации и обычного desktop state. Магией ключ тоже не становится: recovery process и устройство после входа всё равно важны. ## Что делать организациям Организации не должны спрашивать только «безопасны ли passkeys». Нужно классифицировать роли. Кого в основном атакует массовый phishing? Кто может менять identity policy, платежи, production, исходный код или regulated data? Какие устройства managed, encrypted, patched и monitored? Какие passkey providers разрешены? Где synced passkeys приемлемы, а где нужны device-bound credentials или hardware keys? Для обычных сотрудников synced passkeys часто лучше пароля плюс SMS. Для privileged admins стоит требовать phishing-resistant authentication на hardware keys или managed platform authenticators, conditional access, device compliance и отдельные privileged workstations. Важно не смешивать две линии исследований: Unit 42 — это Google synced passkeys и Chrome/Windows; SpecterOps/Black Hat — отдельная линия про Windows 11, Microsoft Entra ID, WebAuthn assertions, logging и replay validation. Общий урок есть, но это не одна уязвимость. Incident response тоже должен стать passwordless-aware. При компрометации endpoint недостаточно «сбросить пароль». Нужно отзывать сессии, смотреть добавленные passkeys, удалять неизвестные devices, менять recovery factors, проверять OAuth grants, заново регистрировать trusted devices и анализировать sign-in logs. Passwordless без такого playbook даёт ложное чувство завершённости. ## Чеклист WebAuthn для сервисов Challenge должен быть случайным, короткоживущим, одноразовым и связанным с конкретной сессией и операцией. Сервер обязан проверять origin, relying party ID, signature и отсутствие replay. User verification для чувствительных аккаунтов и действий лучше требовать явно, а не оставлять “preferred” из удобства. Если сервис допускает более мягкий режим, это должно быть осознанным risk decision, а не случайной настройкой. Регистрация passkey не менее важна, чем вход. Добавление нового authenticator должно происходить из недавно подтверждённой сессии, сопровождаться уведомлением и понятным отображением устройства или provider, где это возможно. Для высокорисковых ролей стоит решить, нужна ли attestation policy и какие hardware keys допустимы. Backup eligibility, backup state, counters и metadata — это сигналы, а не волшебные флажки безопасности. ## Спокойный вывод Passkeys не умерли и не стали бесполезными. Они остаются одним из лучших массовых улучшений входа, потому что убирают reusable password из повседневной схемы. Но они не лечат заражённый endpoint, слабое восстановление аккаунта и плохую реализацию WebAuthn. Их нужно внедрять как сильный слой, а не как финальную точку security. Практическое правило простое: используйте passkeys для обычных аккаунтов, hardware keys и managed devices — для тех, чей захват будет дорогим, а WebAuthn реализуйте как протокол, а не как маркетинговый бейдж. Когда появится следующий страшный заголовок про passwordless, сначала спросите: сломалась ли криптографическая идея входа или нас снова предупреждают, что устройство, recovery и implementation details всё ещё имеют значение?