Passkeys и мультиаккаунтинг: изоляция ключей в 2026

С 1 сентября 2026 года Microsoft начала включать passkeys как способ входа по умолчанию в Entra ID, а с 1 февраля 2027 года отключает собственную доставку SMS- и голосовых кодов. Google сделал ключи доступа основным вариантом входа для личных аккаунтов ещё в октябре 2023-го. Для одного человека с одним аккаунтом это удобно. Для тех, кто ведёт десятки аккаунтов в антидетекте, passkey легко становится незаметной ниткой, которая связывает между собой изолированные профили. Ниже разбираем, как это происходит и как выстроить схему, в которой ключи не «протекают» между аккаунтами.

Почему вопрос встал именно сейчас

Passkeys существуют с 2022 года, но в 2026-м из «можно включить» они превратились в «вас попросят». Три конкретных повода:

Microsoft Entra ID. С сентября 2026 года пользователям, которые подтверждали вход по SMS или звонку, автоматически включаются passkeys: при следующей проверке MFA появится предложение зарегистрировать ключ. До 31 января 2027 года его можно отложить, с 1 февраля 2027-го пропустить уже нельзя. В обоснование Microsoft приводит свою цифру: фишинговые кампании с ИИ получают 54% кликов против 12% у обычных.
Google. С октября 2023 года в личных аккаунтах по умолчанию включён параметр «Пропускать ввод пароля, когда это возможно». Если ключ создан, Google предлагает входить по нему.
Перенос ключей между менеджерами. FIDO Alliance опубликовал стандарт Credential Exchange (форматы CXF и CXP). В iOS 26 и macOS 26 передавать passkeys между Apple Passwords, 1Password, Bitwarden, Dashlane и другими приложениями можно зашифрованно, без выгрузки файла. Ключ перестал быть намертво привязанным к одному хранилищу. Для мультиаккаунтинга это и возможность, и риск.

Как устроен passkey и почему он ломает изоляцию профилей

Passkey — это пара криптографических ключей. Публичный ключ хранит сайт, приватный хранит «аутентификатор». Ключ привязан к домену (в спецификации это rpId), поэтому фишинговый сайт его не получит. Главный вопрос для мультиаккаунтинга — где физически лежит приватный ключ. Антидетект изолирует cookies, localStorage, IndexedDB и отпечаток. Хранилище ключей часто находится вне браузерного профиля:

Windows Hello хранит ключи на уровне учётной записи Windows. Любой браузер и любой профиль под этой учёткой обращается к одному и тому же хранилищу.
Связка ключей iCloud на macOS принадлежит Apple ID. Chrome и Safari на одном маке видят один набор ключей.
Менеджер паролей Google привязан к Google-аккаунту, в который вошёл браузер или телефон. Один служебный Google-аккаунт на двадцать профилей — это один общий сейф.
Расширения-менеджеры (Bitwarden, 1Password и другие) хранят ключи в хранилище своего аккаунта. Одно хранилище на все профили работает как единая точка, через которую видно всё.

Отсюда типичный сбой. Вы нажимаете «Войти с ключом доступа» в профиле аккаунта №7, а система показывает ключи аккаунтов №3 и №12 на том же сайте. Сайт этот список не видит: он получает только выбранный ключ. Но одно неверное нажатие — и аккаунт №3 входит из профиля, IP и отпечатка аккаунта №7. Такую связь уже не отменить.

Что сайт реально узнаёт при входе по passkey

Passkey не отменяет риск-скоринг, он просто заменяет пароль. При входе площадка по-прежнему видит IP, отпечаток браузера и историю сессий. Плюс получает несколько собственных сигналов WebAuthn:

Идентификатор ключа (credential ID). Он уникален для пары «аккаунт — аутентификатор».
AAGUID — идентификатор модели аутентификатора. По нему сайты вроде Google подписывают ключ в настройках аккаунта: «создан в iCloud Keychain», «в менеджере паролей Google» и так далее. Это не уникальный номер вашего устройства, но это ещё одна характеристика, которая должна совпадать с легендой профиля.
Флаги BE и BS (backup eligibility и backup state) показывают, синхронизируемый это ключ или привязанный к устройству.

Вывод: «мобильный» профиль, который входит ключом из Windows Hello, выглядит так же нелогично, как iPhone с таймзоной Бразилии и IP из Германии. Ключ должен соответствовать той же легенде, что прокси и отпечаток.

Пошаговая схема: один аккаунт — один профиль — одно хранилище — один IP

