Описание Device Bound Session Credentials (DBSC)

Whitepaper по Passkey для Enterprise. Практические рекомендации, шаблоны внедрения и KPI для программ passkeys.

Получить whitepaper

Статус поддержки браузерами

Легенда: ✅ В общем доступе | 🚧 Анонсировано / в разработке | ⏸️ Тестирование завершено | 🔄 Оценивается/отслеживается | ❌ Пока недоступно

Примечание: DBSC находится в статусе GA на Windows с TPM начиная с Chrome 146 (апрель 2026 г.). Поддержка macOS через Secure Enclave развертывается следующей. Заявленная дорожная карта Google также включает программные ключи для расширения защиты на устройства без выделенного защищенного оборудования.

Ключевые преимущества: DBSC в сравнении с текущей моделью

Архитектура Всемирной паутины была основана на принципе отсутствия состояния. Когда HTTP был впервые разработан, он не сохранял информацию о пользователях между запросами. Чтобы решить эту проблему, был изобретен "файл cookie" - небольшой фрагмент данных, отправляемый с веб-сайта и хранящийся на компьютере пользователя, чтобы отправлять его обратно на веб-сайт с каждым последующим запросом. На протяжении десятилетий этот механизм служил основой управления сессиями. Когда пользователь входит в систему, сервер проверяет его учетные данные и выдает файл cookie. Этот файл cookie действует как "токен на предъявителя". В физическом мире документ на предъявителя дает держателю права на активы, которые он представляет; если вы держите облигацию, вы владеете облигацией. Аналогично, в цифровом мире HTTP, если вы держите файл cookie, вы являетесь пользователем.

Эта возможность предъявления является одновременно величайшей полезностью Интернета и его самой глубокой уязвимостью. Безопасность всей сессии - и, следовательно, личности пользователя, данных и финансовых активов - полностью зависит от секретности этой строки cookie. Если злоумышленник сможет скопировать эту строку, он сможет выдать себя за пользователя с любого устройства, в любой точке мира, полностью обходя первоначальные проверки аутентификации. Эта специфическая уязвимость породила теневую экономику промышленных масштабов, связанную с "кражей файлов cookie" и "перехватом сессий".

По мере того, как отрасль успешно укрепляет "парадную дверь" аутентификации путем внедрения стандартов FIDO (Fast Identity Online) и ключей доступа, злоумышленники переносят свое внимание на "черный ход": активную сессию. Выудить пароль становится сложнее, но кража сессионного файла cookie остается опасно эффективной. Ответ отрасли на эту растущую угрозу - Device Bound Session Credentials (DBSC).

DBSC представляет собой сдвиг парадигмы в том, как поддерживаются веб-сессии. Он предлагает отойти от простых токенов на предъявителя к модели, где сессия криптографически привязана к устройству. С выходом Chrome 146 (апрель 2026 г.), предоставляющего DBSC в GA на Windows, стандарт перешел от экспериментального к производственному потенциалу, который веб-команды могут развернуть уже сегодня. Chrome использует TPM на Windows и внедряет поддержку Secure Enclave на macOS; сама спецификация не зависит от способа хранения ключей, требуя только, чтобы оно было "надежным против описанной угрозы". Это делает украденные файлы cookie гораздо менее ценными. Их невозможно обновить с другого устройства без привязанного ключа.

В этой статье представлен исчерпывающий анализ DBSC, предназначенный для архитекторов безопасности, менеджеров по продуктам и разработчиков. В ней рассматривается техническая архитектура, бизнес-последствия "безопасности без трения", связь с новыми стандартами, такими как Shared Signals (CAEP/RISC), и то, как организации могут подготовиться к этому будущему с помощью платформ, таких как Corbado.

Ключевые вопросы, на которые отвечает эта статья

1. Почему текущее управление сессиями не может предотвратить захват аккаунтов?
2. Чем DBSC отличается от существующих "безопасных" файлов cookie и флагов HttpOnly?
3. Как DBSC и ключи доступа работают вместе для более надежной защиты от фишинга?
4. Что случилось с Token Binding и почему DBSC добивается успеха там, где она потерпела неудачу?
5. Каковы бизнес-последствия и ROI для менеджеров по продуктам?
6. Какие браузеры и операционные системы поддерживают DBSC сегодня?
7. Как организации могут внедрить DBSC, не создавая все с нуля?
8. Какова связь между DBSC, DPoP и OAuth 2.0?
9. Как DBSC интегрируется с Shared Signals (CAEP/RISC) для реагирования на угрозы в реальном времени?

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

Фундаментальный провал текущего управления сессиями заключается в "портативности" доверия. Когда сервер выдает сессионный файл cookie, он по сути выдает паспорт, который работает для любого, кто им владеет. Хотя браузеры внедрили средства защиты, такие как флаги HttpOnly и Secure (предотвращающие доступ JavaScript и обеспечивающие передачу по HTTPS), эти средства защиты помогают только от специфических векторов извлечения, таких как межсайтовый скриптинг (XSS) или сетевой сниффинг. Они не обеспечивают защиту от вредоносного ПО, работающего на устройстве хоста. "Инфостилеры" - это вредоносное ПО, специально разработанное для поиска файла хранилища cookie браузера на диске, его расшифровки (часто с использованием собственных учетных данных пользователя на уровне ОС) и эксфильтрации содержимого на командно-контрольный сервер. Как только злоумышленник завладевает файлом cookie, он может выполнить атаку Pass-the-Cookie, внедряя украденный токен в свой собственный браузер для перехвата сессии. Сервер, видя действительный файл cookie, предполагает, что запрос является легитимным.

