--- url: 'https://www.corbado.com/ru/blog/device-bound-session-credentials-dbsc' title: 'Описание Device Bound Session Credentials (DBSC)' description: 'Узнайте, как технология Device Bound Session Credentials (DBSC) предотвращает перехват сессий и кражу файлов cookie. Ознакомьтесь со статусом поддержки браузерами и безопасностью на уровне предприятия.' lang: 'ru' author: 'Vincent Delitz' date: '2026-06-15T13:56:56.542Z' lastModified: '2026-06-16T06:07:13.499Z' keywords: 'Device Bound Session Credentials, DBSC, предотвращение перехвата сессий, защита от кражи cookie, привязка сессии TPM' category: 'Authentication' --- # Описание Device Bound Session Credentials (DBSC) **Статус поддержки браузерами** > **Последние новости (апрель 2026 г.):** Chrome 146 выпускает > [DBSC в общий доступ на Windows](https://blog.google/security/protecting-cookies-with-device-bound-session-credentials/), > выводя функцию из стадии Origin Trial. Поддержка macOS (с использованием > [Secure Enclave](https://www.corbado.com/glossary/secure-enclave)) появится в одном из следующих выпусков > Chrome. Google также опубликовала публичную дорожную карту для федеративной > идентификации (кросс-доменные привязки [SSO](https://www.corbado.com/blog/passkeys-single-sign-on-sso)), > расширенной регистрации (mTLS / аппаратные ключи) и программных ключей для устройств без > аппаратной защиты. | Браузер | Windows | macOS | Linux | Android | iOS | Статус | | ----------- | ------------------------- | ----------------------------- | ---------------- | ---------------- | ---------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- | | **Chrome** | ✅ GA (Chrome 146, TPM) | 🚧 Ожидается (Secure Enclave) | ❌ | ❌ | ❌ | [GA на Windows](https://blog.google/security/protecting-cookies-with-device-bound-session-credentials/) (апрель 2026 г.), macOS в следующем выпуске | | **Edge** | ⏸️ Тестирование завершено | ❌ | ❌ | ❌ | ❌ | Origin Trial завершено в октябре 2025 г., GA не объявлено | | **Safari** | N/A | 🔄 Оценивается | N/A | N/A | 🔄 Оценивается | WebKit обсуждает, реализация не объявлена | | **Firefox** | 🔄 Отслеживается | 🔄 Отслеживается | 🔄 Отслеживается | 🔄 Отслеживается | 🔄 Отслеживается | Оценивается, обязательств по реализации нет | **Легенда:** ✅ В общем доступе | 🚧 Анонсировано / в разработке | ⏸️ Тестирование завершено | 🔄 Оценивается/отслеживается | ❌ Пока недоступно **Примечание:** [DBSC](https://www.corbado.com/blog/device-bound-session-credentials-dbsc) находится в статусе GA на Windows с TPM начиная с Chrome 146 (апрель 2026 г.). Поддержка macOS через [Secure Enclave](https://www.corbado.com/glossary/secure-enclave) развертывается следующей. Заявленная дорожная карта Google также включает программные ключи для расширения защиты на устройства без выделенного защищенного оборудования. **Ключевые преимущества: DBSC в сравнении с текущей моделью** | **Функция** | **Текущая модель cookie** | **Модель DBSC** | | ---------------------------- | ------------------------------------ | --------------------------------------------------------- | | **Тип токена** | Bearer (владение = доступ) | Bound (владение + ключ = доступ) | | **Последствия кражи** | Полный захват аккаунта | Бесполезный токен (невозможно обновить) | | **Продолжительность сессии** | Короткая (для безопасности) | Длинная / бесконечная (безопасна по замыслу) | | **Трение для пользователя** | Высокое (частые входы) | Низкое (невидимая безопасность) | | **Обход MFA** | Уязвимо (pass-the-cookie) | Устойчиво (требуется устройство) | | **Отзыв** | Медленный (ожидание истечения срока) | Почти в реальном времени (отказ при следующем обновлении) | ## Key Facts - **DBSC** привязывает веб-сессии к криптографическому ключу, хранящемуся на устройстве, делая украденные файлы cookie бесполезными, поскольку их невозможно обновить с другого устройства. - Браузер хранит неэкспортируемый закрытый ключ в **TPM**, подписывая серверные вызовы каждые 5 минут для подтверждения владения устройством без участия пользователя. - В отличие от **Token Binding**, которая потерпела неудачу из-за сложности инфраструктуры на уровне TLS, DBSC работает на прикладном уровне HTTP и прозрачно функционирует с существующими балансировщиками нагрузки и CDN. - **Chrome 146 выпускает DBSC в GA на Windows (апрель 2026 г.)**, а поддержка macOS Secure Enclave ожидается в следующем выпуске. Опубликованная дорожная карта Google также охватывает федеративную идентификацию (кросс-доменные привязки SSO), расширенную регистрацию (mTLS / аппаратные ключи) и программные ключи для устройств без аппаратной защиты. Safari и Firefox все еще оценивают технологию; Origin Trial Edge завершилось в октябре 2025 года без объявления GA. ## 1. Введение: Device Bound Session Credentials (DBSC) Архитектура Всемирной паутины была основана на принципе отсутствия состояния. Когда HTTP был впервые разработан, он не сохранял информацию о пользователях между запросами. Чтобы решить эту проблему, был изобретен "файл cookie" - небольшой фрагмент данных, отправляемый с веб-сайта и хранящийся на компьютере пользователя, чтобы отправлять его обратно на веб-сайт с каждым последующим запросом. На протяжении десятилетий этот механизм служил основой управления сессиями. Когда пользователь входит в систему, сервер проверяет его учетные данные и выдает файл cookie. Этот файл cookie действует как "токен на предъявителя". В физическом мире документ на предъявителя дает держателю права на активы, которые он представляет; если вы держите облигацию, вы владеете облигацией. Аналогично, в цифровом мире HTTP, если вы держите файл cookie, вы являетесь пользователем. Эта возможность предъявления является одновременно величайшей полезностью Интернета и его самой глубокой уязвимостью. Безопасность всей сессии - и, следовательно, личности пользователя, данных и финансовых активов - полностью зависит от секретности этой строки cookie. Если злоумышленник сможет скопировать эту строку, он сможет выдать себя за пользователя с любого устройства, в любой точке мира, полностью обходя первоначальные проверки аутентификации. Эта специфическая уязвимость породила теневую экономику промышленных масштабов, связанную с "кражей файлов cookie" и "перехватом сессий". По мере того, как отрасль успешно укрепляет "парадную дверь" аутентификации путем внедрения стандартов [FIDO](https://www.corbado.com/ru/glossary/cda) (Fast Identity Online) и ключей доступа, злоумышленники переносят свое внимание на "черный ход": активную сессию. Выудить пароль становится сложнее, но кража сессионного файла cookie остается опасно эффективной. Ответ отрасли на эту растущую угрозу - **Device Bound Session Credentials (DBSC)**. [DBSC](https://www.corbado.com/blog/device-bound-session-credentials-dbsc) представляет собой сдвиг парадигмы в том, как поддерживаются веб-сессии. Он предлагает отойти от простых токенов на предъявителя к модели, где сессия [криптографически привязана к устройству](https://www.w3.org/TR/dbsc/). С выходом [Chrome 146 (апрель 2026 г.), предоставляющего DBSC в GA на Windows](https://blog.google/security/protecting-cookies-with-device-bound-session-credentials/), стандарт перешел от экспериментального к производственному потенциалу, который веб-команды могут развернуть уже сегодня. Chrome использует TPM на Windows и внедряет поддержку Secure Enclave на macOS; сама спецификация не зависит от способа хранения ключей, требуя только, чтобы оно было "надежным против описанной угрозы". Это делает украденные файлы cookie гораздо менее ценными. Их невозможно обновить с другого устройства без привязанного ключа. В этой статье представлен исчерпывающий анализ [DBSC](https://www.corbado.com/blog/device-bound-session-credentials-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](https://www.corbado.com/glossary/oauth2)? 9. Как DBSC интегрируется с Shared Signals (CAEP/RISC) для реагирования на угрозы в реальном времени? ## 2. Понимание основных проблем и решений Чтобы разобраться в сложности этого нового стандарта, мы должны сначала понять фундаментальные проблемы с текущим управлением сессиями и то, как DBSC предлагает решения. Каждая из этих областей представляет собой критическую уязвимость или ограничение, которое устраняет DBSC. ### 2.1 Провал текущего управления сессиями Фундаментальный провал текущего управления сессиями заключается в "портативности" доверия. Когда сервер выдает сессионный файл cookie, он по сути выдает паспорт, который работает для любого, кто им владеет. Хотя браузеры внедрили средства защиты, такие как [флаги HttpOnly и Secure](https://www.wisp.blog/blog/understanding-token-storage-local-storage-vs-httponly-cookies) (предотвращающие доступ JavaScript и обеспечивающие передачу по HTTPS), эти средства защиты помогают только от специфических векторов извлечения, таких как межсайтовый скриптинг (XSS) или сетевой сниффинг. Они не обеспечивают защиту от вредоносного ПО, работающего на устройстве хоста. "Инфостилеры" - это вредоносное ПО, специально разработанное для поиска файла хранилища cookie браузера на диске, его расшифровки (часто с использованием собственных учетных данных пользователя на уровне ОС) и эксфильтрации содержимого на командно-контрольный сервер. Как только злоумышленник завладевает файлом cookie, он может выполнить [атаку Pass-the-Cookie](https://blog.chromium.org/2024/04/fighting-cookie-theft-using-device.html), внедряя украденный токен в свой собственный браузер для перехвата сессии. Сервер, видя действительный файл cookie, предполагает, что запрос является легитимным. ### 2.2 Криптографическое преимущество DBSC перед традиционными безопасными файлами cookie DBSC вводит второй фактор аутентификации в сам цикл обслуживания сессии. В отличие от стандартного безопасного файла cookie, который представляет собой статический секрет, сессия DBSC состоит из кратковременного токена на предъявителя и криптографического доказательства владения. Браузер генерирует пару открытого и закрытого ключей, надежно хранящуюся на устройстве. Сервер привязывает сессию к открытому ключу. Периодически браузер должен доказывать, что он все еще владеет закрытым ключом, подписывая вызов (challenge) от сервера. [Спецификация требует хранения ключей](https://www.w3.org/TR/dbsc/), "надежного против описанной угрозы". Chrome использует TPM на Windows, когда он доступен. Если злоумышленник крадет файл cookie с другого устройства, он не может его обновить, потому что не может сгенерировать необходимую криптографическую подпись. Аспект "предъявителя" сведен к очень короткому окну, в то время как аспект "привязки" обеспечивает долгосрочную непрерывность. ### 2.3 Синергия между ключами доступа и DBSC Ключи доступа и DBSC - это взаимодополняющие технологии, которые защищают разные этапы жизненного цикла пользователя. Ключи доступа (FIDO2) решают проблему _аутентификации_, доказывая личность для начала сессии без паролей, тем самым устраняя фишинг учетных данных. DBSC решает проблему _после аутентификации_, делая перехват сессии посредством кражи файлов cookie значительно сложнее. [FIDO Alliance позиционирует DBSC](https://fidoalliance.org/white-paper-dbsc-dpop-as-complementary-technologies-to-fido-authentication/) как взаимодополняющую технологию, которая "повышает планку" против перехвата сессий. Вместе они сокращают поверхность атаки на протяжении всего жизненного цикла входа и сессии, хотя DBSC не защищает от вредоносного ПО с постоянным доступом к устройству или атак браузера в середине (browser-in-the-middle) в реальном времени на том же устройстве. | Технологии | Удаленный фишинг | Перебор учетных данных | Кража токенов | | ------------------------------- | ---------------- | ---------------------- | ------------- | | **Ключи доступа** | ✅ | ✅ | ❌ | | **DBSC / DPoP** | ❌ | ❌ | ✅ | | **Ключи доступа + DBSC / DPoP** | ✅ | ✅ | ✅ | **Как ключи доступа и DBSC работают вместе** | **Аспект** | **Ключи доступа** | **DBSC** | **Совместная польза** | | ------------------------- | -------------------------------------------------------------- | ------------------------------------------ | -------------------------------------------------------- | | **Область применения** | Аутентификация (вход) | Управление сессиями | Сквозная защита | | **Смягчаемая угроза** | Фишинг паролей, перебор учетных данных | Удаленный перехват сессий, кража cookie | Значительно повышенная планка защиты от захвата аккаунта | | **Пользовательский опыт** | Вход без пароля | Прозрачная защита сессии | Бесшовный и безопасный опыт | | **Хранение ключей** | Привязанные к устройству или синхронизированные учетные данные | Привязанные к устройству (HSM при наличии) | Гибкая аутентификация, жесткая привязка сессии | | **Развертывание** | Заменяет пароли | Улучшает существующие сессии | Постепенное повышение безопасности | ### 2.4 Уроки из провала Token Binding DBSC - это не первая попытка решить эту проблему. "Token Binding" был предыдущим стандартом, который пытался привязать файлы cookie к базовому соединению TLS (Transport Layer Security). Хотя криптографически надежный, Token Binding не получил распространения из-за его сильной зависимости от уровня TLS. В современном Интернете соединения TLS часто оканчиваются на балансировщиках нагрузки, CDN или обратных прокси, в то время как логика приложения находится на серверах за ними. Распространение информации Token Binding через эти сложные сетевые уровни оказалось слишком сложным. DBSC извлекает уроки из этой неудачи, [работая исключительно на прикладном уровне (HTTP)](https://fidoalliance.org/white-paper-dbsc-dpop-as-complementary-technologies-to-fido-authentication/). Он не зависит от базового сетевого соединения, что делает его совместимым с существующими балансировщиками нагрузки, прокси и облачной инфраструктурой. ### 2.5 Бизнес-последствия и возможности ROI Для руководителей продуктов DBSC предлагает возможность повысить безопасность, одновременно улучшая пользовательский опыт (UX). Традиционно высокая безопасность означала короткие тайм-ауты сессий, заставляя пользователей часто входить в систему (трение). Благодаря привязке сессии к устройству, риск _удаленной_ кражи файла cookie значительно снижается. Бизнес может рассмотреть более длительные сессии, зная, что украденные файлы cookie нельзя обновить с другого устройства. Однако DBSC не защищает от кражи устройства, постоянного вредоносного ПО на устройстве или злоупотреблений со стороны вредоносного пользователя, поэтому политики времени жизни сессии все равно должны отражать эти остаточные риски. ## 3. Ландшафт угроз: Индустриализация кражи файлов cookie Чтобы понять срочность внедрения DBSC, необходимо оценить изощренность современного ландшафта угроз. Кража сессионных файлов cookie превратилась из нишевого хакерского трюка в масштабируемую, автоматизированную индустрию. ### 3.1 Расцвет инфостилеров ```mermaid graph TD A[Пользователь загружает
вредоносное ПО] -->|Выполнение| B[Инфостилер активируется
на устройстве] B --> C[Находит данные браузера] C --> D[Хранилище cookie
Chrome/Edge/Firefox] C --> E[База данных паролей] C --> F[Криптокошельки] D --> G[Расшифровывает, используя
учетные данные ОС] E --> G F --> G G --> H[Создает файл журнала (лог)
с украденными данными] H --> I[Эксфильтрация на C2-сервер] I --> J[Торговая площадка Даркнета] J --> K[Злоумышленник покупает лог] K --> L[Импортирует cookie
в свой браузер] L --> M[Обходит MFA] M --> N[Захват аккаунта
завершен] 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](https://www.corbado.com/blog/passkey-webauthn-database-guide)) и база данных Login Data (сохраненные пароли). - **Механизм:** Браузеры шифруют эти базы данных с помощью API защиты данных (DPAPI на Windows), привязанных к логину пользователя в ОС. Поскольку вредоносное ПО запускается _от имени пользователя_, оно может тривиально запросить расшифровку этих файлов. - **Результат:** Вредоносное ПО генерирует "лог" — zip-архив, содержащий расшифрованные файлы cookie, пароли, информацию о системе, а иногда ключи криптокошельков. ### 3.2 Рынок "логов" Эти логи агрегируются и продаются на теневых [торговых площадках](https://www.corbado.com/passkeys-for-e-commerce), таких как Genesis Market (до его закрытия) и Russian Market. Покупатели могут искать логи, содержащие активные файлы cookie для конкретных ценных целей: "Salesforce", "Gmail", "Bank of America" или "[AWS](https://www.corbado.com/blog/passkeys-amazon-cognito) Console". **Обход:** Ценность лога файлов cookie заключается в его способности обходить многофакторную аутентификацию (MFA). Большинство запросов [MFA](https://www.corbado.com/ru/blog/passkey-fallback-recovery) (SMS, TOTP, Push) происходят только во время события _входа_. Как только сессия установлена и файл cookie выдан, сервер предполагает, что пользователю можно доверять. Злоумышленник, импортирующий действительный сессионный файл cookie, [проскальзывает мимо ворот MFA](https://workspace.google.com/blog/identity-and-security/defending-against-account-takeovers-top-threats-passkeys-and-dbsc), представая перед сервером как пользователь, вернувшийся на активную вкладку. ### 3.3 Угроза для Google Workspace и Microsoft Entra Облачные пакеты для повышения производительности являются первоочередными целями. Украденный сессионный файл cookie для аккаунта Google Workspace или Microsoft Entra ID (ранее Azure AD) может предоставить злоумышленнику доступ к корпоративной электронной почте, документам и внутренним системам. [Собственная служба анализа угроз Google](https://blog.chromium.org/2024/04/fighting-cookie-theft-using-device.html) сообщила о массовом всплеске кражи файлов cookie как основного вектора доступа к аккаунтам Google, явно назвав это стимулом для их инвестиций в DBSC. Они отмечают, что, поскольку они принудительно включают двухэтапную аутентификацию (2SV) и ключи доступа, злоумышленники просто сменили тактику с фишинга учетных данных (которую предотвращает [2SV](https://www.corbado.com/blog/2sv-vs-2fa) / ключи доступа) на кражу файлов cookie (которую [2SV](https://www.corbado.com/blog/2sv-vs-2fa) / ключи доступа часто не останавливают). ### 3.4 Ограничения "Снятия отпечатков устройства" Исторически системы оценки рисков пытались обнаружить кражу сессии путем анализа цифровых отпечатков устройств, проверяя строку [User-Agent](https://www.corbado.com/blog/client-hints-user-agent-chrome-safari-firefox), разрешение экрана, установленные шрифты и IP-адрес. Если сессионный файл cookie внезапно появляется с нового IP-адреса с немного отличающимся отпечатком canvas, сервер может сделать его недействительным. **Проблема:** Инициативы по обеспечению конфиденциальности в браузерах (такие как Intelligent Tracking Prevention от Safari и Privacy Sandbox от Chrome) активно снижают энтропию этих отпечатков, чтобы остановить отслеживание рекламы. Это делает "хорошее" снятие отпечатков для безопасности все более сложным. Более того, злоумышленники теперь используют "Anti-Detect браузеры", которые позволяют им идеально подделывать эти отпечатки, чтобы они соответствовали профилю жертвы, делая эвристическое обнаружение неэффективным. DBSC заменяет эту вероятностную игру в угадывание детерминированным криптографическим доказательством. ## 4. Техническая архитектура: Как работает DBSC [Device Bound Session Credentials](https://www.corbado.com/blog/device-bound-session-credentials-dbsc) (DBSC) представляет собой [стандартизированный API и протокол](https://developer.chrome.com/docs/web-platform/device-bound-session-credentials) для создания сессий, привязанных к ключу на устройстве клиента. Спецификация требует хранения ключей, "надежного против описанной угрозы", но не зависит от реализации. Chrome использует TPM на Windows, когда он доступен. В этом разделе подробно описываются механизмы, как они определены в рабочем проекте W3C и документации Chrome. ### 4.1 Основные компоненты | **Компонент** | **Описание** | **Роль в DBSC** | | ------------------------------------ | ------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------- | | **Пользовательский агент (браузер)** | Клиентское приложение (Chrome, Edge и т.д.). | Управляет парой ключей, обрабатывает взаимодействие с HSM и перехватывает сетевые запросы для добавления доказательств. | | **Опирающаяся сторона (сервер)** | Веб-приложение (например, банковский портал). | Выдает вызовы (challenges), проверяет подписи и управляет жизненным циклом сессии. | | **Хранилище ключей** | Безопасное хранилище (TPM, Secure Enclave и др.) | Хранит закрытый ключ. Chrome использует TPM на Windows при наличии; спецификация не зависит от реализации. | | **Файл cookie сессии** | Стандартный HTTP cookie. | Используется как токен на предъявителя, но с очень коротким сроком жизни (например, 5-10 минут). | | **Доказательство владения** | Криптографическая подпись. | JWT, отправляемый браузером для подтверждения того, что он все еще владеет закрытым ключом. | ### 4.2 Жизненный цикл протокола DBSC Жизненный цикл DBSC обеспечивает плавный переход от стандартной сессии к привязанной сессии, обеспечивая обратную совместимость и прогрессивное улучшение. ```mermaid 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: Ответ об успехе ``` #### 4.2.1 Фаза 1: Инициация и привязка Процесс привязки начинается сразу после успешной аутентификации пользователя стандартными методами (пароль, ключ доступа и т.д.). 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 \.\.\ ``` 4. **Привязка сессии:** Сервер проверяет подпись, чтобы убедиться в работоспособности открытого ключа. Затем он обновляет свою базу данных, чтобы связать сессию пользователя (session_id=xyz123) с этим конкретным открытым ключом. С этого момента сессия становится "привязанной". #### 4.2.2 Фаза 2: Цикл кратковременного файла cookie Чтобы сбалансировать безопасность и производительность (операции с безопасными ключами могут добавлять задержку), DBSC использует систему с двумя токенами. 1. **Выдача:** Сервер выдает _новый_, кратковременный файл cookie (например, действительный в течение 5 минут). Назовем его access_token. 2. **Использование:** Браузер использует этот access_token для всех обычных запросов (получение изображений, вызовы API, навигация по страницам). Пока файл cookie действителен, никакие криптографические операции не выполняются. Это обеспечивает быструю работу в Интернете. 3. **Истечение срока:** Через 5 минут access_token истекает. #### 4.2.3 Фаза 3: Обновление (Доказательство владения) Это сердцевина механизма безопасности. Когда истекает срок действия кратковременного файла cookie, злоумышленник на другом устройстве блокируется, но легитимный пользователь (с доступом к привязанному ключу) может продолжить работу. 1. **Обнаружение:** Браузер пытается выполнить запрос. Он замечает, что срок действия файла cookie истек (или сервер возвращает 401 или специальный заголовок Secure-Session-Challenge). 2. **Перехват:** Браузер _приостанавливает_ сетевой запрос. Он не показывает ошибку пользователю. 3. **Запрос на обновление:** Браузер автоматически вызывает конечную точку обновления, определенную в конфигурации сессии. - Сервер отправляет криптографический **Вызов** (challenge) (nonce). - Браузер использует привязанный ключ для подписания этого вызова. - Подпись подтверждает владение закрытым ключом. 4. **Отправка:** Браузер отправляет подписанный вызов обратно на сервер. ``` HTTP POST /auth/dbsc/refresh HTTP/1.1 Sec-Secure-Session-Id: \ Secure-Session-Response: \ ``` 5. **Проверка:** Сервер использует сохраненный Открытый ключ для проверки подписи. - _Если действительна:_ Сервер знает, что запрос поступает с того же физического устройства, которое начало сессию. Он выдает _новый_ кратковременный access_token (действительный еще 5 минут). - _Если недействительна:_ Запрос отклоняется. Сессия прерывается. 6. **Возобновление:** Браузер берет новый файл cookie и прозрачно повторяет исходный приостановленный запрос. [Пользователь не замечает никаких прерываний](https://developer.chrome.com/docs/web-platform/device-bound-session-credentials). ### 4.3 Нюансы реализации #### 4.3.1 Защита от "Lift and Shift" ```mermaid graph LR subgraph "Устройство жертвы" A[Сессия пользователя
с DBSC] B[Закрытый ключ
HSM/TPM] C[Cookie +
ID сессии] A --> B A --> C B -.->|Неэкспортируемый| X[Невозможно извлечь
Закрытый ключ] end subgraph "Сценарий атаки" D[Стилер RedLine
заражает устройство] D --> E[Крадет Cookie
и ID сессии] E --> F[Экспорт к
злоумышленнику] end subgraph "Устройство злоумышленника" G[Импортирует украденный
Cookie] H[Пытается
использовать сессию] I[Сервер запрашивает
обновление DBSC] J[Невозможно подписать
вызов] 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, но не может выполнить обновление, поскольку у него нет привязанного закрытого ключа. Атака терпит неудачу. #### 4.3.2 Область действия и конфиденциальность Конфиденциальность — это центральная цель при проектировании DBSC. [Спецификация W3C](https://www.w3.org/TR/dbsc/) явно запрещает использование глобальных идентификаторов, которые могли бы отслеживать пользователей на разных сайтах. - **Ключи для каждого источника:** Браузер генерирует уникальную пару ключей для каждого сайта. google.com видит Ключ А; amazon.com видит Ключ Б. Между ними нет никакой связи. - **Очистка данных пользователя:** Если пользователь удаляет свои файлы cookie/данные сайтов, браузер также удаляет связанные ключи DBSC. Это гарантирует, что DBSC не может быть использован как "супер-cookie" для восстановления удаленных идентификаторов. #### 4.3.3 Соображения на стороне сервера Внедрение DBSC требует от сервера сохранения состояния об открытых ключах. - **Схема базы данных:** Таблица сессий должна быть обновлена для хранения `public_key` и `last_challenge` наряду с `user_id` и `session_expiry`. - **Производительность:** Операция обновления включает криптографическую проверку (например, проверку подписи ECDSA). Хотя она и быстрая, она более требовательна к процессору, чем проверка простой строки. Однако, поскольку обновления происходят только каждые несколько минут (а не при каждом запросе), накладные расходы незначительны. ## 5. Бизнес и продуктовые последствия Помимо технических спецификаций, DBSC несет в себе значительные последствия для бизнес-стратегии, дорожных карт продуктов и соответствия нормативным требованиям. ### 5.1 ROI безопасности без трения Инициативы по обеспечению безопасности часто рассматриваются как центры затрат или генераторы трения. DBSC переворачивает этот нарратив. Следующая диаграмма иллюстрирует, как привязка к устройству создает каскад бизнес-преимуществ: - **Снижение уровня мошенничества:** Нейтрализуя основной вектор захвата аккаунта (ATO), компании могут сэкономить миллионы на убытках от мошенничества. - **Затраты на поддержку:** Восстановление аккаунта обходится дорого. [Предотвращение взлома в первую очередь](https://fidoalliance.org/white-paper-dbsc-dpop-as-complementary-technologies-to-fido-authentication/) напрямую снижает это операционное бремя. - **Оптимизация конверсии:** В [электронной коммерции](https://www.corbado.com/passkeys-for-e-commerce) каждый запрос на вход является потенциальной точкой отсева. DBSC позволяет применять агрессивную политику "оставаться в системе", обеспечивая мгновенное оформление заказа без запросов пароля. ### 5.2 Соответствие нормативным требованиям и "Современный уровень техники" Нормативные базы, такие как GDPR (Общий регламент по защите данных) в Европе, требуют от организаций внедрения "надлежащих технических и организационных мер" для обеспечения безопасности. - **Доказуемая безопасность:** По мере того, как DBSC становится стандартом, он, вероятно, будет интерпретироваться как "современный уровень техники" для управления сессиями. В случае нарушения демонстрация того, что был внедрен DBSC, может стать мощной защитой от обвинений в халатности. - **Банковские стандарты (PSD2):** Вторая директива о [платежных](https://www.corbado.com/passkeys-for-payment) услугах требует "Строгой аутентификации клиента" (SCA). Хотя [SCA](https://www.corbado.com/ru/blog/psd2-passkeys) сосредоточена на входе в систему, динамическое связывание сессии с устройством идеально согласуется с целями директивы по привязке аутентификации к конкретным суммам и получателям. ### 5.3 Высокая уверенность в сравнении с умеренной уверенностью [Белые книги FIDO Alliance](https://fidoalliance.org/white-paper-high-assurance-enterprise-fido-authentication/) выделяют концепцию "Уровней уверенности" (Assurance Levels). - **Умеренная уверенность:** Использует синхронизированные ключи доступа (например, такие, как в Связке ключей iCloud). Отлично подходит для потребительских приложений, восстанавливается, просто в использовании. - **Высокая уверенность:** Требует привязанных к устройству ключей. В этом DBSC проявляет себя наилучшим образом. Для корпоративных ресурсов (HR-порталы, репозитории кода) или ценного [банкинга](https://www.corbado.com/passkeys-for-banking) организация может применять политику, которая _только_ разрешает доступ из сессий, привязанных к конкретному управляемому устройству. DBSC обеспечивает технический механизм соблюдения этой политики. ## 6. DBSC в сравнении с альтернативами Чтобы полностью оценить DBSC, мы должны сравнить его с другими технологиями, которые пытались решить аналогичные проблемы. ```mermaid 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 ``` ### 6.1 DBSC в сравнении с Token Binding Как упоминалось ранее, Token Binding пытался привязать сессию к уровню TLS. - **Token Binding:** Требовал поддержки от клиента, сервера _и_ каждого перехода между ними (Балансировщики нагрузки, Терминаторы TLS). Он ломался, когда соединение обрывалось и зашифровывалось заново. - **DBSC:** [Работает на прикладном уровне HTTP](https://fidoalliance.org/white-paper-dbsc-dpop-as-complementary-technologies-to-fido-authentication/). Он прозрачно проходит через балансировщики нагрузки как стандартные заголовки/файлы cookie. Его гораздо проще развернуть в современных облачных архитектурах (AWS/GCP/Azure), где TLS часто обрабатывается граничной сетью облачного провайдера. ### 6.2 DBSC в сравнении с DPoP (Demonstrating Proof of Possession) [DPoP (RFC 9449)](https://datatracker.ietf.org/doc/html/rfc9449) — это стандарт для токенов OAuth, "ограниченных отправителем" (sender-constrained). Он привязывает как токены доступа, _так и_ токены обновления к открытому ключу — что критически важно, поскольку токены обновления сами по себе являются долгоживущими учетными данными на предъявителя. Каждый запрос API включает доказательство DPoP: подписанный JWT с HTTP-методом, URL, временной меткой и уникальным идентификатором. Спецификации с высокой степенью уверенности, такие как [FAPI 2.0](https://openid.net/specs/fapi-2_0-security-profile.html), требуют использования токенов, ограниченных отправителем; DPoP является рекомендуемым методом, когда mTLS недоступен. **Ключевое отличие:** Ключи DPoP живут в контексте приложения. Лучшей практикой является использование API ОС для неэкспортируемого хранения, но это не является обязательным — многие реализации хранят ключи в памяти, доступной для JavaScript. Если злоумышленник может выполнить произвольный код (XSS, вредоносное ПО), он может получить доступ к ключам DPoP или генерировать доказательства по требованию. DPoP останавливает воспроизведение токенов _между разными клиентами_, но не может защитить скомпрометированный контекст браузера. DBSC переносит доказательство владения в браузер и на аппаратный уровень. Закрытый ключ живет в TPM или безопасном анклаве (Secure Enclave), который JavaScript не может прочитать или экспортировать. Браузер обрабатывает протокол и создает подписи, не раскрывая ключи коду приложения. Даже если веб-приложение полностью скомпрометировано, злоумышленник не может создавать новые доказательства для украденных файлов cookie на другой машине. | Аспект | DPoP | DBSC | | -------------------------- | --------------------------------------------- | ------------------------------- | | **Цель** | Токены доступа + обновления OAuth | Файлы cookie сессии браузера | | **Хранение ключей** | Контекст приложения (лучшая практика: API ОС) | На аппаратном уровне (TPM) | | **Устойчивость к XSS** | ⚠️ Зависит от реализации | ✅ Ключи неэкспортируемы | | **Основное использование** | Нативные приложения, SPA, FAPI 2.0 | Сессии пользователей в браузере | **Синергия:** Как [отмечает FIDO Alliance](https://fidoalliance.org/white-paper-dbsc-dpop-as-complementary-technologies-to-fido-authentication/), ключи доступа устраняют фишинг при входе, в то время как DBSC/DPoP защищают токены после аутентификации. Современная архитектура сочетает и то, и другое: DPoP для API OAuth (особенно в регулируемом открытом [банкинге](https://www.corbado.com/passkeys-for-banking)), DBSC для сессий в браузере. Вместе они закрывают вектор атаки "lift and shift" на протяжении всего жизненного цикла сессии. ### 6.3 DBSC в сравнении с кратковременными файлами cookie (Сами по себе) Простое сокращение времени жизни файлов cookie (например, до 15 минут) повышает безопасность, но разрушает UX. Пользователи вынуждены постоянно авторизовываться. DBSC обеспечивает _эффективную_ безопасность 5-минутного файла cookie с _пользовательским опытом_ 30-дневного файла cookie. ## 7. Shared Signals и динамическое реагирование (CAEP/RISC) ```mermaid %%{init: { "theme": "default", "themeVariables": { "actorBkg": "#ffffff", "actorBorder": "#000000", "noteBkgColor": "#f1f3f5", "noteTextColor": "#000000", "activationBkgColor": "#e0e0e0", "actorColours": { "ST": "#ff6b6b", "IdP": "#4c6ef5" } } }}%% sequenceDiagram participant ST as Средства безопасности
(CrowdStrike, Defender) participant IdP as Поставщик удостоверений
(Okta, Google, Azure) participant SP1 as Провайдер услуг 1
(Slack) participant SP2 as Провайдер услуг 2
(Salesforce) participant SP3 as Провайдер услуг 3
(Банковское приложение) participant Session as Сессия пользователя
(Защищена DBSC) Note over ST,Session: Фаза обнаружения угрозы ST->>ST: Обнаруживает вредоносное ПО на
устройстве пользователя ST->>IdP: Сигнал RISC:
"Устройство скомпрометировано" Note over IdP,SP3: Фаза распространения сигнала IdP->>SP1: Событие CAEP:
"Устройство скомпрометировано" IdP->>SP2: Событие CAEP:
"Устройство скомпрометировано" IdP->>SP3: Событие CAEP:
"Устройство скомпрометировано" Note over SP1,Session: Фаза применения (с DBSC) Session->>SP1: Следующая попытка обновления
(в течение минут) SP1-->>Session: x Отклонить подпись Session->>SP2: Следующая попытка обновления SP2-->>Session: x Отклонить подпись Session->>SP3: Следующая попытка обновления SP3-->>Session: x Отклонить подпись Note over Session: Сессии могут быть прерваны при следующей попытке обновления ``` Потенциал DBSC усиливается в сочетании с [**Shared Signals Framework (SSF)**](https://fidoalliance.org/white-paper-fido-and-the-shared-signals-framework/), в частности, с **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, сервер отклонит подпись и прервет сессию.\ Этот [архитектурный шаблон](https://fidoalliance.org/white-paper-fido-and-the-shared-signals-framework/) обеспечивает более быстрый отзыв — фактическая задержка зависит от периода обновления сайта и от того, реализованы ли на нем как DBSC, так и SSF. ## 8. Поддержка браузерами и экосистемой Внедрение DBSC зависит от разработчиков браузеров. Ситуация в 2026 году существенно изменилась: Chrome перевел DBSC из стадии Origin Trial в общий доступ на Windows в апреле 2026 года, а macOS станет следующей. Другие браузеры все еще оценивают технологию. ### 8.1 Google Chrome Google является главным драйвером DBSC и первым браузером, который широко его внедряет. - **Статус (апрель 2026 г.):** [Chrome 146 выпускает DBSC в общий доступ на Windows](https://blog.google/security/protecting-cookies-with-device-bound-session-credentials/), завершая стадию Origin Trial. Поддержка macOS с использованием [Secure Enclave](https://www.corbado.com/glossary/secure-enclave) анонсирована для одного из следующих выпусков Chrome. - **Оборудование:** Windows использует TPM, macOS будет использовать Secure Enclave. Google заявила, что также изучает **программные ключи** для расширения защиты DBSC на устройства без выделенного защищенного оборудования. - **Дорожная карта:** Объявление Google о GA также опубликовало план следующих шагов: - **Защита федеративной идентификации:** кросс-доменные привязки DBSC, чтобы сессия опирающейся стороны (RP) оставалась привязанной к тому же ключу устройства, что и сессия поставщика удостоверений (IdP), сохраняя непрерывную цепочку доверия через [SSO](https://www.corbado.com/blog/passkeys-single-sign-on-sso). - **Расширенная регистрация:** привязка сессий DBSC к ранее существовавшим доверенным ключевым материалам, таким как **сертификаты mTLS** или **аппаратные ключи безопасности**, вместо генерации нового ключа при входе. - **Более широкая поддержка устройств:** программные ключи для устройств без TPM / Secure Enclave. - **Операционные результаты:** Во время развертывания Google сообщает о "значительном сокращении краж сессий" для сессий, защищенных DBSC. - **Аккаунты Google:** Отдельно Google уже внедрила защиту в стиле DBSC для [файлов cookie аккаунтов Google в Chrome для Windows](https://support.google.com/chrome/a/answer/2657289), которая контролируется корпоративной политикой. Это защищает Gmail/Workspace и теперь является тем же самым семейством технологий, которое доступно в GA для всего веба. ### 8.2 Microsoft Edge и Windows Microsoft принимает активное участие. - **Статус:** Edge проводил [Origin Trial DBSC](https://developer.microsoft.com/microsoft-edge/origin-trials/trials/0c292c9b-58fe-4f23-b066-c3b58911024d) на Windows, которое завершилось в октябре 2025 года. О новом тестировании или GA не объявлялось. - **Корпоративный контекст:** Edge использует [архитектуру "Primary Refresh Token" (PRT)](https://learn.microsoft.com/en-us/entra/identity/devices/concept-primary-refresh-token) для Entra/Azure AD [SSO](https://www.corbado.com/blog/passkeys-single-sign-on-sso), которая концептуально схожа с DBSC. PRT остается специфичным механизмом Microsoft; нет никаких заявленных планов по его объединению с веб-стандартом DBSC для сторонних сайтов. ### 8.3 Apple Safari (WebKit) Позиция Apple критически важна для охвата мобильных устройств. - **Статус:** В WebKit есть [проблема (issue) с позицией по стандартам](https://github.com/WebKit/standards-positions/issues/281), в которой оценивается DBSC с отмеченными опасениями по поводу удобства использования и конфиденциальности. В примечаниях к выпуску Safari DBSC не упоминается. Нет публичных заявлений об "активной реализации". - **Конфиденциальность прежде всего:** Главное опасение Apple заключается в том, что DBSC можно использовать для создания "супер-cookie" (неудаляемого отслеживания). Спецификация W3C решает эту проблему, гарантируя очистку ключей вместе с данными веб-сайта. - **Взаимодействие:** WebKit участвует в процессе стандартизации, но статус реализации неясен — "обсуждается", а не "в разработке". ### 8.4 Mozilla Firefox Mozilla имеет [проблему (issue) с позицией по стандартам](https://github.com/mozilla/standards-positions/issues/912), оценивающую DBSC с отмеченными опасениями по поводу сложности и конфиденциальности. Нет никаких публичных обязательств по внедрению после стабилизации стандарта. ## 9. Рекомендации: Защита пользователей уже сегодня Учитывая текущую поддержку DBSC и ключей доступа в экосистеме, организациям следует применять поэтапный подход к внедрению этих взаимодополняющих технологий. Приведенная ниже дорожная карта намечает немедленные действия и этапы стратегического планирования: ### 9.1 Немедленные действия (сейчас, когда Chrome 146 в GA) 1. **Сначала разверните ключи доступа**: Начните с внедрения ключей доступа для защиты уровня аутентификации. Это обеспечивает немедленную защиту от фишинга учетных данных и является предварительным условием для получения реальной выгоды от DBSC. 2. **Запустите конечные точки регистрации и обновления DBSC**: С выходом Chrome 146 GA реалистичная задача сейчас — это бэкенд-интеграция: добавление заголовков `Secure-Session-Registration` в ответы при входе в систему и реализация `/dbsc/register` плюс конечной точки обновления, которая проверяет подписанные вызовы. Код фронтенда менять не нужно. 3. **Внедрите короткоживущие сессии с токенами обновления**: Если вы еще не готовы к DBSC, примите архитектурный паттерн короткоживущих токенов с механизмами обновления. Это подготовит ваш бэкенд к DBSC, одновременно повысив безопасность уже сегодня. ### 9.2 Стратегическое планирование (следующие 12 месяцев) 1. **Примите гибридный подход**: Используйте обнаружение функций для предоставления DBSC совместимым браузерам (в настоящее время Chrome 146+ на Windows, далее macOS Secure Enclave), сохраняя при этом запасные варианты (fallback). Это максимизирует безопасность, не исключая пользователей в Safari, Firefox или Edge. 2. **Подготовьтесь к следующим пунктам дорожной карты**: Google явно указала федеративную идентификацию (кросс-доменные привязки SSO), расширенную регистрацию (mTLS / аппаратные ключи) и программные ключи для более широкого охвата устройств. Если вы управляете SSO или уровнем IdP, начните планировать кросс-доменную привязку уже сейчас. 3. **Интегрируйтесь с поставщиками удостоверений**: Если вы используете Okta, [Auth0](https://www.corbado.com/blog/auth0-passkeys-analysis) или подобные IdP, поработайте с ними, чтобы включить поддержку DBSC в их SDK. Многие из них участвовали в Origin Trials и активно выпускают возможности DBSC теперь, когда Chrome находится в GA. ### 9.3 Лучшие практики внедрения - **Начните с ценных целей**: Отдайте приоритет DBSC для панелей администратора, финансовых транзакций и доступа к конфиденциальным данным. - **Используйте управляемые решения**: Рассмотрите платформы вроде Corbado, которые берут на себя сложность реализации DBSC и совместимости браузеров. - **Измеряйте и улучшайте**: Отслеживайте такие метрики, как попытки перехвата сессий, обращения в службу поддержки и трение пользователей, чтобы продемонстрировать ROI. - **Подготовьтесь к соблюдению нормативов**: Документируйте вашу реализацию DBSC, поскольку она, вероятно, станет нормативным требованием для обработки конфиденциальных данных. ## 10. Как Corbado может помочь: Мост в будущее Внедрение DBSC с нуля — это тяжелая инженерная задача. Она требует криптографической экспертизы, глубоких знаний о несоответствиях браузеров и надежной серверной инфраструктуры для управления ключами и вызовами. Именно здесь **Corbado** выступает в роли вспомогательного инструмента. ### 10.1 Фундамент: Ключи доступа Вы не можете построить сессию с высокой степенью уверенности поверх логина с низкой степенью уверенности. Если пользователь входит в систему со слабым паролем, сессия безопасна ровно настолько, насколько безопасен этот пароль. Основной продукт Corbado (**управляемые ключи доступа**) обеспечивает необходимый фундамент. Интегрируя Corbado, организации могут легко развертывать ключи доступа, гарантируя, что начало сессии устойчиво к фишингу. ### 10.2 Будущее: DBSC для надежного обнаружения доверенных устройств Corbado будет использовать DBSC для улучшения обнаружения доверенных устройств. Когда доступны сигналы DBSC, они предоставляют криптографическое доказательство того, что сессия исходит с определенного устройства, позволяя Corbado соответствующим образом повышать уровни доверия аутентификации. - **Решение неоднозначности синхронизированных ключей доступа:** Синхронизированные ключи доступа удобны, но создают пробел в доверии: когда пользователь аутентифицируется с помощью синхронизированного ключа доступа, вы не можете сказать, его ли это обычный ноутбук или совершенно новое устройство, которое только что синхронизировало учетные данные. DBSC закрывает этот пробел. Проверив, имеет ли устройство установленную привязку DBSC, Corbado может убедиться, что устройство действительно известно и пользуется доверием, а не просто синхронизируется впервые. - **Более высокое доверие к известным устройствам:** Когда сигналы DBSC подтверждают, что устройство уже было замечено ранее, Corbado может принимать более уверенные решения о рисках: меньше запросов на пошаговую аутентификацию (step-up authentication) для легитимных возвращающихся пользователей, более строгая проверка для сессий с нераспознанных устройств. - **Дополнение к Passkey Intelligence:** Сигналы DBSC интегрируются с существующим механизмом [**Passkey Intelligence**](https://docs.corbado.com/corbado-connect/features/passkey-intelligence) от Corbado. Сочетание аутентификации на основе ключей доступа и привязки устройства на основе DBSC создает полную цепочку доверия от входа в систему через весь жизненный цикл сессии. По вопросам о том, как Corbado планирует интегрировать DBSC в свою платформу, [свяжитесь с командой](https://www.corbado.com/contact). ### 10.3 Изящный откат (Резервирование в гибридной реальности) В течение следующих нескольких лет Интернет будет гибридным. У некоторых пользователей будут браузеры, поддерживающие DBSC (Chrome на [Windows 11](https://www.corbado.com/blog/passkeys-windows-11)); другие будут на старых системах. Справиться с этой фрагментацией сложно. Механизм [**Passkey Intelligence**](https://docs.corbado.com/corbado-connect/features/passkey-intelligence) от Corbado разработан именно для обработки такой логики отката — обслуживания ключей доступа для совместимых устройств и предоставления резервных вариантов для остальных. Этот же интеллект применяется к привязке сессий, гарантируя максимальную безопасность для каждого пользователя в соответствии с возможностями его устройства. ## 11. Заключение: Путь вперед для DBSC Эра "Токена на предъявителя" подходит к концу. Текущее управление сессиями терпит катастрофический провал — токены на предъявителя могут быть украдены промышленными операциями вредоносного ПО и использованы с любого устройства, что позволяет захватывать аккаунты в обход даже самых сильных методов аутентификации. Эта фундаментальная уязвимость создала теневую экономику, оцениваемую в миллиарды. [Device Bound Session Credentials](https://www.corbado.com/blog/device-bound-session-credentials-dbsc) (DBSC) представляет собой развивающийся ответ отрасли. В отличие от традиционных безопасных файлов cookie с их флагами HttpOnly и статическими секретами, DBSC добавляет криптографическое доказательство владения через ключи, привязанные к устройству. Это делает украденные файлы cookie гораздо менее ценными. Их невозможно обновить с другого устройства. Там, где Token Binding потерпел неудачу, требуя сложных изменений на уровне TLS во всей инфраструктуре, DBSC преуспевает, работая на прикладном уровне HTTP, совместимом с существующими балансировщиками нагрузки и архитектурами CDN. Примечание: DBSC имеет задокументированные пути отката, когда браузер пропускает привязку (TPM недоступен, сетевые ошибки), поэтому он значительно снижает, но не устраняет полностью риск кражи файлов cookie. Синергия между DBSC и ключами доступа значительно повышает планку для злоумышленников на всем пути пользователя. Ключи доступа устраняют фишинг учетных данных при входе в систему, в то время как DBSC делает перехват сессий посредством удаленной кражи файлов cookie гораздо более сложным — вместе они формируют платформу идентификации "с высокой степенью уверенности", которую представляет [FIDO Alliance](https://www.corbado.com/glossary/fido-alliance). С выходом [Chrome 146, выпускающего DBSC в GA на Windows в апреле 2026 г.](https://blog.google/security/protecting-cookies-with-device-bound-session-credentials/), и появлением поддержки macOS Secure Enclave в следующем выпуске, стандарт перешел от этапа подготовки к этапу развертывания. Опубликованная дорожная карта Google (федеративная идентификация, регистрация через mTLS / аппаратный ключ, программные ключи) сигнализирует о следующих 12 месяцах расширения. Для менеджеров по продуктам экономическое обоснование убедительно: DBSC обеспечивает "бесконечные" безопасные сессии, которые радикально снижают трение при входе и одновременно сокращают потери от мошенничества и затраты на поддержку. ROI проявляется в более высоких коэффициентах конверсии, меньшем количестве запросов на сброс пароля и устранении инцидентов захвата аккаунта. Организации, использующие OAuth, могут применять ту же концепцию привязки ключей через DPoP для токенов API, в то время как интеграция с Shared Signals (CAEP/RISC) обеспечивает реагирование на угрозы в реальном времени — мгновенный отзыв скомпрометированных сессий при следующей попытке обновления. Реализация не требует создания всего с нуля. Платформы, такие как [Corbado](https://www.corbado.com/features), предоставляют инфраструктуру ключей доступа и отслеживают разработки DBSC для интеграции привязки к устройству по мере созревания поддержки браузерами. [Спецификация W3C](https://www.w3.org/TR/dbsc/) является активным рабочим проектом, Chrome 146 находится в GA на Windows и развертывается на macOS, а другие браузеры все еще оценивают стандарт. Траектория ясна: организации, которые начнут внедрять ключи доступа и DBSC сегодня, будут в лучшем положении для беспарольного будущего, устойчивого к фишингу. Вопрос не в том, внедрять ли сессии, привязанные к устройствам, а в том, насколько быстро вы сможете развернуть их для защиты своих пользователей и бизнеса. Будущее веб-безопасности не просто аутентифицировано; оно криптографически привязано к устройствам, которым мы доверяем. ## Часто задаваемые вопросы ### Как DBSC работает с CAEP и RISC для отзыва скомпрометированных сессий в реальном времени? Когда средства безопасности конечных точек, такие как CrowdStrike, обнаруживают вредоносное ПО, они отправляют сигнал RISC поставщику удостоверений, который передает событие CAEP "Устройство скомпрометировано" подключенным приложениям. При следующей попытке обновления DBSC (в течение нескольких минут) эти приложения отклоняют подпись сессии и прекращают доступ. Кросс-вендорное развертывание CAEP/RISC все еще находится в стадии развития. ### В чем разница между DBSC и DPoP для защиты сессий веб-приложений? DPoP (RFC 9449) привязывает токены доступа и обновления OAuth к открытому ключу на прикладном уровне, в первую очередь защищая вызовы API в нативных приложениях и SPA. DBSC привязывает файлы cookie сессии браузера к аппаратным ключам TPM, которые JavaScript не может прочитать или экспортировать, защищая сессии пользователей даже в том случае, если само веб-приложение скомпрометировано с помощью XSS или вредоносного ПО. ### Почему DBSC позволяет увеличить продолжительность сессии без повышения риска безопасности? Традиционный дизайн безопасности требует коротких тайм-аутов сессии для ограничения ущерба, если файл cookie будет украден и воспроизведен удаленно. DBSC привязывает возможность обновления к закрытому ключу исходного устройства, поэтому украденный файл cookie, используемый с другого устройства, не проходит криптографическую проверку. Сессии могут быть фактически бессрочными, поскольку удаленные атаки воспроизведения нейтрализованы. ### На какую окупаемость инвестиций (ROI) могут рассчитывать предприятия от внедрения DBSC? DBSC нейтрализует кражу файлов cookie как основной вектор захвата учетных записей, напрямую снижая убытки от мошенничества и затраты на поддержку восстановления учетных записей. Безопасные длинные сессии устраняют повторные запросы на вход, повышая коэффициент конверсии в электронной коммерции и снижая отсев пользователей. [FIDO](https://www.corbado.com/ru/glossary/cda) Alliance позиционирует DBSC как технологию, повышающую уровень безопасности при одновременном снижении трения для пользователей.