Проведите инвентаризацию. Выпишите площадки, где у ваших аккаунтов уже есть passkeys или появилось предложение их создать: Google, Microsoft, крупные маркетплейсы и соцсети. В настройках безопасности каждого аккаунта видно, сколько ключей зарегистрировано и где они созданы. Все неожиданные записи «Windows Hello» и «iCloud Keychain» — кандидаты на удаление.
Отключите системное хранение ключей для рабочих профилей. В браузере, где работают профили, выключите сохранение паролей и ключей доступа во встроенном менеджере. На рабочей машине не создавайте ключи в Windows Hello или связке iCloud. Если окно создания ключа предлагает «этот компьютер», выбирайте другой способ.
Выберите хранилище для каждого аккаунта. Правило простое: хранилище должно быть разделено так же, как профили. Варианты:
- отдельное хранилище менеджера паролей на аккаунт или на группу аккаунтов одного клиента;
- аппаратный ключ (FIDO2) для немногих самых ценных аккаунтов;
- для автоматизации — программный аутентификатор, о нём в шаге 6.
Одно хранилище на всех — самый частый способ самому связать аккаунты между собой.
Регистрируйте ключ только из «родного» профиля. Тот же профиль, тот же отпечаток, тот же прокси с закреплённой сессией, то же гео, что при обычной работе аккаунта. Регистрация ключа — чувствительное действие, и площадки смотрят на него внимательно. Смена IP посреди процедуры часто приводит к дополнительной проверке. Как держать один адрес на профиль, мы подробно разбирали в статье sticky-сессия или ротация для профиля антидетекта.
Оставьте запасной вход. Пропавшее хранилище означает потерянный аккаунт. Для каждого аккаунта нужен второй способ входа: второй passkey в другом хранилище, пароль с TOTP или коды восстановления, которые хранятся отдельно от ключа. Microsoft в Entra прямо требует перевести пользователей на устойчивые к фишингу методы до февраля 2027 года. Не ждите, пока окно регистрации перестанет закрываться.
В автоматизации используйте виртуальный аутентификатор. В Chrome DevTools Protocol есть домен WebAuthn. Метод addVirtualAuthenticator создаёт программный аутентификатор с протоколом ctap2 и транспортом internal (платформенный) или usb/hybrid. Параметры hasResidentKey и hasUserVerification включают хранение ключа на аутентификаторе и проверку пользователя. getCredentials после регистрации возвращает ключ целиком: credentialId, rpId, userHandle, signCount и приватный ключ в формате PKCS#8. addCredential при следующем запуске кладёт его обратно. Получается ключ, который живёт только в вашем секрет-хранилище и подключается к сессии конкретного аккаунта. Две оговорки: домен помечен как экспериментальный и создан для тестирования WebAuthn, а выгруженный приватный ключ — это секрет уровня пароля, и хранить его нужно соответственно.
Переносите ключи через Credential Exchange, а не вручную. Если меняете менеджер или разносите аккаунты по разным хранилищам, используйте встроенный экспорт по стандарту FIDO: он поддерживается в Apple Passwords, 1Password, Bitwarden, Dashlane, DuckDuckGo, Devolutions. Учтите, что на macOS часть приложений этот механизм ещё не внедрила.

Подводные камни

Синхронизация по умолчанию. Ключ, созданный «на этом устройстве», может сразу уйти в облако iCloud или Google и появиться на всех устройствах этого аккаунта, в том числе на вашем личном телефоне.
Кросс-девайсный вход по QR. Сценарий «отсканируйте QR телефоном» (транспорт hybrid) подключает к сессии профиля реальный телефон со своими ключами. Для рабочих профилей это лишняя связь.
Одинаковый AAGUID у всей фермы — это нормально. Миллионы людей пользуются одним и тем же менеджером. Опасен не одинаковый провайдер, а общий ключ или общее хранилище.
Passkey не лечит «грязный» вход. Если аккаунт заходит с IP, который уже засветился на соседних аккаунтах, или с датацентра, который площадка не любит, сильная криптография не поможет. Риск оценивается по совокупности сигналов.
Второй фактор тоже нужно изолировать. Если запасной вход — TOTP, секреты тоже раскладываются по аккаунтам, а не лежат в одном приложении на личном телефоне. Как связать 2FA и прокси, мы разбирали в материале о двухфакторной аутентификации в работе через прокси.

Какой прокси нужен и почему

Для входа по ключу важнее всего постоянство: аккаунт должен регистрировать ключ и потом входить по нему из одной и той же сети, в одном гео. Поэтому:

Веб-профили в антидетекте — резидентные прокси с закреплённой сессией в стране аккаунта. Это адреса домашних провайдеров, и они совпадают с легендой «обычный пользователь дома».
Мобильные площадки и аккаунты с мобильной легендой — мобильные прокси. Мобильный профиль, который регистрирует ключ из домашней сети на другом конце страны, выбивается из своей истории.
Ротация на каждый запрос подходит для парсинга, но не для входа в аккаунты. Ставьте интервал с запасом на всю рабочую сессию.

Вывод

Passkeys делают вход устойчивым к фишингу, но переносят точку связи между аккаунтами из cookies и паролей в хранилище ключей. Эта точка часто находится вне профиля антидетекта: в Windows Hello, iCloud, Google-аккаунте или общем хранилище менеджера. Рабочая схема выглядит так: у каждого аккаунта свой профиль, своё хранилище ключа, свой постоянный IP и запасной способ входа. Для автоматизации есть виртуальный аутентификатор в CDP. Займитесь этим до февраля 2027 года, когда Microsoft перестанет давать отложить регистрацию. Потом разбираться придётся в спешке и прямо на живых аккаунтах.