DBSC вводит второй фактор аутентификации в сам цикл обслуживания сессии. В отличие от стандартного безопасного файла cookie, который представляет собой статический секрет, сессия DBSC состоит из кратковременного токена на предъявителя и криптографического доказательства владения. Браузер генерирует пару открытого и закрытого ключей, надежно хранящуюся на устройстве. Сервер привязывает сессию к открытому ключу. Периодически браузер должен доказывать, что он все еще владеет закрытым ключом, подписывая вызов (challenge) от сервера. Спецификация требует хранения ключей, "надежного против описанной угрозы". Chrome использует TPM на Windows, когда он доступен. Если злоумышленник крадет файл cookie с другого устройства, он не может его обновить, потому что не может сгенерировать необходимую криптографическую подпись. Аспект "предъявителя" сведен к очень короткому окну, в то время как аспект "привязки" обеспечивает долгосрочную непрерывность.

Ключи доступа и DBSC - это взаимодополняющие технологии, которые защищают разные этапы жизненного цикла пользователя. Ключи доступа (FIDO2) решают проблему аутентификации, доказывая личность для начала сессии без паролей, тем самым устраняя фишинг учетных данных. DBSC решает проблему после аутентификации, делая перехват сессии посредством кражи файлов cookie значительно сложнее. FIDO Alliance позиционирует DBSC как взаимодополняющую технологию, которая "повышает планку" против перехвата сессий. Вместе они сокращают поверхность атаки на протяжении всего жизненного цикла входа и сессии, хотя DBSC не защищает от вредоносного ПО с постоянным доступом к устройству или атак браузера в середине (browser-in-the-middle) в реальном времени на том же устройстве.

Как ключи доступа и DBSC работают вместе

DBSC - это не первая попытка решить эту проблему. "Token Binding" был предыдущим стандартом, который пытался привязать файлы cookie к базовому соединению TLS (Transport Layer Security). Хотя криптографически надежный, Token Binding не получил распространения из-за его сильной зависимости от уровня TLS. В современном Интернете соединения TLS часто оканчиваются на балансировщиках нагрузки, CDN или обратных прокси, в то время как логика приложения находится на серверах за ними. Распространение информации Token Binding через эти сложные сетевые уровни оказалось слишком сложным. DBSC извлекает уроки из этой неудачи, работая исключительно на прикладном уровне (HTTP). Он не зависит от базового сетевого соединения, что делает его совместимым с существующими балансировщиками нагрузки, прокси и облачной инфраструктурой.

Для руководителей продуктов DBSC предлагает возможность повысить безопасность, одновременно улучшая пользовательский опыт (UX). Традиционно высокая безопасность означала короткие тайм-ауты сессий, заставляя пользователей часто входить в систему (трение). Благодаря привязке сессии к устройству, риск удаленной кражи файла cookie значительно снижается. Бизнес может рассмотреть более длительные сессии, зная, что украденные файлы cookie нельзя обновить с другого устройства. Однако DBSC не защищает от кражи устройства, постоянного вредоносного ПО на устройстве или злоупотреблений со стороны вредоносного пользователя, поэтому политики времени жизни сессии все равно должны отражать эти остаточные риски.

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

graph TD
    A[Пользователь загружает<br/>вредоносное ПО] -->|Выполнение| B[Инфостилер активируется<br/>на устройстве]
    B --> C[Находит данные браузера]
    C --> D[Хранилище cookie<br/>Chrome/Edge/Firefox]
    C --> E[База данных паролей]
    C --> F[Криптокошельки]

    D --> G[Расшифровывает, используя<br/>учетные данные ОС]
    E --> G
    F --> G

    G --> H[Создает файл журнала (лог)<br/>с украденными данными]
    H --> I[Эксфильтрация на C2-сервер]
    I --> J[Торговая площадка Даркнета]

    J --> K[Злоумышленник покупает лог]
    K --> L[Импортирует cookie<br/>в свой браузер]
    L --> M[Обходит MFA]
    M --> N[Захват аккаунта<br/>завершен]

    style A fill:#ff6b6b,color:#fff
    style B fill:#ff6b6b,color:#fff
    style N fill:#ff6b6b,color:#fff
    style J fill:#495057,color:#fff
    style M fill:#ffd43b,color:#000

Модель "Вредоносное ПО как услуга" (MaaS) снизила входной барьер для киберпреступников. "Инфостилеры", такие как RedLine, Raccoon, Vidar и Taurus, представляют собой коммерчески доступные штаммы вредоносного ПО, разработанные с одной главной целью: эксфильтрация данных из веб-браузеров. Эти стилеры распространяются через фишинговые электронные письма, взломанное ПО или вредоносную рекламу. После установки они нацеливаются на определенные пути к файлам, где браузеры, такие как Chrome, Edge и Firefox, хранят свои данные.

• Цель: База данных файлов cookie (обычно файл SQLite) и база данных Login Data (сохраненные пароли).
• Механизм: Браузеры шифруют эти базы данных с помощью API защиты данных (DPAPI на Windows), привязанных к логину пользователя в ОС. Поскольку вредоносное ПО запускается от имени пользователя, оно может тривиально запросить расшифровку этих файлов.
• Результат: Вредоносное ПО генерирует "лог" — zip-архив, содержащий расшифрованные файлы cookie, пароли, информацию о системе, а иногда ключи криптокошельков.

Эти логи агрегируются и продаются на теневых торговых площадках, таких как Genesis Market (до его закрытия) и Russian Market. Покупатели могут искать логи, содержащие активные файлы cookie для конкретных ценных целей: "Salesforce", "Gmail", "Bank of America" или "AWS Console".

Обход: Ценность лога файлов cookie заключается в его способности обходить многофакторную аутентификацию (MFA). Большинство запросов MFA (SMS, TOTP, Push) происходят только во время события входа. Как только сессия установлена и файл cookie выдан, сервер предполагает, что пользователю можно доверять. Злоумышленник, импортирующий действительный сессионный файл cookie, проскальзывает мимо ворот MFA, представая перед сервером как пользователь, вернувшийся на активную вкладку.

Облачные пакеты для повышения производительности являются первоочередными целями. Украденный сессионный файл cookie для аккаунта Google Workspace или Microsoft Entra ID (ранее Azure AD) может предоставить злоумышленнику доступ к корпоративной электронной почте, документам и внутренним системам. Собственная служба анализа угроз Google сообщила о массовом всплеске кражи файлов cookie как основного вектора доступа к аккаунтам Google, явно назвав это стимулом для их инвестиций в DBSC. Они отмечают, что, поскольку они принудительно включают двухэтапную аутентификацию (2SV) и ключи доступа, злоумышленники просто сменили тактику с фишинга учетных данных (которую предотвращает 2SV / ключи доступа) на кражу файлов cookie (которую 2SV / ключи доступа часто не останавливают).

Исторически системы оценки рисков пытались обнаружить кражу сессии путем анализа цифровых отпечатков устройств, проверяя строку User-Agent, разрешение экрана, установленные шрифты и IP-адрес. Если сессионный файл cookie внезапно появляется с нового IP-адреса с немного отличающимся отпечатком canvas, сервер может сделать его недействительным. Проблема: Инициативы по обеспечению конфиденциальности в браузерах (такие как Intelligent Tracking Prevention от Safari и Privacy Sandbox от Chrome) активно снижают энтропию этих отпечатков, чтобы остановить отслеживание рекламы. Это делает "хорошее" снятие отпечатков для безопасности все более сложным. Более того, злоумышленники теперь используют "Anti-Detect браузеры", которые позволяют им идеально подделывать эти отпечатки, чтобы они соответствовали профилю жертвы, делая эвристическое обнаружение неэффективным. DBSC заменяет эту вероятностную игру в угадывание детерминированным криптографическим доказательством.

Device Bound Session Credentials (DBSC) представляет собой стандартизированный API и протокол для создания сессий, привязанных к ключу на устройстве клиента. Спецификация требует хранения ключей, "надежного против описанной угрозы", но не зависит от реализации. Chrome использует TPM на Windows, когда он доступен. В этом разделе подробно описываются механизмы, как они определены в рабочем проекте W3C и документации Chrome.

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

sequenceDiagram
    participant User as Пользователь
    participant Browser as Браузер
    participant HSM as HSM (TPM/Secure Enclave)
    participant Server as Сервер

    Note over User,Server: Фаза 1: Аутентификация и привязка
    User->>Browser: Вход с учетными данными/ключом доступа
    Browser->>Server: Запрос аутентификации
    Server->>Browser: Успех + заголовок регистрации DBSC
    Browser->>HSM: Генерация пары ключей
    HSM->>Browser: Открытый/Закрытый ключ (закрытый неэкспортируемый)
    Browser->>Server: Регистрация открытого ключа (подписанный JWT)
    Server->>Server: Привязка сессии к открытому ключу
    Server->>Browser: Кратковременный cookie (5 мин)

    Note over User,Server: Фаза 2: Обычное использование
    loop Каждый запрос в течение 5 минут
        Browser->>Server: Запрос с cookie
        Server->>Browser: Ответ
    end

    Note over User,Server: Фаза 3: Обновление (после истечения срока)
    Browser->>Server: Запрос с истекшим cookie
    Server->>Browser: 401 + Nonce вызова
    Browser->>HSM: Подпись вызова
    HSM->>Browser: Подпись
    Browser->>Server: Доказательство подписи
    Server->>Server: Проверка с сохраненным открытым ключом
    Server->>Browser: Новый кратковременный cookie
    Browser->>Server: Повтор исходного запроса
    Server->>Browser: Ответ об успехе

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

1. Сигнал сервера: После успешного входа сервер устанавливает сессионный файл cookie (как обычно), но добавляет специальный заголовок, указывающий на поддержку DBSC.

   HTTP
   HTTP/1.1 200 OK
   Set-Cookie: session_id=xyz123...; Secure; HttpOnly; SameSite=Strict
   Secure-Session-Registration: (ES256 RS256); path="/auth/dbsc/register"
   

   • Заголовок Secure-Session-Registration сообщает браузеру: "Я поддерживаю алгоритмы ES256 и RS256. Пожалуйста, зарегистрируйте привязанную сессию на конечной точке /auth/dbsc/register."

2. Генерация ключей: Браузер парсит этот заголовок. Он генерирует новую пару асимметричных ключей (например, на эллиптических кривых P-256), которая надежно хранится на устройстве.

   • Примечание по реализации: Chrome использует TPM на Windows, когда он доступен; спецификация не зависит от механизма хранения, требуя только, чтобы оно было "надежным против описанной угрозы".
   • Область конфиденциальности: Ключ привязан к источнику (origin) веб-сайта (например, bank.com). Браузер гарантирует, что этот ключ никогда не будет использоваться для retailer.com, предотвращая межсайтовое отслеживание.

3. Запрос регистрации: Браузер отправляет запрос по указанному пути регистрации. Этот запрос включает только что сгенерированный Открытый ключ внутри JSON Web Token (JWT), подписанный Закрытым ключом (самоподписанное свидетельство).

   HTTP
   POST /auth/dbsc/register HTTP/1.1
   Content-Type: application/jwt
   
   \<JWT Header\>.\<JWT Payload containing Public Key\>.\<Signature\>
   

4. Привязка сессии: Сервер проверяет подпись, чтобы убедиться в работоспособности открытого ключа. Затем он обновляет свою базу данных, чтобы связать сессию пользователя (session_id=xyz123) с этим конкретным открытым ключом. С этого момента сессия становится "привязанной".

Чтобы сбалансировать безопасность и производительность (операции с безопасными ключами могут добавлять задержку), DBSC использует систему с двумя токенами.

1. Выдача: Сервер выдает новый, кратковременный файл cookie (например, действительный в течение 5 минут). Назовем его access_token.
2. Использование: Браузер использует этот access_token для всех обычных запросов (получение изображений, вызовы API, навигация по страницам). Пока файл cookie действителен, никакие криптографические операции не выполняются. Это обеспечивает быструю работу в Интернете.
3. Истечение срока: Через 5 минут access_token истекает.

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

1. Обнаружение: Браузер пытается выполнить запрос. Он замечает, что срок действия файла cookie истек (или сервер возвращает 401 или специальный заголовок Secure-Session-Challenge).
2. Перехват: Браузер приостанавливает сетевой запрос. Он не показывает ошибку пользователю.
3. Запрос на обновление: Браузер автоматически вызывает конечную точку обновления, определенную в конфигурации сессии.
   • Сервер отправляет криптографический Вызов (challenge) (nonce).
   • Браузер использует привязанный ключ для подписания этого вызова.
   • Подпись подтверждает владение закрытым ключом.
4. Отправка: Браузер отправляет подписанный вызов обратно на сервер.

   HTTP
   POST /auth/dbsc/refresh HTTP/1.1
   Sec-Secure-Session-Id: \<Session ID\>
   Secure-Session-Response: \<JWT Signature of Challenge\>
   

5. Проверка: Сервер использует сохраненный Открытый ключ для проверки подписи.
   • Если действительна: Сервер знает, что запрос поступает с того же физического устройства, которое начало сессию. Он выдает новый кратковременный access_token (действительный еще 5 минут).
   • Если недействительна: Запрос отклоняется. Сессия прерывается.
6. Возобновление: Браузер берет новый файл cookie и прозрачно повторяет исходный приостановленный запрос. Пользователь не замечает никаких прерываний.

graph LR
    subgraph "Устройство жертвы"
        A[Сессия пользователя<br/>с DBSC]
        B[Закрытый ключ<br/>HSM/TPM]
        C[Cookie +<br/>ID сессии]
        A --> B
        A --> C
        B -.->|Неэкспортируемый| X[Невозможно извлечь<br/>Закрытый ключ]
    end

    subgraph "Сценарий атаки"
        D[Стилер RedLine<br/>заражает устройство]
        D --> E[Крадет Cookie<br/>и ID сессии]
        E --> F[Экспорт к<br/>злоумышленнику]
    end

    subgraph "Устройство злоумышленника"
        G[Импортирует украденный<br/>Cookie]
        H[Пытается<br/>использовать сессию]
        I[Сервер запрашивает<br/>обновление DBSC]
        J[Невозможно подписать<br/>вызов]
        K[В сессии отказано]

        G --> H
        H --> I
        I --> J
        J --> K
    end

    C -.->|Украдено| E
    F --> G

    style D fill:#ff6b6b,color:#fff
    style K fill:#51cf66,color:#fff
    style B fill:#4c6ef5,color:#fff
    style X fill:#51cf66,color:#fff
    style J fill:#ff6b6b,color:#fff

Представьте злоумышленника, который заражает ПК пользователя стилером RedLine. Он крадет access_token и session_id. Он импортирует их в свой собственный браузер.

• Сценарий А (в течение 5 минут): Злоумышленник может получить доступ на несколько минут, пока не истечет срок действия кратковременного токена.
• Сценарий Б (после истечения срока): Браузер злоумышленника (на другом устройстве) пытается использовать токен. Сервер отклоняет его и требует обновления. Браузер злоумышленника видит заголовки DBSC, но не может выполнить обновление, поскольку у него нет привязанного закрытого ключа. Атака терпит неудачу.

Конфиденциальность — это центральная цель при проектировании DBSC. Спецификация W3C явно запрещает использование глобальных идентификаторов, которые могли бы отслеживать пользователей на разных сайтах.

• Ключи для каждого источника: Браузер генерирует уникальную пару ключей для каждого сайта. google.com видит Ключ А; amazon.com видит Ключ Б. Между ними нет никакой связи.
• Очистка данных пользователя: Если пользователь удаляет свои файлы cookie/данные сайтов, браузер также удаляет связанные ключи DBSC. Это гарантирует, что DBSC не может быть использован как "супер-cookie" для восстановления удаленных идентификаторов.

Внедрение DBSC требует от сервера сохранения состояния об открытых ключах.

• Схема базы данных: Таблица сессий должна быть обновлена для хранения public_key и last_challenge наряду с user_id и session_expiry.
• Производительность: Операция обновления включает криптографическую проверку (например, проверку подписи ECDSA). Хотя она и быстрая, она более требовательна к процессору, чем проверка простой строки. Однако, поскольку обновления происходят только каждые несколько минут (а не при каждом запросе), накладные расходы незначительны.

Помимо технических спецификаций, DBSC несет в себе значительные последствия для бизнес-стратегии, дорожных карт продуктов и соответствия нормативным требованиям.

Инициативы по обеспечению безопасности часто рассматриваются как центры затрат или генераторы трения. DBSC переворачивает этот нарратив. Следующая диаграмма иллюстрирует, как привязка к устройству создает каскад бизнес-преимуществ:

• Снижение уровня мошенничества: Нейтрализуя основной вектор захвата аккаунта (ATO), компании могут сэкономить миллионы на убытках от мошенничества.
• Затраты на поддержку: Восстановление аккаунта обходится дорого. Предотвращение взлома в первую очередь напрямую снижает это операционное бремя.
• Оптимизация конверсии: В электронной коммерции каждый запрос на вход является потенциальной точкой отсева. DBSC позволяет применять агрессивную политику "оставаться в системе", обеспечивая мгновенное оформление заказа без запросов пароля.

Нормативные базы, такие как GDPR (Общий регламент по защите данных) в Европе, требуют от организаций внедрения "надлежащих технических и организационных мер" для обеспечения безопасности.

• Доказуемая безопасность: По мере того, как DBSC становится стандартом, он, вероятно, будет интерпретироваться как "современный уровень техники" для управления сессиями. В случае нарушения демонстрация того, что был внедрен DBSC, может стать мощной защитой от обвинений в халатности.
• Банковские стандарты (PSD2): Вторая директива о платежных услугах требует "Строгой аутентификации клиента" (SCA). Хотя SCA сосредоточена на входе в систему, динамическое связывание сессии с устройством идеально согласуется с целями директивы по привязке аутентификации к конкретным суммам и получателям.

Белые книги FIDO Alliance выделяют концепцию "Уровней уверенности" (Assurance Levels).

• Умеренная уверенность: Использует синхронизированные ключи доступа (например, такие, как в Связке ключей iCloud). Отлично подходит для потребительских приложений, восстанавливается, просто в использовании.
• Высокая уверенность: Требует привязанных к устройству ключей. В этом DBSC проявляет себя наилучшим образом. Для корпоративных ресурсов (HR-порталы, репозитории кода) или ценного банкинга организация может применять политику, которая только разрешает доступ из сессий, привязанных к конкретному управляемому устройству. DBSC обеспечивает технический механизм соблюдения этой политики.

Чтобы полностью оценить DBSC, мы должны сравнить его с другими технологиями, которые пытались решить аналогичные проблемы.

graph RL
    subgraph "Традиционные файлы cookie"
        TC1[Только токен на предъявителя]
        TC2[Уязвимость к краже]
        TC3[Долгие сессии = Риск]
        TC1 --> TC2
        TC2 --> TC3
    end

    subgraph "Token Binding"
        TB1[Привязка на уровне TLS]
        TB2[❌ Провал: Сложная инфраструктура]
        TB3[Поломка на балансировщиках нагрузки]
        TB1 --> TB2
        TB2 --> TB3
    end

    subgraph "DPoP"
        DP1[Привязка токенов OAuth]
        DP2[✅ Защита API]
        DP3[Не для сессий браузера]
        DP1 --> DP2
        DP2 --> DP3
    end

    subgraph "DBSC"
        D1[Привязка на уровне HTTP]
        D2[✅ Защита аппаратным ключом]
        D3[✅ Работает с CDN/Балансировщиками]
        D4[✅ Сессии браузера]
        D1 --> D2
        D2 --> D3
        D3 --> D4
    end

    style TC2 fill:#ff6b6b,color:#fff
    style TB2 fill:#ff6b6b,color:#fff
    style D2 fill:#51cf66,color:#fff
    style D3 fill:#51cf66,color:#fff
    style D4 fill:#51cf66,color:#fff
    style DP2 fill:#51cf66,color:#fff

Как упоминалось ранее, Token Binding пытался привязать сессию к уровню TLS.

• Token Binding: Требовал поддержки от клиента, сервера и каждого перехода между ними (Балансировщики нагрузки, Терминаторы TLS). Он ломался, когда соединение обрывалось и зашифровывалось заново.
• DBSC: Работает на прикладном уровне HTTP. Он прозрачно проходит через балансировщики нагрузки как стандартные заголовки/файлы cookie. Его гораздо проще развернуть в современных облачных архитектурах (AWS/GCP/Azure), где TLS часто обрабатывается граничной сетью облачного провайдера.

DPoP (RFC 9449) — это стандарт для токенов OAuth, "ограниченных отправителем" (sender-constrained). Он привязывает как токены доступа, так и токены обновления к открытому ключу — что критически важно, поскольку токены обновления сами по себе являются долгоживущими учетными данными на предъявителя. Каждый запрос API включает доказательство DPoP: подписанный JWT с HTTP-методом, URL, временной меткой и уникальным идентификатором. Спецификации с высокой степенью уверенности, такие как FAPI 2.0, требуют использования токенов, ограниченных отправителем; DPoP является рекомендуемым методом, когда mTLS недоступен.

Ключевое отличие: Ключи DPoP живут в контексте приложения. Лучшей практикой является использование API ОС для неэкспортируемого хранения, но это не является обязательным — многие реализации хранят ключи в памяти, доступной для JavaScript. Если злоумышленник может выполнить произвольный код (XSS, вредоносное ПО), он может получить доступ к ключам DPoP или генерировать доказательства по требованию. DPoP останавливает воспроизведение токенов между разными клиентами, но не может защитить скомпрометированный контекст браузера.

DBSC переносит доказательство владения в браузер и на аппаратный уровень. Закрытый ключ живет в TPM или безопасном анклаве (Secure Enclave), который JavaScript не может прочитать или экспортировать. Браузер обрабатывает протокол и создает подписи, не раскрывая ключи коду приложения. Даже если веб-приложение полностью скомпрометировано, злоумышленник не может создавать новые доказательства для украденных файлов cookie на другой машине.

Синергия: Как отмечает FIDO Alliance, ключи доступа устраняют фишинг при входе, в то время как DBSC/DPoP защищают токены после аутентификации. Современная архитектура сочетает и то, и другое: DPoP для API OAuth (особенно в регулируемом открытом банкинге), DBSC для сессий в браузере. Вместе они закрывают вектор атаки "lift and shift" на протяжении всего жизненного цикла сессии.

Простое сокращение времени жизни файлов cookie (например, до 15 минут) повышает безопасность, но разрушает UX. Пользователи вынуждены постоянно авторизовываться. DBSC обеспечивает эффективную безопасность 5-минутного файла cookie с пользовательским опытом 30-дневного файла cookie.

%%{init: {
  "theme": "default",
  "themeVariables": {
    "actorBkg": "#ffffff",
    "actorBorder": "#000000",
    "noteBkgColor": "#f1f3f5",
    "noteTextColor": "#000000",
    "activationBkgColor": "#e0e0e0",
    "actorColours": {
      "ST": "#ff6b6b",
      "IdP": "#4c6ef5"
    }
  }
}}%%

sequenceDiagram
    participant ST as Средства безопасности<br/>(CrowdStrike, Defender)
    participant IdP as Поставщик удостоверений<br/>(Okta, Google, Azure)
    participant SP1 as Провайдер услуг 1<br/>(Slack)
    participant SP2 as Провайдер услуг 2<br/>(Salesforce)
    participant SP3 as Провайдер услуг 3<br/>(Банковское приложение)
    participant Session as Сессия пользователя<br/>(Защищена DBSC)

    Note over ST,Session: Фаза обнаружения угрозы
    ST->>ST: Обнаруживает вредоносное ПО на<br/>устройстве пользователя
    ST->>IdP: Сигнал RISC:<br/>"Устройство скомпрометировано"

    Note over IdP,SP3: Фаза распространения сигнала
    IdP->>SP1: Событие CAEP:<br/>"Устройство скомпрометировано"
    IdP->>SP2: Событие CAEP:<br/>"Устройство скомпрометировано"
    IdP->>SP3: Событие CAEP:<br/>"Устройство скомпрометировано"

    Note over SP1,Session: Фаза применения (с DBSC)
    Session->>SP1: Следующая попытка обновления<br/>(в течение минут)
    SP1-->>Session: x Отклонить подпись
    Session->>SP2: Следующая попытка обновления
    SP2-->>Session: x Отклонить подпись
    Session->>SP3: Следующая попытка обновления
    SP3-->>Session: x Отклонить подпись

    Note over Session: Сессии могут быть прерваны при следующей попытке обновления

Потенциал DBSC усиливается в сочетании с Shared Signals Framework (SSF), в частности, с Continuous Access Evaluation Profile (CAEP) и Risk Management (RISC). Примечание: SSF/CAEP — это развивающаяся возможность экосистемы — архитектурный шаблон определен, но широкое кросс-вендорное развертывание все еще находится в стадии развития.

В старой модели, если устройство пользователя было скомпрометировано, поставщик удостоверений (IdP) никак не мог сказать провайдеру услуг (SP) прервать сессию прямо сейчас. SP приходилось ждать, пока истечет срок действия файла cookie.

Предполагаемый рабочий процесс DBSC + CAEP:

1. Триггер: Средство безопасности конечной точки (например, CrowdStrike или Microsoft Defender) обнаруживает вредоносное ПО на ноутбуке пользователя.
2. Сигнал: Средство безопасности отправляет сигнал RISC поставщику удостоверений (например, Okta/Google).
3. Распространение: IdP передает событие CAEP подключенным приложениям: "Устройство скомпрометировано".
4. Применение (DBSC): В следующий раз, когда браузер попытается обновить кратковременный файл cookie DBSC, сервер отклонит подпись и прервет сессию.
   Этот архитектурный шаблон обеспечивает более быстрый отзыв — фактическая задержка зависит от периода обновления сайта и от того, реализованы ли на нем как DBSC, так и SSF.

Внедрение DBSC зависит от разработчиков браузеров. Ситуация в 2026 году существенно изменилась: Chrome перевел DBSC из стадии Origin Trial в общий доступ на Windows в апреле 2026 года, а macOS станет следующей. Другие браузеры все еще оценивают технологию.

Google является главным драйвером DBSC и первым браузером, который широко его внедряет.

• Статус (апрель 2026 г.): Chrome 146 выпускает DBSC в общий доступ на Windows, завершая стадию Origin Trial. Поддержка macOS с использованием Secure Enclave анонсирована для одного из следующих выпусков Chrome.
• Оборудование: Windows использует TPM, macOS будет использовать Secure Enclave. Google заявила, что также изучает программные ключи для расширения защиты DBSC на устройства без выделенного защищенного оборудования.
• Дорожная карта: Объявление Google о GA также опубликовало план следующих шагов:
  • Защита федеративной идентификации: кросс-доменные привязки DBSC, чтобы сессия опирающейся стороны (RP) оставалась привязанной к тому же ключу устройства, что и сессия поставщика удостоверений (IdP), сохраняя непрерывную цепочку доверия через SSO.
  • Расширенная регистрация: привязка сессий DBSC к ранее существовавшим доверенным ключевым материалам, таким как сертификаты mTLS или аппаратные ключи безопасности, вместо генерации нового ключа при входе.
  • Более широкая поддержка устройств: программные ключи для устройств без TPM / Secure Enclave.
• Операционные результаты: Во время развертывания Google сообщает о "значительном сокращении краж сессий" для сессий, защищенных DBSC.
• Аккаунты Google: Отдельно Google уже внедрила защиту в стиле DBSC для файлов cookie аккаунтов Google в Chrome для Windows, которая контролируется корпоративной политикой. Это защищает Gmail/Workspace и теперь является тем же самым семейством технологий, которое доступно в GA для всего веба.

Microsoft принимает активное участие.

• Статус: Edge проводил Origin Trial DBSC на Windows, которое завершилось в октябре 2025 года. О новом тестировании или GA не объявлялось.
• Корпоративный контекст: Edge использует архитектуру "Primary Refresh Token" (PRT) для Entra/Azure AD SSO, которая концептуально схожа с DBSC. PRT остается специфичным механизмом Microsoft; нет никаких заявленных планов по его объединению с веб-стандартом DBSC для сторонних сайтов.

Позиция Apple критически важна для охвата мобильных устройств.

• Статус: В WebKit есть проблема (issue) с позицией по стандартам, в которой оценивается DBSC с отмеченными опасениями по поводу удобства использования и конфиденциальности. В примечаниях к выпуску Safari DBSC не упоминается. Нет публичных заявлений об "активной реализации".
• Конфиденциальность прежде всего: Главное опасение Apple заключается в том, что DBSC можно использовать для создания "супер-cookie" (неудаляемого отслеживания). Спецификация W3C решает эту проблему, гарантируя очистку ключей вместе с данными веб-сайта.
• Взаимодействие: WebKit участвует в процессе стандартизации, но статус реализации неясен — "обсуждается", а не "в разработке".

Mozilla имеет проблему (issue) с позицией по стандартам, оценивающую DBSC с отмеченными опасениями по поводу сложности и конфиденциальности. Нет никаких публичных обязательств по внедрению после стабилизации стандарта.

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

1. Сначала разверните ключи доступа: Начните с внедрения ключей доступа для защиты уровня аутентификации. Это обеспечивает немедленную защиту от фишинга учетных данных и является предварительным условием для получения реальной выгоды от DBSC.

2. Запустите конечные точки регистрации и обновления DBSC: С выходом Chrome 146 GA реалистичная задача сейчас — это бэкенд-интеграция: добавление заголовков Secure-Session-Registration в ответы при входе в систему и реализация /dbsc/register плюс конечной точки обновления, которая проверяет подписанные вызовы. Код фронтенда менять не нужно.

3. Внедрите короткоживущие сессии с токенами обновления: Если вы еще не готовы к DBSC, примите архитектурный паттерн короткоживущих токенов с механизмами обновления. Это подготовит ваш бэкенд к DBSC, одновременно повысив безопасность уже сегодня.

1. Примите гибридный подход: Используйте обнаружение функций для предоставления DBSC совместимым браузерам (в настоящее время Chrome 146+ на Windows, далее macOS Secure Enclave), сохраняя при этом запасные варианты (fallback). Это максимизирует безопасность, не исключая пользователей в Safari, Firefox или Edge.

2. Подготовьтесь к следующим пунктам дорожной карты: Google явно указала федеративную идентификацию (кросс-доменные привязки SSO), расширенную регистрацию (mTLS / аппаратные ключи) и программные ключи для более широкого охвата устройств. Если вы управляете SSO или уровнем IdP, начните планировать кросс-доменную привязку уже сейчас.

3. Интегрируйтесь с поставщиками удостоверений: Если вы используете Okta, Auth0 или подобные IdP, поработайте с ними, чтобы включить поддержку DBSC в их SDK. Многие из них участвовали в Origin Trials и активно выпускают возможности DBSC теперь, когда Chrome находится в GA.

• Начните с ценных целей: Отдайте приоритет DBSC для панелей администратора, финансовых транзакций и доступа к конфиденциальным данным.
• Используйте управляемые решения: Рассмотрите платформы вроде Corbado, которые берут на себя сложность реализации DBSC и совместимости браузеров.
• Измеряйте и улучшайте: Отслеживайте такие метрики, как попытки перехвата сессий, обращения в службу поддержки и трение пользователей, чтобы продемонстрировать ROI.
• Подготовьтесь к соблюдению нормативов: Документируйте вашу реализацию DBSC, поскольку она, вероятно, станет нормативным требованием для обработки конфиденциальных данных.

Внедрение DBSC с нуля — это тяжелая инженерная задача. Она требует криптографической экспертизы, глубоких знаний о несоответствиях браузеров и надежной серверной инфраструктуры для управления ключами и вызовами. Именно здесь Corbado выступает в роли вспомогательного инструмента.

Вы не можете построить сессию с высокой степенью уверенности поверх логина с низкой степенью уверенности. Если пользователь входит в систему со слабым паролем, сессия безопасна ровно настолько, насколько безопасен этот пароль. Основной продукт Corbado (управляемые ключи доступа) обеспечивает необходимый фундамент. Интегрируя Corbado, организации могут легко развертывать ключи доступа, гарантируя, что начало сессии устойчиво к фишингу.

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

• Решение неоднозначности синхронизированных ключей доступа: Синхронизированные ключи доступа удобны, но создают пробел в доверии: когда пользователь аутентифицируется с помощью синхронизированного ключа доступа, вы не можете сказать, его ли это обычный ноутбук или совершенно новое устройство, которое только что синхронизировало учетные данные. DBSC закрывает этот пробел. Проверив, имеет ли устройство установленную привязку DBSC, Corbado может убедиться, что устройство действительно известно и пользуется доверием, а не просто синхронизируется впервые.
• Более высокое доверие к известным устройствам: Когда сигналы DBSC подтверждают, что устройство уже было замечено ранее, Corbado может принимать более уверенные решения о рисках: меньше запросов на пошаговую аутентификацию (step-up authentication) для легитимных возвращающихся пользователей, более строгая проверка для сессий с нераспознанных устройств.
• Дополнение к Passkey Intelligence: Сигналы DBSC интегрируются с существующим механизмом Passkey Intelligence от Corbado. Сочетание аутентификации на основе ключей доступа и привязки устройства на основе DBSC создает полную цепочку доверия от входа в систему через весь жизненный цикл сессии.

По вопросам о том, как Corbado планирует интегрировать DBSC в свою платформу, свяжитесь с командой.

В течение следующих нескольких лет Интернет будет гибридным. У некоторых пользователей будут браузеры, поддерживающие DBSC (Chrome на Windows 11); другие будут на старых системах. Справиться с этой фрагментацией сложно. Механизм Passkey Intelligence от Corbado разработан именно для обработки такой логики отката — обслуживания ключей доступа для совместимых устройств и предоставления резервных вариантов для остальных. Этот же интеллект применяется к привязке сессий, гарантируя максимальную безопасность для каждого пользователя в соответствии с возможностями его устройства.

Эра "Токена на предъявителя" подходит к концу. Текущее управление сессиями терпит катастрофический провал — токены на предъявителя могут быть украдены промышленными операциями вредоносного ПО и использованы с любого устройства, что позволяет захватывать аккаунты в обход даже самых сильных методов аутентификации. Эта фундаментальная уязвимость создала теневую экономику, оцениваемую в миллиарды.

Device Bound Session Credentials (DBSC) представляет собой развивающийся ответ отрасли. В отличие от традиционных безопасных файлов cookie с их флагами HttpOnly и статическими секретами, DBSC добавляет криптографическое доказательство владения через ключи, привязанные к устройству. Это делает украденные файлы cookie гораздо менее ценными. Их невозможно обновить с другого устройства. Там, где Token Binding потерпел неудачу, требуя сложных изменений на уровне TLS во всей инфраструктуре, DBSC преуспевает, работая на прикладном уровне HTTP, совместимом с существующими балансировщиками нагрузки и архитектурами CDN. Примечание: DBSC имеет задокументированные пути отката, когда браузер пропускает привязку (TPM недоступен, сетевые ошибки), поэтому он значительно снижает, но не устраняет полностью риск кражи файлов cookie.

Синергия между DBSC и ключами доступа значительно повышает планку для злоумышленников на всем пути пользователя. Ключи доступа устраняют фишинг учетных данных при входе в систему, в то время как DBSC делает перехват сессий посредством удаленной кражи файлов cookie гораздо более сложным — вместе они формируют платформу идентификации "с высокой степенью уверенности", которую представляет FIDO Alliance. С выходом Chrome 146, выпускающего DBSC в GA на Windows в апреле 2026 г., и появлением поддержки macOS Secure Enclave в следующем выпуске, стандарт перешел от этапа подготовки к этапу развертывания. Опубликованная дорожная карта Google (федеративная идентификация, регистрация через mTLS / аппаратный ключ, программные ключи) сигнализирует о следующих 12 месяцах расширения.

Для менеджеров по продуктам экономическое обоснование убедительно: DBSC обеспечивает "бесконечные" безопасные сессии, которые радикально снижают трение при входе и одновременно сокращают потери от мошенничества и затраты на поддержку. ROI проявляется в более высоких коэффициентах конверсии, меньшем количестве запросов на сброс пароля и устранении инцидентов захвата аккаунта. Организации, использующие OAuth, могут применять ту же концепцию привязки ключей через DPoP для токенов API, в то время как интеграция с Shared Signals (CAEP/RISC) обеспечивает реагирование на угрозы в реальном времени — мгновенный отзыв скомпрометированных сессий при следующей попытке обновления.

Реализация не требует создания всего с нуля. Платформы, такие как Corbado, предоставляют инфраструктуру ключей доступа и отслеживают разработки DBSC для интеграции привязки к устройству по мере созревания поддержки браузерами. Спецификация W3C является активным рабочим проектом, Chrome 146 находится в GA на Windows и развертывается на macOS, а другие браузеры все еще оценивают стандарт.

Траектория ясна: организации, которые начнут внедрять ключи доступа и DBSC сегодня, будут в лучшем положении для беспарольного будущего, устойчивого к фишингу. Вопрос не в том, внедрять ли сессии, привязанные к устройствам, а в том, насколько быстро вы сможете развернуть их для защиты своих пользователей и бизнеса. Будущее веб-безопасности не просто аутентифицировано; оно криптографически привязано к устройствам, которым мы доверяем.

О Corbado

Corbado — это Passkey Intelligence Platform для CIAM-команд, обеспечивающих аутентификацию пользователей в крупных масштабах. Мы показываем то, что не видят логи IDP и общие инструменты аналитики: какие устройства, версии ОС, браузеры и менеджеры учётных данных поддерживают passkey, почему регистрации не превращаются в логины, где сбоит WebAuthn-поток и когда обновление ОС или браузера тихо ломает вход — всё это без замены Okta, Auth0, Ping, Cognito или вашего собственного IDP. Два продукта: Corbado Observe добавляет наблюдаемость для passkey и любых других способов входа. Corbado Connect даёт managed passkey со встроенной аналитикой (рядом с вашим IDP). VicRoads использует passkey для более чем 5 млн пользователей с Corbado (+80 % активации passkey). Поговорить с экспертом по passkey →

Когда средства безопасности конечных точек, такие как CrowdStrike, обнаруживают вредоносное ПО, они отправляют сигнал RISC поставщику удостоверений, который передает событие CAEP "Устройство скомпрометировано" подключенным приложениям. При следующей попытке обновления DBSC (в течение нескольких минут) эти приложения отклоняют подпись сессии и прекращают доступ. Кросс-вендорное развертывание CAEP/RISC все еще находится в стадии развития.

DPoP (RFC 9449) привязывает токены доступа и обновления OAuth к открытому ключу на прикладном уровне, в первую очередь защищая вызовы API в нативных приложениях и SPA. DBSC привязывает файлы cookie сессии браузера к аппаратным ключам TPM, которые JavaScript не может прочитать или экспортировать, защищая сессии пользователей даже в том случае, если само веб-приложение скомпрометировано с помощью XSS или вредоносного ПО.

Традиционный дизайн безопасности требует коротких тайм-аутов сессии для ограничения ущерба, если файл cookie будет украден и воспроизведен удаленно. DBSC привязывает возможность обновления к закрытому ключу исходного устройства, поэтому украденный файл cookie, используемый с другого устройства, не проходит криптографическую проверку. Сессии могут быть фактически бессрочными, поскольку удаленные атаки воспроизведения нейтрализованы.

DBSC нейтрализует кражу файлов cookie как основной вектор захвата учетных записей, напрямую снижая убытки от мошенничества и затраты на поддержку восстановления учетных записей. Безопасные длинные сессии устраняют повторные запросы на вход, повышая коэффициент конверсии в электронной коммерции и снижая отсев пользователей. FIDO Alliance позиционирует DBSC как технологию, повышающую уровень безопасности при одновременном снижении трения для пользователей.