--- url: 'https://www.corbado.com/pt/blog/credenciais-sessao-vinculadas-dispositivo-dbsc' title: 'Credenciais de sessão vinculadas ao dispositivo (DBSC) explicadas' description: 'Saiba como as credenciais de sessão vinculadas ao dispositivo (DBSC) evitam o sequestro de sessões e o roubo de cookies. Conheça o suporte dos navegadores e a segurança corporativa.' lang: 'pt' author: 'Vincent Delitz' date: '2026-06-15T13:57:07.637Z' lastModified: '2026-06-17T06:03:26.746Z' keywords: 'Device Bound Session Credentials, DBSC, prevenção de sequestro de sessão, proteção contra roubo de cookies, vinculação de sessão TPM' category: 'Authentication' --- # Credenciais de sessão vinculadas ao dispositivo (DBSC) explicadas **Status de suporte dos navegadores** > **Mais recente (abril de 2026):** o Chrome 146 lança o > [DBSC em disponibilidade geral no Windows](https://blog.google/security/protecting-cookies-with-device-bound-session-credentials/), > retirando o recurso do Origin Trial. O suporte ao macOS (usando o > [Secure Enclave](https://www.corbado.com/glossary/secure-enclave)) está chegando em uma próxima versão do > Chrome. O Google também anunciou um roteiro público para identidade federada > (vinculações de [SSO](https://www.corbado.com/blog/passkeys-single-sign-on-sso) entre origens), registro > avançado (mTLS/chaves de hardware) e chaves baseadas em software para dispositivos sem > hardware seguro. | Navegador | Windows | macOS | Linux | Android | iOS | Status | | ----------- | ----------------------- | ---------------------------- | -------------- | -------------- | -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ | | **Chrome** | ✅ GA (Chrome 146, TPM) | 🚧 Em breve (Secure Enclave) | ❌ | ❌ | ❌ | [GA no Windows](https://blog.google/security/protecting-cookies-with-device-bound-session-credentials/) (abril de 2026), macOS na próxima versão | | **Edge** | ⏸️ Teste encerrado | ❌ | ❌ | ❌ | ❌ | O Origin Trial terminou em outubro de 2025, sem anúncio de GA | | **Safari** | N/A | 🔄 Avaliando | N/A | N/A | 🔄 Avaliando | WebKit em discussão, sem implementação anunciada | | **Firefox** | 🔄 Monitorando | 🔄 Monitorando | 🔄 Monitorando | 🔄 Monitorando | 🔄 Monitorando | Avaliando, sem compromisso de implementação | **Legenda:** ✅ Disponibilidade geral | 🚧 Anunciado/em desenvolvimento | ⏸️ Teste encerrado | 🔄 Avaliando/monitorando | ❌ Ainda não disponível **Nota:** o [DBSC](https://www.corbado.com/blog/device-bound-session-credentials-dbsc) é GA no Windows com TPM a partir do Chrome 146 (abril de 2026). O suporte ao macOS por meio do [Secure Enclave](https://www.corbado.com/glossary/secure-enclave) será implementado em seguida. O roteiro declarado do Google também inclui chaves baseadas em software para estender a proteção a dispositivos sem hardware seguro dedicado. **Principais vantagens: DBSC vs modelo atual** | **Recurso** | **Modelo atual de cookies** | **Modelo DBSC** | | ------------------------- | ---------------------------- | -------------------------------------------------- | | **Tipo de token** | Portador (posse = acesso) | Vinculado (posse + chave = acesso) | | **Consequência do roubo** | Invasão total da conta | Token inútil (não pode ser atualizado) | | **Duração da sessão** | Curta (por segurança) | Longa/infinita (segura por design) | | **Atrito do usuário** | Alto (logins frequentes) | Baixo (segurança invisível) | | **Desvio de MFA** | Vulnerável (pass-the-cookie) | Resistente (dispositivo necessário) | | **Revogação** | Lenta (esperar expirar) | Quase em tempo real (falha na próxima atualização) | ## Key Facts - O **DBSC** vincula sessões da web a uma chave criptográfica mantida no dispositivo, tornando os cookies roubados inúteis porque não podem ser atualizados a partir de outro dispositivo. - O navegador armazena uma chave privada não exportável em um **TPM**, assinando os desafios do servidor a cada 5 minutos para provar a posse do dispositivo sem a interação do usuário. - Ao contrário do **Token Binding**, que falhou devido à complexidade da infraestrutura da camada TLS, o DBSC opera na camada de aplicativo HTTP e funciona de forma transparente com os balanceadores de carga e CDNs existentes. - **O Chrome 146 lança o DBSC em GA no Windows (abril de 2026)**, com o suporte ao Secure Enclave do macOS chegando em uma próxima versão. O roteiro publicado pelo Google também abrange identidade federada (vinculações de SSO entre origens), registro avançado (mTLS/chaves de hardware) e chaves baseadas em software para dispositivos sem hardware seguro. Safari e Firefox ainda estão avaliando; o Origin Trial do Edge terminou em outubro de 2025 sem nenhum anúncio de GA. ## 1. Introdução: Credenciais de sessão vinculadas ao dispositivo (DBSC) A arquitetura da World Wide Web foi fundada em um princípio de ausência de estado (statelessness). Quando o HTTP foi projetado pela primeira vez, ele não retinha informações sobre os usuários entre as solicitações. Para resolver isso, foi inventado o "cookie" - um pequeno dado enviado por um site e armazenado no computador do usuário, para ser enviado de volta ao site com cada solicitação subsequente. Por décadas, esse mecanismo serviu como a base do gerenciamento de sessão. Quando um usuário faz login, o servidor valida suas credenciais e emite um cookie. Esse cookie atua como um "token de portador". No mundo físico, um instrumento ao portador é um documento que dá ao titular os direitos ou ativos que ele representa; se você detém o título, você é o dono do título. Da mesma forma, no mundo digital do HTTP, se você tiver o cookie, você é o usuário. Essa capacidade de portador é simultaneamente a maior utilidade da web e sua vulnerabilidade mais profunda. A [segurança](https://www.corbado.com/pt/blog/senhas-complexas-quebradas-em-breve) de toda a sessão - e por extensão, a identidade, os dados e os ativos financeiros do usuário - baseia-se inteiramente no sigilo dessa string de cookie. Se um agente mal-intencionado puder copiar essa string, ele poderá se passar por usuário de qualquer dispositivo, em qualquer lugar do mundo, ignorando totalmente as verificações iniciais de [autenticação](https://www.corbado.com/pt/blog/webauthn-relying-party-id-rpid-passkeys). Essa vulnerabilidade específica deu origem a uma economia clandestina em escala industrial de "roubo de cookies" e "sequestro de sessões". À medida que o setor endurece com sucesso a "porta da frente" da [autenticação](https://www.corbado.com/pt/blog/webauthn-relying-party-id-rpid-passkeys) por meio da adoção dos padrões [FIDO](https://www.corbado.com/pt/glossary/cda) (Fast Identity Online) e [chaves de acesso](https://www.corbado.com/pt/glossary/cda), os invasores estão mudando seu foco para a "porta dos fundos": a sessão ativa. Fazer [phishing](https://www.corbado.com/glossary/phishing) de uma senha está se tornando mais difícil, mas roubar um cookie de sessão continua perigosamente eficaz. A resposta do setor a essa ameaça crescente é o **Device Bound Session Credentials (DBSC)**. O [DBSC](https://www.corbado.com/blog/device-bound-session-credentials-dbsc) representa uma mudança de paradigma na forma como as sessões da web são mantidas. Ele propõe um afastamento de simples tokens de portador em direção a um modelo em que a sessão é [criptograficamente vinculada ao dispositivo](https://www.w3.org/TR/dbsc/). Com [o Chrome 146 (abril de 2026) lançando o DBSC em GA no Windows](https://blog.google/security/protecting-cookies-with-device-bound-session-credentials/), o padrão passou de um recurso experimental a um recurso de produção que as equipes da web podem implantar hoje. O Chrome usa TPMs no Windows e está lançando o suporte para o Secure Enclave no macOS a seguir; a especificação em si é agnóstica em relação ao armazenamento de chaves, exigindo apenas que seja "robusta contra a ameaça descrita". Isso torna os cookies roubados muito menos valiosos. Eles não podem ser atualizados em outro dispositivo sem a chave vinculada. Este artigo fornece uma análise exaustiva do [DBSC](https://www.corbado.com/blog/device-bound-session-credentials-dbsc), projetada para arquitetos de [segurança](https://www.corbado.com/pt/blog/senhas-complexas-quebradas-em-breve), gerentes de produto e desenvolvedores. Ele explora a arquitetura técnica, as implicações comerciais da "[segurança](https://www.corbado.com/pt/blog/senhas-complexas-quebradas-em-breve) sem atrito", o relacionamento com padrões emergentes, como Sinais Compartilhados (CAEP/RISC), e como as organizações podem se preparar para esse futuro usando plataformas como a Corbado. **Principais perguntas que este artigo responde** 1. Por que o gerenciamento de sessões atual está falhando na prevenção de invasões de contas? 2. Como o DBSC é diferente dos cookies "seguros" existentes e das flags HttpOnly? 3. Como o DBSC e as [chaves de acesso](https://www.corbado.com/pt/glossary/cda) funcionam juntos para uma resistência mais forte ao [phishing](https://www.corbado.com/glossary/phishing)? 4. O que aconteceu com o Token Binding e por que o DBSC está tendo sucesso onde ele falhou? 5. Quais são as implicações comerciais e o ROI para os gerentes de produto? 6. Quais navegadores e sistemas operacionais oferecem suporte ao DBSC hoje? 7. Como as organizações podem implementar o DBSC sem construir do zero? 8. Qual é a relação entre DBSC, DPoP e [OAuth 2.0](https://www.corbado.com/glossary/oauth2)? 9. Como o DBSC se integra ao Shared Signals (CAEP/RISC) para resposta a ameaças em tempo real? ## 2. Entendendo os principais problemas e soluções Para navegar na complexidade desse novo padrão, devemos primeiro entender os problemas fundamentais do gerenciamento de sessão atual e como o DBSC fornece soluções. Cada uma dessas áreas representa uma vulnerabilidade ou limitação crítica que o DBSC aborda. ### 2.1 Falha no gerenciamento de sessão atual A falha fundamental do gerenciamento de sessão atual é a "portabilidade" da confiança. Quando um servidor emite um cookie de sessão, ele está essencialmente emitindo um passaporte que funciona para qualquer pessoa que o possua. Embora os navegadores tenham implementado defesas como [sinalizadores HttpOnly e Secure](https://www.wisp.blog/blog/understanding-token-storage-local-storage-vs-httponly-cookies) (impedindo o acesso do JavaScript e garantindo a transmissão por HTTPS), essas defesas apenas protegem contra vetores de extração específicos, como Cross-Site Scripting (XSS) ou rastreamento de rede. Elas não oferecem proteção contra [malware](https://www.corbado.com/glossary/malware) executado no dispositivo host. "Infostealers" são malwares projetados especificamente para localizar o arquivo de armazenamento de cookies do navegador no disco, descriptografá-lo (geralmente usando as próprias credenciais em nível de sistema operacional do usuário) e exfiltrar o conteúdo para um servidor de comando e controle. Uma vez que o invasor possua o cookie, ele pode realizar um ataque [Pass-the-Cookie](https://blog.chromium.org/2024/04/fighting-cookie-theft-using-device.html), injetando o token roubado em seu próprio navegador para sequestrar a sessão. O servidor, vendo um cookie válido, presume que a solicitação seja legítima. ### 2.2 A vantagem criptográfica do DBSC em relação aos cookies seguros tradicionais O DBSC introduz um segundo fator de [autenticação](https://www.corbado.com/pt/blog/webauthn-relying-party-id-rpid-passkeys) no próprio loop de manutenção da sessão. Ao contrário de um cookie seguro padrão, que é um segredo estático, uma sessão DBSC consiste em um token de portador de curta duração e uma prova criptográfica de posse. O navegador gera um par de chaves pública-privada armazenado com segurança no dispositivo. O servidor vincula a sessão à [chave pública](https://www.corbado.com/pt/glossary/jwks). Periodicamente, o navegador deve provar que ainda possui a chave privada, assinando um desafio do servidor. A [especificação exige um armazenamento de chaves](https://www.w3.org/TR/dbsc/) "robusto contra a ameaça descrita". O Chrome usa o TPM no Windows quando disponível. Se um invasor roubar o cookie de um dispositivo diferente, ele não poderá atualizá-lo porque não conseguirá gerar a assinatura criptográfica necessária. O aspecto de "portador" é minimizado em uma janela muito curta, enquanto o aspecto de "vinculação" fornece continuidade a longo prazo. ### 2.3 Sinergia entre chaves de acesso e DBSC As [chaves de acesso](https://www.corbado.com/pt/glossary/cda) e o DBSC são tecnologias complementares que protegem diferentes fases do ciclo de vida do usuário. As chaves de acesso (FIDO2) resolvem o problema de _autenticação_ provando a identidade para iniciar uma sessão sem senhas, eliminando assim o [phishing](https://www.corbado.com/glossary/phishing) de credenciais. O DBSC aborda o problema _pós-autenticação_ tornando o sequestro de sessão por meio do roubo de cookies significativamente mais difícil. A [FIDO Alliance enquadra o DBSC](https://fidoalliance.org/white-paper-dbsc-dpop-as-complementary-technologies-to-fido-authentication/) como uma tecnologia complementar que "eleva o nível" contra o sequestro de sessões. Juntos, eles reduzem a superfície de ataque durante o login e o ciclo de vida da sessão, embora o DBSC não proteja contra malwares com acesso contínuo ao dispositivo ou ataques de browser-in-the-middle em tempo real no mesmo dispositivo. | Tecnologias | Phishing remoto | Preenchimento de credenciais | Roubo de token | | ---------------------------------- | --------------- | ---------------------------- | -------------- | | **Chaves de acesso** | ✅ | ✅ | ❌ | | **DBSC / DPoP** | ❌ | ❌ | ✅ | | **Chaves de acesso + DBSC / DPoP** | ✅ | ✅ | ✅ | **Como as chaves de acesso e o DBSC funcionam juntos** | **Aspecto** | **Chaves de acesso** | **DBSC** | **Benefício combinado** | | --------------------------- | ------------------------------------------------------ | ------------------------------------------------ | ------------------------------------------------------- | | **Escopo** | Autenticação (login) | Gerenciamento de sessão | Proteção de ponta a ponta | | **Ameaça mitigada** | Phishing de senha, preenchimento de credenciais | Sequestro remoto de sessão, roubo de cookies | Nível significativamente elevado para invasão de contas | | **Experiência do usuário** | Login sem senha | Proteção de sessão transparente | Experiência perfeita e segura | | **Armazenamento de chaves** | Credenciais vinculadas ao dispositivo ou sincronizadas | Vinculado ao dispositivo (HSM quando disponível) | Autenticação flexível, vinculação de sessão rígida | | **Implantação** | Substitui senhas | Aprimora as sessões existentes | Melhorias incrementais de segurança | ### 2.4 Aprendendo com o fracasso do Token Binding O DBSC não é a primeira tentativa de resolver esse problema. O "Token Binding" foi um padrão anterior que tentava vincular cookies à conexão TLS (Transport Layer Security) subjacente. Embora criptograficamente sólido, o Token Binding não obteve adoção devido à sua forte dependência da camada TLS. Na web moderna, as conexões TLS geralmente são encerradas em balanceadores de carga, CDNs ou proxies reversos, enquanto a lógica do aplicativo reside em servidores por trás deles. Propagar as informações do Token Binding por essas camadas de rede complexas provou ser muito difícil. O DBSC aprende com essa falha [operando inteiramente na camada de aplicativo (HTTP)](https://fidoalliance.org/white-paper-dbsc-dpop-as-complementary-technologies-to-fido-authentication/). Ele não depende da conexão de rede subjacente, tornando-o compatível com balanceadores de carga, proxies e infraestrutura de nuvem existentes. ### 2.5 Implicações comerciais e oportunidades de ROI Para os líderes de produtos, o DBSC oferece uma oportunidade de melhorar a segurança e, simultaneamente, melhorar a experiência do usuário (UX). Tradicionalmente, alta segurança significava tempos limite curtos de sessão, forçando os usuários a fazer login com frequência (atrito). Ao vincular a sessão ao dispositivo, o risco de roubo _remoto_ de cookies é significativamente reduzido. As empresas podem considerar durações de sessão mais longas, sabendo que cookies roubados não podem ser atualizados a partir de outro dispositivo. No entanto, o DBSC não protege contra roubo de dispositivo, [malware](https://www.corbado.com/glossary/malware) persistente no dispositivo ou abuso por um uso mal-intencionado, portanto, as políticas de tempo de vida da sessão ainda devem refletir esses riscos residuais. ## 3. Cenário de ameaças: Industrialização do roubo de cookies Para entender a urgência por trás do DBSC, é preciso apreciar a sofisticação do cenário de ameaças moderno. O roubo de cookies de sessão passou de um truque de hacker de nicho a um setor escalável e automatizado. ### 3.1 A ascensão dos Infostealers ```mermaid graph TD A[Usuário baixa
software malicioso] -->|Execução| B[Infostealer é ativado
no dispositivo] B --> C[Localiza dados do navegador] C --> D[Armazenamento de cookies do
Chrome/Edge/Firefox] C --> E[Banco de dados de senhas] C --> F[Carteiras de criptomoedas] D --> G[Descriptografa usando as
credenciais do SO] E --> G F --> G G --> H[Cria arquivo de log
com dados roubados] H --> I[Exfiltra para o servidor C2] I --> J[Mercado da Dark Web] J --> K[O invasor compra o log] K --> L[Importa cookie para seu
próprio navegador] L --> M[Contorna o MFA] M --> N[Invasão de conta
concluída] 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 ``` O [Malware](https://www.corbado.com/glossary/malware)-as-a-Service (MaaS) diminuiu a barreira de entrada para os cibercriminosos. Os "Infostealers", como RedLine, Raccoon, Vidar e Taurus, são malwares disponíveis comercialmente projetados com um objetivo principal: exfiltração de dados de navegadores da web. Esses ladrões são distribuídos por meio de e-mails de phishing, software crackeado ou anúncios maliciosos. Uma vez instalados, eles têm como alvo os caminhos de arquivo específicos onde navegadores como Chrome, Edge e Firefox armazenam seus dados. - **O alvo:** o banco de dados de cookies (geralmente um arquivo [SQLite](https://www.corbado.com/blog/passkey-webauthn-database-guide)) e o banco de dados de dados de login (senhas salvas). - **O mecanismo:** os navegadores criptografam esses bancos de dados usando APIs de [proteção de dados](https://www.corbado.com/pt/blog/manuseio-seguro-documentos) (DPAPI no Windows) vinculadas ao login do sistema operacional do usuário. Como o malware é executado _como o usuário_, ele pode solicitar de forma trivial a descriptografia desses arquivos. - **A saída:** o malware gera um "log" — um arquivo zip contendo os cookies descriptografados, senhas, informações do sistema e, às vezes, chaves de [carteira](https://www.corbado.com/pt/blog/garantia-carteiras-digitais) de criptomoedas. ### 3.2 O mercado de "logs" Esses logs são agregados e vendidos em [mercados](https://www.corbado.com/passkeys-for-e-commerce) da [dark web](https://www.corbado.com/pt/blog/dark-web-seguranca) como o Genesis Market (antes de sua derrubada) e o Russian Market. Os compradores podem procurar logs contendo cookies ativos para alvos específicos de alto valor: "Salesforce", "Gmail", "Bank of America" ou "[AWS](https://www.corbado.com/blog/passkeys-amazon-cognito) Console". **O desvio:** O valor de um log de cookie está na capacidade de ignorar a Autenticação Multifator (MFA). A maioria dos desafios de [MFA](https://www.corbado.com/pt/blog/senha-apareceu-em-vazamento-de-dados) (SMS, TOTP, Push) ocorre apenas durante o evento de _login_. Assim que a sessão for estabelecida e o cookie emitido, o servidor assumirá que o usuário é confiável. Um invasor que importe um cookie de sessão válido [passa direto pelo portão do MFA](https://workspace.google.com/blog/identity-and-security/defending-against-account-takeovers-top-threats-passkeys-and-dbsc), aparecendo para o servidor como se o usuário estivesse retornando a uma guia ativa. ### 3.3 Ameaça do Google Workspace e do Microsoft Entra Os pacotes de produtividade na nuvem são os principais alvos. Um cookie de sessão roubado para uma conta do Google Workspace ou do Microsoft Entra ID (anteriormente Azure AD) pode dar ao invasor acesso a e-mails corporativos, documentos e sistemas internos. [A própria inteligência de ameaças do Google](https://blog.chromium.org/2024/04/fighting-cookie-theft-using-device.html) relatou um aumento maciço no roubo de cookies como o principal vetor de acesso às contas do Google, citando-o explicitamente como o motivo de seu investimento no DBSC. Eles observam que, à medida que forçam a habilitação da Verificação em duas etapas (2SV) e das chaves de acesso, os invasores simplesmente mudaram de tática de phishing de credenciais (que [2SV](https://www.corbado.com/blog/2sv-vs-2fa) / chaves de acesso interrompe) para roubo de cookies (que [2SV](https://www.corbado.com/blog/2sv-vs-2fa) / chaves de acesso geralmente não interrompe). ### 3.4 Limites da "identificação do dispositivo" Historicamente, os mecanismos de risco tentaram detectar o roubo de sessão analisando impressões digitais de dispositivos, observando a string [User-Agent](https://www.corbado.com/blog/client-hints-user-agent-chrome-safari-firefox), a resolução da tela, as fontes instaladas e o endereço IP. Se um cookie de sessão aparecer repentinamente de um novo IP com uma impressão digital de tela ligeiramente diferente, o servidor pode invalidá-lo. **O problema:** iniciativas de privacidade em navegadores (como o Intelligent Tracking Prevention do Safari e o Privacy Sandbox do Chrome) estão reduzindo ativamente a entropia dessas impressões digitais para interromper o rastreamento de anúncios. Isso torna a "boa" impressão digital para segurança cada vez mais difícil. Além disso, os invasores agora usam "Navegadores anti-detecção" que lhes permitem falsificar essas impressões digitais perfeitamente para combinar com o perfil da vítima, tornando a detecção heurística ineficaz. O DBSC substitui esse jogo de adivinhação probabilística por prova criptográfica determinística. ## 4. Arquitetura técnica: como o DBSC funciona O [Device Bound Session Credentials](https://www.corbado.com/blog/device-bound-session-credentials-dbsc) (DBSC) introduz uma [API e protocolo padronizados](https://developer.chrome.com/docs/web-platform/device-bound-session-credentials) para criar sessões vinculadas a uma chave no dispositivo cliente. A especificação exige que o armazenamento de chaves seja "robusto contra a ameaça descrita", mas é agnóstico em relação à implementação. O Chrome usa o TPM no Windows quando disponível. Esta seção detalha a mecânica conforme definida no rascunho de trabalho do W3C e na documentação do Chrome. ### 4.1 Componentes principais | **Componente** | **Descrição** | **Papel no DBSC** | | --------------------------------- | --------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------ | | **Agente de usuário (navegador)** | O aplicativo cliente (Chrome, Edge, etc.). | Gerencia o par de chaves, lida com a interação do HSM e intercepta as solicitações de rede para anexar provas. | | **Parte dependente (servidor)** | O aplicativo da web (por exemplo, portal bancário). | Emite desafios, verifica assinaturas e gerencia o ciclo de vida da sessão. | | **Armazenamento de chaves** | Armazenamento seguro (TPM, Secure Enclave ou outro) | Armazena a chave privada. O Chrome usa o TPM no Windows quando disponível; a especificação é agnóstica quanto à implementação. | | **Cookie de sessão** | Um cookie HTTP padrão. | Usado como token de portador, mas com uma vida útil muito curta (por exemplo, 5-10 minutos). | | **Prova de posse** | Uma assinatura criptográfica. | Um JWT enviado pelo navegador para provar que ele ainda possui a chave privada. | ### 4.2 Ciclo de vida do protocolo DBSC O ciclo de vida do DBSC permite uma transição perfeita de uma sessão padrão para uma sessão vinculada, garantindo compatibilidade com versões anteriores e aprimoramento progressivo. ```mermaid sequenceDiagram participant User participant Browser participant HSM as HSM (TPM/Secure Enclave) participant Server Note over User,Server: Fase 1: Autenticação e vinculação User->>Browser: Login com credenciais/chave de acesso Browser->>Server: Solicitação de autenticação Server->>Browser: Sucesso + cabeçalho de registro DBSC Browser->>HSM: Gerar par de chaves HSM->>Browser: Chave pública/privada (privada não exportável) Browser->>Server: Registrar chave pública (JWT assinado) Server->>Server: Vincular sessão à chave pública Server->>Browser: Cookie de curta duração (5 min) Note over User,Server: Fase 2: Uso normal loop A cada solicitação dentro de 5 minutos Browser->>Server: Solicitação com cookie Server->>Browser: Resposta end Note over User,Server: Fase 3: Atualização (após expiração) Browser->>Server: Solicitação com cookie expirado Server->>Browser: 401 + Desafio (nonce) Browser->>HSM: Assinar desafio HSM->>Browser: Assinatura Browser->>Server: Prova de assinatura Server->>Server: Verificar com chave pública armazenada Server->>Browser: Novo cookie de curta duração Browser->>Server: Tentar novamente a solicitação original Server->>Browser: Resposta de sucesso ``` #### 4.2.1 Fase 1: Iniciação e vinculação O processo de vinculação começa imediatamente após a autenticação do usuário usando métodos padrão (senha, [chave de acesso](https://www.corbado.com/pt/blog/senhas-complexas-quebradas-em-breve), etc.). 1. **Sinal do servidor:** Após o login bem-sucedido, o servidor define um cookie de sessão (como de costume), mas adiciona um cabeçalho específico indicando o suporte ao 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" ``` - O cabeçalho Secure-Session-Registration informa ao navegador: "Eu suporto os algoritmos ES256 e RS256. Por favor, registre uma sessão vinculada no endpoint /auth/dbsc/register." 2. **Geração de chaves:** O navegador analisa esse cabeçalho. Ele gera um novo par de chaves assimétricas (por exemplo, Elliptic Curve P-256), armazenado com segurança no dispositivo. - **Nota de implementação:** O Chrome usa TPM no Windows quando disponível; a especificação é agnóstica sobre o mecanismo de armazenamento, exigindo apenas que seja "robusto contra a ameaça descrita". - **Escopo de privacidade:** A chave é restrita à origem da web (por exemplo, banco.com.br). O navegador garante que essa chave nunca seja usada para varejista.com.br, evitando rastreamento entre sites. 3. **Solicitação de registro:** O navegador envia uma solicitação para o caminho de registro especificado. Esta solicitação inclui a recém-gerada **Chave Pública** dentro de um JSON Web Token (JWT), assinado pela Chave Privada (atestado autoassinado). ``` HTTP POST /auth/dbsc/register HTTP/1.1 Content-Type: application/jwt \.\.\ ``` 4. **Vinculação de sessão:** O servidor valida a assinatura para garantir que a [chave pública](https://www.corbado.com/pt/glossary/jwks) seja funcional. Ele então atualiza seu banco de dados para associar a sessão do usuário (session_id=xyz123) com essa [Chave Pública](https://www.corbado.com/pt/glossary/jwks) específica. A partir deste momento, a sessão está "vinculada". #### 4.2.2 Fase 2: Loop de cookie de curta duração Para equilibrar segurança com desempenho (operações com chave segura podem adicionar latência), o DBSC usa um sistema de token duplo. 1. **Emissão:** O servidor emite um _novo_ cookie de curta duração (por exemplo, válido por 5 minutos). Vamos chamar isso de access_token. 2. **Uso:** O navegador usa esse access_token para todas as solicitações normais (buscar imagens, chamadas de API, navegar em páginas). Enquanto o cookie for válido, nenhuma operação criptográfica será executada. Isso garante que a navegação permaneça rápida. 3. **Expiração:** Após 5 minutos, o access_token expira. #### 4.2.3 Fase 3: Atualização (Prova de posse) Este é o coração do mecanismo de segurança. Quando o cookie de curta duração expira, um invasor em um dispositivo diferente é bloqueado, mas o usuário legítimo (com acesso à chave vinculada) pode continuar. 1. **Detecção:** O navegador tenta fazer uma solicitação. Ele percebe que o cookie expirou (ou o servidor retorna um 401 ou um cabeçalho Secure-Session-Challenge específico). 2. **Interceptação:** O navegador _pausa_ a solicitação de rede. Ele não mostra um erro ao usuário. 3. **Solicitação de atualização:** O navegador chama automaticamente o endpoint de atualização definido na configuração da sessão. - O servidor envia um **Desafio** criptográfico (um nonce). - O navegador usa a chave vinculada para assinar esse desafio. - A assinatura prova a posse da chave privada. 4. **Envio:** O navegador envia o desafio assinado de volta ao servidor. ``` HTTP POST /auth/dbsc/refresh HTTP/1.1 Sec-Secure-Session-Id: \ Secure-Session-Response: \ ``` 5. **Validação:** O servidor usa a Chave Pública armazenada para verificar a assinatura. - _Se Válida:_ O servidor sabe que a solicitação vem do mesmo dispositivo físico que iniciou a sessão. Ele emite um _novo_ access_token de curta duração (válido por mais 5 minutos). - _Se Inválida:_ A solicitação é rejeitada. A sessão é encerrada. 6. **Retomada:** O navegador pega o novo cookie e tenta novamente de forma transparente a solicitação original pausada. O [usuário não experimenta interrupções](https://developer.chrome.com/docs/web-platform/device-bound-session-credentials). ### 4.3 Nuances de implementação #### 4.3.1 Defesa "Lift and Shift" ```mermaid graph LR subgraph "Dispositivo da vítima" A[Sessão do usuário
com DBSC] B[Chave privada
HSM/TPM] C[Cookie +
ID da sessão] A --> B A --> C B -.->|Não exportável| X[Não é possível extrair
a chave privada] end subgraph "Cenário de ataque" D[RedLine Stealer
infecta o dispositivo] D --> E[Rouba cookie
e ID da sessão] E --> F[Exporta para
o invasor] end subgraph "Dispositivo do invasor" G[Importa cookie
roubado] H[Tenta
usar a sessão] I[O servidor solicita a
atualização do DBSC] J[Não consegue assinar
o desafio] K[Sessão negada] G --> H H --> I I --> J J --> K end C -.->|Roubado| 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 ``` Considere um invasor que infecte o PC do usuário com o RedLine Stealer. Eles roubam o `access_token` e o `session_id`. Eles os importam para o próprio navegador. - **Cenário A (dentro de 5 minutos):** O invasor pode ter acesso por alguns minutos até que o token de curta duração expire. - **Cenário B (após expiração):** O navegador do invasor (em um dispositivo diferente) tenta usar o token. O servidor o rejeita e exige uma atualização. O navegador do invasor vê os cabeçalhos do DBSC, mas não pode realizar a atualização porque não possui a chave privada vinculada. O ataque falha. #### 4.3.2 Escopo e privacidade A privacidade é um objetivo central de design do DBSC. A [especificação do W3C](https://www.w3.org/TR/dbsc/) proíbe explicitamente o uso de identificadores globais que poderiam rastrear usuários entre sites. - **Chaves por origem:** O navegador gera um par de chaves exclusivo para cada site. google.com vê a Chave A; amazon.com vê a Chave B. Não há correlação entre elas. - **Limpeza do usuário:** Se o usuário limpar seus cookies/dados do site, o navegador também excluirá as chaves do DBSC associadas. Isso garante que o DBSC não possa ser usado como um "super-cookie" para ressuscitar identidades excluídas. #### 4.3.3 Considerações no lado do servidor A implementação do DBSC requer que o servidor mantenha o estado das chaves públicas. - **Esquema de banco de dados:** A tabela de sessão deve ser atualizada para armazenar a `public_key` e o `last_challenge` ao lado de `user_id` e `session_expiry`. - **Desempenho:** A operação de atualização envolve verificação criptográfica (por exemplo, verificar uma assinatura ECDSA). Embora rápida, consome mais uso da CPU do que verificar uma string simples. No entanto, como as atualizações ocorrem apenas a cada poucos minutos (não a cada solicitação), a sobrecarga é insignificante. ## 5. Implicações comerciais e de produto Além das especificações técnicas, o DBSC traz implicações significativas para a estratégia de negócios, roteiros de produtos e posturas de conformidade. ### 5.1 ROI da segurança sem atrito As iniciativas de segurança são frequentemente vistas como centros de [custo](https://www.corbado.com/pt/blog/custos-sms) ou geradores de atrito. O DBSC inverte essa narrativa. O diagrama a seguir ilustra como a vinculação ao dispositivo cria uma cascata de benefícios comerciais: - **Redução de fraudes:** Ao neutralizar o vetor primário para invasão de contas (ATO), as empresas podem economizar milhões em perdas por fraudes. - **Custos de suporte:** A [recuperação de conta](https://www.corbado.com/pt/blog/como-eliminar-senhas-por-completo) é cara. [Prevenir o hack em primeiro lugar](https://fidoalliance.org/white-paper-dbsc-dpop-as-complementary-technologies-to-fido-authentication/) reduz diretamente esse fardo operacional. - **Otimização de conversão:** No [comércio eletrônico](https://www.corbado.com/passkeys-for-e-commerce), cada solicitação de login é um ponto de abandono potencial. O DBSC permite políticas de "mantenha-me conectado" agressivas, possibilitando o checkout instantâneo sem solicitações de senha. ### 5.2 Conformidade e o "estado da arte" Estruturas regulatórias como o RGPD (Regulamento Geral sobre a [Proteção de Dados](https://www.corbado.com/pt/blog/manuseio-seguro-documentos)) na Europa exigem que as organizações implementem "medidas técnicas e organizacionais adequadas" para garantir a segurança. - **Segurança defensável:** À medida que o DBSC se torna um padrão, ele provavelmente será interpretado como o "estado da arte" para o gerenciamento de sessões. Em caso de violação, demonstrar que o DBSC foi implementado pode ser uma defesa poderosa contra alegações de negligência. - **Padrões bancários (PSD2):** A Diretiva de Serviços de [Pagamento](https://www.corbado.com/passkeys-for-payment) 2 exige a "Autenticação Forte do Cliente" (SCA). Embora o [SCA](https://www.corbado.com/pt/blog/psd2-passkeys) se concentre no login, a [vinculação dinâmica](https://www.corbado.com/pt/blog/biometria-confirmacao-pagador) da sessão ao dispositivo alinha-se perfeitamente com os objetivos da diretiva de vincular a autenticação a valores e beneficiários específicos. ### 5.3 Alta garantia vs Garantia moderada Os [white papers da FIDO Alliance](https://fidoalliance.org/white-paper-high-assurance-enterprise-fido-authentication/) destacam o conceito de "Níveis de Garantia". - **Garantia moderada:** Usa [chaves de acesso sincronizadas](https://www.corbado.com/pt/blog/chaves-de-acesso-vinculadas-dispositivo-vs-sincronizadas) (como as do [iCloud Keychain](https://www.corbado.com/glossary/icloud-keychain)). Ótimo para aplicativos de consumo, recuperável, fácil de usar. - **Alta garantia:** Requer chaves vinculadas ao dispositivo. É aqui que o DBSC brilha. Para recursos corporativos (portais de RH, repositórios de código) ou acesso [bancário](https://www.corbado.com/passkeys-for-banking) de alto valor, a organização pode impor uma política que _só_ permita o acesso de sessões vinculadas a um dispositivo gerenciado específico. O DBSC fornece o mecanismo de aplicação técnica para essa política. ## 6. DBSC vs Alternativas Para apreciar plenamente o DBSC, devemos compará-lo com outras tecnologias que tentaram resolver problemas semelhantes. ```mermaid graph RL subgraph "Cookies tradicionais" TC1[Somente token de portador] TC2[Vulnerável a roubo] TC3[Sessões longas = Risco] TC1 --> TC2 TC2 --> TC3 end subgraph "Token Binding" TB1[Vinculação na camada TLS] TB2[❌ Falhou: Infraestrutura complexa] TB3[Quebrou em balanceadores de carga] TB1 --> TB2 TB2 --> TB3 end subgraph "DPoP" DP1[Vinculação de token OAuth] DP2[✅ Proteção de API] DP3[Não para sessões de navegador] DP1 --> DP2 DP2 --> DP3 end subgraph "DBSC" D1[Vinculação na camada HTTP] D2[✅ Proteção por chave de hardware] D3[✅ Funciona com CDNs/LBs] D4[✅ Sessões de navegador] 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 vs Token Binding Como mencionado, o Token Binding tentou vincular a sessão à camada TLS. - **Token Binding:** Exigia suporte do cliente, do servidor _e_ de cada salto intermediário (balanceadores de carga, terminadores TLS). Ele quebrava quando uma conexão era encerrada e criptografada novamente. - **DBSC:** [Opera na camada de aplicativo HTTP](https://fidoalliance.org/white-paper-dbsc-dpop-as-complementary-technologies-to-fido-authentication/). Ele passa pelos balanceadores de carga de forma transparente como cabeçalhos/cookies padrão. É muito mais fácil de implantar em arquiteturas de nuvem modernas (AWS/GCP/Azure), onde o TLS costuma ser tratado pela rede de borda do provedor de nuvem. ### 6.2 DBSC vs DPoP (Demonstrating Proof of Possession) O [DPoP (RFC 9449)](https://datatracker.ietf.org/doc/html/rfc9449) é o padrão para tokens OAuth "restritos ao remetente". Ele vincula tokens de acesso _e_ tokens de atualização a uma chave pública — essencial, já que os tokens de atualização são credenciais de portador de longa duração. Cada solicitação de API inclui uma prova DPoP: um JWT assinado com o método HTTP, URL, carimbo de data/hora e identificador exclusivo. Especificações de alta garantia como o [FAPI 2.0](https://openid.net/specs/fapi-2_0-security-profile.html) exigem tokens restritos ao remetente; o DPoP é o método recomendado quando o mTLS não está disponível. **A principal diferença:** as chaves do DPoP residem no contexto do aplicativo. A prática recomendada é usar APIs do sistema operacional para armazenamento não extraível, mas isso não é obrigatório — muitas implementações mantêm as chaves na memória acessível por JavaScript. Se um invasor puder executar código arbitrário (XSS, malware), ele poderá acessar as chaves DPoP ou gerar provas sob demanda. O DPoP impede a reprodução do token _entre diferentes clientes_, mas não pode proteger um contexto de navegador comprometido. O DBSC move a prova de posse para o navegador e o hardware. A chave privada reside em um TPM ou em um enclave seguro que o JavaScript não pode ler ou exportar. O navegador manipula o protocolo e produz assinaturas sem expor as chaves ao código do aplicativo. Mesmo que o aplicativo da web esteja totalmente comprometido, um invasor não poderá cunhar novas provas para cookies roubados em outra máquina. | Aspecto | DPoP | DBSC | | --------------------------- | --------------------------------------------------- | -------------------------------------- | | **Alvo** | Tokens de acesso + atualização OAuth | Cookies de sessão do navegador | | **Armazenamento de chaves** | Contexto do aplicativo (melhor prática: APIs do SO) | Baseado em hardware (TPM) | | **Resistência a XSS** | ⚠️ Dependente da implementação | ✅ Chaves não exportáveis | | **Uso primário** | Aplicativos nativos, SPAs, FAPI 2.0 | Sessões da web voltadas para o usuário | **Sinergia:** Como observa a [FIDO Alliance](https://www.corbado.com/glossary/fido-alliance), as chaves de acesso eliminam o phishing no login, enquanto o DBSC/DPoP protege os tokens pós-autenticação. Uma arquitetura moderna combina ambos: DPoP para APIs OAuth (especialmente em [sistemas bancários](https://www.corbado.com/passkeys-for-banking) abertos regulamentados), DBSC para sessões de navegador. Juntos, eles fecham o vetor de ataque "lift and shift" em todo o ciclo de vida da sessão. ### 6.3 DBSC vs Cookies de curta duração (sozinhos) Simplesmente encurtar a vida útil do cookie (por exemplo, para 15 minutos) melhora a segurança, mas destrói a UX. Os usuários são forçados a fazer login constantemente. O DBSC permite a segurança _efetiva_ de um cookie de 5 minutos com a _Experiência do Usuário_ de um cookie de 30 dias. ## 7. Sinais Compartilhados e Resposta Dinâmica (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 Ferramentas de segurança
(CrowdStrike, Defender) participant IdP as Provedor de Identidade
(Okta, Google, Azure) participant SP1 as Provedor de Serviços 1
(Slack) participant SP2 as Provedor de Serviços 2
(Salesforce) participant SP3 as Provedor de Serviços 3
(App Bancário) participant Session as Sessão do Usuário
(Protegida por DBSC) Note over ST,Session: Fase de Detecção de Ameaças ST->>ST: Detecta malware no
dispositivo do usuário ST->>IdP: Sinal RISC:
"Dispositivo Comprometido" Note over IdP,SP3: Fase de Propagação do Sinal IdP->>SP1: Evento CAEP:
"Dispositivo Comprometido" IdP->>SP2: Evento CAEP:
"Dispositivo Comprometido" IdP->>SP3: Evento CAEP:
"Dispositivo Comprometido" Note over SP1,Session: Fase de Execução (com DBSC) Session->>SP1: Próxima tentativa de atualização
(em minutos) SP1-->>Session: x Rejeitar assinatura Session->>SP2: Próxima tentativa de atualização SP2-->>Session: x Rejeitar assinatura Session->>SP3: Próxima tentativa de atualização SP3-->>Session: x Rejeitar assinatura Note over Session: As sessões podem ser encerradas na próxima tentativa de atualização ``` O potencial do DBSC é ampliado quando combinado com o [**Shared Signals Framework (SSF)**](https://fidoalliance.org/white-paper-fido-and-the-shared-signals-framework/), especificamente o **Continuous Access Evaluation Profile (CAEP)** e o **Risk Management (RISC)**. Nota: SSF/CAEP é um recurso de ecossistema emergente — o padrão de arquitetura está definido, mas a implantação entre fornecedores ainda está amadurecendo. No modelo antigo, se o dispositivo de um usuário fosse comprometido, o Provedor de Identidade (IdP) não tinha como informar o Provedor de Serviços (SP) para encerrar a sessão _agora mesmo_. O SP teria que esperar que o cookie expirasse. O fluxo imaginado de DBSC + CAEP: 1. **Gatilho:** Uma ferramenta de segurança de endpoint (como CrowdStrike ou Microsoft Defender) detecta malware no laptop do usuário. 2. **Sinal:** A ferramenta de segurança envia um sinal RISC para o Provedor de Identidade (por exemplo, Okta/Google). 3. **Propagação:** O IdP envia um evento CAEP aos aplicativos conectados: "Dispositivo Comprometido". 4. **Execução (DBSC):** Na próxima vez que o navegador tentar atualizar o cookie DBSC de curta duração, o servidor rejeitará a assinatura e encerrará a sessão.\ Este [padrão de arquitetura](https://fidoalliance.org/white-paper-fido-and-the-shared-signals-framework/) permite uma revogação mais rápida — a latência real depende do período de atualização do site e de se eles implementaram tanto o DBSC quanto o SSF. ## 8. Suporte ao navegador e ao ecossistema A adoção do DBSC depende dos fornecedores de navegadores. O cenário de 2026 mudou significativamente: o Chrome moveu o DBSC do Origin Trial para disponibilidade geral no Windows em abril de 2026, com o macOS chegando a seguir. Outros navegadores ainda estão avaliando. ### 8.1 Google Chrome O Google é o principal impulsionador do DBSC e o primeiro navegador a lançá-lo de forma ampla. - **Status (abril de 2026):** O [Chrome 146 lança o DBSC em disponibilidade geral no Windows](https://blog.google/security/protecting-cookies-with-device-bound-session-credentials/), encerrando a fase de Origin Trial. O suporte ao macOS, usando o [Secure Enclave](https://www.corbado.com/glossary/secure-enclave), foi anunciado para um próximo lançamento do Chrome. - **Hardware:** O Windows usa o TPM, o macOS usará o Secure Enclave. O Google afirmou que também está explorando **chaves baseadas em software** para estender a proteção DBSC a dispositivos sem hardware seguro dedicado. - **Roteiro:** O anúncio do GA do Google também publicou o roteiro da próxima etapa: - **Proteção da identidade federada:** vinculações DBSC entre origens para que a sessão da parte dependente (RP) permaneça vinculada à mesma chave de dispositivo que a sessão do provedor de identidade (IdP), preservando uma cadeia de confiança ininterrupta por meio do [SSO](https://www.corbado.com/blog/passkeys-single-sign-on-sso). - **Registro avançado:** vincular sessões DBSC a material de chave pré-existente e confiável, como **certificados mTLS** ou **chaves de segurança de hardware**, em vez de gerar uma nova chave no momento do login. - **Suporte a dispositivos mais amplo:** chaves baseadas em software para dispositivos sem TPM / Secure Enclave. - **Resultados operacionais:** Durante o lançamento, o Google relatou uma "redução significativa no roubo de sessão" para as sessões protegidas pelo DBSC. - **Contas do Google:** Separadamente, o Google já havia implementado proteção no estilo DBSC para [cookies de conta do Google no Chrome para Windows](https://support.google.com/chrome/a/answer/2657289), controlado via política corporativa. Isso protege o Gmail/Workspace e agora é a mesma família de tecnologia que é GA para a web em geral. ### 8.2 Microsoft Edge e Windows A Microsoft está participando ativamente. - **Status:** O Edge realizou um [Origin Trial do DBSC](https://developer.microsoft.com/microsoft-edge/origin-trials/trials/0c292c9b-58fe-4f23-b066-c3b58911024d) no Windows que terminou em outubro de 2025. Nenhum teste substituto ou GA foi anunciado. - **Contexto corporativo:** O Edge utiliza a arquitetura ["Primary Refresh Token" (PRT)](https://learn.microsoft.com/en-us/entra/identity/devices/concept-primary-refresh-token) para o Entra/Azure AD [SSO](https://www.corbado.com/blog/passkeys-single-sign-on-sso), que é conceitualmente semelhante ao DBSC. O PRT continua sendo um mecanismo específico da Microsoft; não há plano anunciado para unificá-lo com o padrão da web DBSC para sites de terceiros. ### 8.3 Apple Safari (WebKit) A postura da Apple é crítica para a cobertura móvel. - **Status:** O WebKit possui um [problema de posição de padrões](https://github.com/WebKit/standards-positions/issues/281) avaliando o DBSC com problemas observados de usabilidade/privacidade. As notas de versão do Safari não mencionam o DBSC. Não existe uma declaração pública de "implementação ativa". - **A privacidade em primeiro lugar:** a principal preocupação da Apple é que o DBSC possa ser usado como "super-cookies" (rastreamento que não pode ser excluído). A especificação do W3C aborda isso garantindo que as chaves sejam limpas com os dados do site. - **Engajamento:** O WebKit está engajado com o processo padrão, mas o status de implementação não é claro — "em discussão" em vez de "em desenvolvimento". ### 8.4 Mozilla Firefox A Mozilla possui um [problema de posição de padrões](https://github.com/mozilla/standards-positions/issues/912) avaliando o DBSC com preocupações observadas sobre complexidade e privacidade. Não há compromisso público para implementar uma vez que o padrão se estabilize. ## 9. Recomendações: protegendo os usuários hoje Dado o suporte atual do ecossistema para DBSC e chaves de acesso, as organizações devem adotar uma abordagem gradual para a implementação dessas tecnologias complementares. O roteiro a seguir descreve as ações imediatas e os marcos de planejamento estratégico: ### 9.1 Ações imediatas (agora que o Chrome 146 é GA) 1. **Implante as chaves de acesso primeiro**: Comece com a implementação das chaves de acesso para proteger a camada de autenticação. Isso fornece proteção imediata contra phishing de credenciais e é o pré-requisito para obter valor real do DBSC. 2. **Envie os endpoints de registro e atualização do DBSC**: Com o GA do Chrome 146, o trabalho realista agora é a integração de back-end: adicione os cabeçalhos `Secure-Session-Registration` nas respostas de login e implemente o `/dbsc/register` mais um endpoint de atualização que verifique os desafios assinados. O código front-end não precisa mudar. 3. **Implemente sessões de curta duração com tokens de atualização**: Se você ainda não está pronto para o DBSC, adote o padrão arquitetônico de tokens de curta duração com mecanismos de atualização. Isso prepara seu back-end para o DBSC e, ao mesmo tempo, melhora a segurança atual. ### 9.2 Planejamento estratégico (próximos 12 meses) 1. **Adote uma abordagem híbrida**: Use a detecção de recursos para fornecer o DBSC aos navegadores compatíveis (atualmente o Chrome 146+ no Windows, em breve o Secure Enclave do macOS), mantendo as opções de [fallback](https://www.corbado.com/pt/faq/login-segundo-dispositivo-chave-de-acesso-vinculada). Isso maximiza a segurança sem excluir os usuários do Safari, Firefox ou Edge. 2. **Prepare-se para os próximos itens do roteiro**: O Google mencionou explicitamente a identidade federada (vinculações de SSO entre origens), registro avançado (mTLS/chaves de hardware) e chaves baseadas em software para uma cobertura mais ampla de dispositivos. Se você opera uma camada de SSO ou IdP, comece a definir o escopo da vinculação entre origens agora. 3. **Integre com provedores de identidade**: Se estiver usando o Okta, [Auth0](https://www.corbado.com/blog/auth0-passkeys-analysis) ou IdPs semelhantes, trabalhe com eles para ativar o suporte ao DBSC em seus SDKs. Muitos participaram dos Origin Trials e estão enviando ativamente os recursos do DBSC agora que o Chrome é GA. ### 9.3 Melhores práticas de implementação - **Comece com alvos de alto valor**: Priorize o DBSC para painéis de administração, transações financeiras e acesso a dados confidenciais. - **Use soluções gerenciadas**: Considere plataformas como a Corbado, que lidam com a complexidade da implementação do DBSC e com a compatibilidade dos navegadores. - **Meça e itere**: Acompanhe métricas como tentativas de sequestro de sessão, tíquetes de suporte e atrito do usuário para demonstrar o ROI. - **Prepare-se para a conformidade**: Documente sua implementação do DBSC, pois ela provavelmente se tornará um requisito de conformidade para lidar com dados confidenciais. ## 10. Como a Corbado pode ajudar: Ponte para o futuro Implementar o DBSC do zero é um trabalho de engenharia pesado. Isso exige experiência criptográfica, conhecimento profundo das inconsistências dos navegadores e uma infraestrutura robusta no lado do servidor para gerenciar chaves e desafios. É aqui que a **Corbado** serve como um facilitador. ### 10.1 Fundação: Chaves de acesso Você não pode criar uma sessão de alta garantia sobre um login de baixa garantia. Se um usuário fizer login com uma senha fraca, a sessão será tão segura quanto essa senha. O principal produto da Corbado (**chaves de acesso gerenciadas**) fornece a base necessária. Ao integrar a Corbado, as organizações podem implantar chaves de acesso com facilidade, garantindo que o início da sessão seja [resistente a phishing](https://www.corbado.com/pt/blog/como-eliminar-senhas-por-completo). ### 10.2 Futuro: DBSC para detecção de dispositivos confiáveis A Corbado aproveitará o DBSC para aprimorar a detecção de dispositivos confiáveis. Quando os sinais do DBSC estiverem disponíveis, eles fornecerão provas criptográficas de que uma sessão se origina de um dispositivo específico, permitindo que a Corbado aumente os níveis de confiança de autenticação em conformidade. - **Resolvendo a ambiguidade das chaves de acesso sincronizadas:** As [chaves de acesso sincronizadas](https://www.corbado.com/pt/blog/chaves-de-acesso-vinculadas-dispositivo-vs-sincronizadas) são convenientes, mas criam uma lacuna de confiança: quando um usuário autentica com uma [chave de acesso](https://www.corbado.com/pt/blog/senhas-complexas-quebradas-em-breve) sincronizada, não há como saber se é seu laptop habitual ou um dispositivo totalmente novo que acabou de sincronizar a credencial. O DBSC fecha essa lacuna. Ao verificar se o dispositivo tem uma vinculação DBSC estabelecida, a Corbado pode confirmar se o dispositivo é realmente conhecido e confiável, não apenas uma sincronização pela primeira vez. - **Maior confiança para dispositivos conhecidos:** Quando os sinais do DBSC confirmam que um dispositivo já foi visto antes, a Corbado pode tomar decisões de risco com mais confiança: menos solicitações de [step-up authentication](https://www.corbado.com/glossary/step-up-authentication) para usuários legítimos que retornam, e escrutínio mais rigoroso para sessões de dispositivos não reconhecidos. - **Complementando a inteligência das chaves de acesso:** Os sinais do DBSC se integram ao mecanismo [**Passkey Intelligence**](https://docs.corbado.com/corbado-connect/features/passkey-intelligence) existente da Corbado. A combinação de autenticação baseada em chaves de acesso e vinculação de dispositivo baseada em DBSC cria uma cadeia de confiança completa desde o login até o ciclo de vida completo da sessão. Para tirar dúvidas sobre como a Corbado planeja integrar o DBSC à sua plataforma, [entre em contato com a equipe](https://www.corbado.com/contact). ### 10.3 Fallback gracioso (A realidade "Híbrida") Nos próximos anos, a web será híbrida. Alguns usuários terão navegadores compatíveis com o DBSC (Chrome no [Windows 11](https://www.corbado.com/blog/passkeys-windows-11)); outros estarão em sistemas mais antigos. Lidar com essa fragmentação é difícil. O mecanismo [**Passkey Intelligence**](https://docs.corbado.com/corbado-connect/features/passkey-intelligence) da Corbado é projetado para lidar exatamente com esse tipo de lógica de [fallback](https://www.corbado.com/pt/faq/login-segundo-dispositivo-chave-de-acesso-vinculada), fornecendo chaves de acesso a dispositivos compatíveis e fallbacks a outros. Essa mesma inteligência se aplica à vinculação de sessão, garantindo que a segurança seja maximizada para cada usuário de acordo com as capacidades de seus dispositivos. ## 11. Conclusão: O caminho a seguir para o DBSC A era do "Token de portador" está chegando ao fim. O gerenciamento atual de sessões está falhando catastroficamente — os tokens de portador podem ser roubados por operações de malware em escala industrial e usados de qualquer dispositivo, permitindo invasões de contas que contornam até mesmo os métodos mais fortes de autenticação. Essa vulnerabilidade fundamental criou uma economia subterrânea no valor de bilhões. O [Device Bound Session Credentials](https://www.corbado.com/blog/device-bound-session-credentials-dbsc) (DBSC) representa a resposta emergente do setor. Ao contrário dos cookies seguros tradicionais com seus sinalizadores HttpOnly e segredos estáticos, o DBSC adiciona a prova de posse criptográfica por meio de chaves vinculadas ao dispositivo. Isso torna os cookies roubados muito menos valiosos. Eles não podem ser atualizados em outro dispositivo. Onde o Token Binding falhou por exigir mudanças complexas na camada TLS em toda a infraestrutura, o DBSC é bem-sucedido operando na camada de aplicativo HTTP, compatível com os balanceadores de carga existentes e arquiteturas de CDN. Nota: O DBSC possui caminhos de [fallback](https://www.corbado.com/pt/faq/login-segundo-dispositivo-chave-de-acesso-vinculada) documentados em que o navegador ignora a vinculação (TPM não disponível, erros de rede), portanto, ele reduz muito, mas não elimina o risco de roubo de cookies. A sinergia entre o DBSC e as chaves de acesso eleva significativamente o nível de segurança para os invasores durante toda a jornada do usuário. As chaves de acesso eliminam o phishing de credenciais no momento do login, enquanto o DBSC torna o sequestro de sessão por meio de roubo remoto de cookies muito mais difícil - juntos, formando a estrutura de identidade de "alta garantia" que a [FIDO Alliance](https://www.corbado.com/glossary/fido-alliance) imagina. Com [o Chrome 146 lançando o DBSC em GA no Windows em abril de 2026](https://blog.google/security/protecting-cookies-with-device-bound-session-credentials/) e o suporte ao Secure Enclave do macOS chegando a seguir, o padrão passou da fase de preparação para a fase de lançamento. O roteiro publicado pelo Google (identidade federada, registro de mTLS / chave de hardware, chaves baseadas em software) sinaliza os próximos 12 meses de expansão. Para os gerentes de produto, o argumento comercial é convincente: o DBSC permite sessões seguras "infinitas" que reduzem drasticamente o atrito de login enquanto, simultaneamente, cortam perdas por fraudes e custos de suporte. O ROI se manifesta em taxas de conversão mais altas, menos tíquetes de redefinição de senha e incidentes eliminados de invasão de contas. As organizações que usam o OAuth podem aproveitar o mesmo conceito de vinculação de chaves por meio do DPoP para tokens de API, enquanto a integração com os Shared Signals (CAEP/RISC) permite a resposta a ameaças em tempo real — revogando instantaneamente as sessões comprometidas na próxima tentativa de atualização. A implementação não exige que se construa do zero. Plataformas como a [Corbado](https://www.corbado.com/features) fornecem a infraestrutura de chaves de acesso e estão acompanhando os desenvolvimentos do DBSC para integrar a vinculação de dispositivos à medida que o suporte aos navegadores amadurece. A [especificação do W3C](https://www.w3.org/TR/dbsc/) é um rascunho de trabalho ativo, o Chrome 146 é GA no Windows e está sendo lançado para macOS, e outros navegadores ainda estão avaliando o padrão. A trajetória é clara: as organizações que começarem a adotar as chaves de acesso e o DBSC hoje estarão melhor posicionadas para o futuro sem senha e resistente ao phishing. A questão não é se você deve implementar sessões vinculadas ao dispositivo, mas com que rapidez você pode implantá-las para proteger seus usuários e seus negócios. O futuro da segurança da web não é apenas autenticado; é criptograficamente vinculado aos dispositivos em que confiamos. ## Perguntas Frequentes ### Como o DBSC funciona com o CAEP e o RISC para revogar sessões comprometidas em tempo real? Quando ferramentas de segurança de endpoint, como o CrowdStrike, detectam malware, elas enviam um sinal RISC ao Provedor de Identidade, que envia um evento CAEP de 'Dispositivo comprometido' para os aplicativos conectados. Na próxima tentativa de atualização do DBSC (em minutos), esses aplicativos rejeitam a assinatura da sessão e encerram o acesso. A implantação de CAEP/RISC entre fornecedores ainda está amadurecendo. ### Qual é a diferença entre o DBSC e o DPoP para proteger sessões de aplicativos da web? O DPoP (RFC 9449) vincula tokens de acesso e de atualização do OAuth a uma chave pública na camada de aplicativo, protegendo principalmente chamadas de API em aplicativos nativos e SPAs. O DBSC vincula os cookies de sessão do navegador a chaves TPM baseadas em hardware que o JavaScript não pode ler ou exportar, protegendo as sessões voltadas para o usuário, mesmo quando o próprio aplicativo da web é comprometido por XSS ou malware. ### Por que o DBSC permite durações de sessão mais longas sem aumentar o risco de segurança? O design seguro tradicional exige tempos limite curtos de sessão para limitar os danos caso um cookie seja roubado e reproduzido remotamente. O DBSC vincula a capacidade de atualização à chave privada do dispositivo de origem, portanto, um cookie roubado usado a partir de um dispositivo diferente falha no desafio criptográfico. As sessões podem ser efetivamente indefinidas porque os ataques de reprodução remota são neutralizados. ### Qual ROI comercial as empresas podem esperar da implantação do DBSC? O DBSC neutraliza o roubo de cookies como o principal vetor de invasão de conta, reduzindo diretamente as perdas por fraude e os custos de suporte à recuperação de contas. Sessões longas e seguras eliminam as solicitações repetidas de login, melhorando as taxas de conversão no comércio eletrônico e reduzindo o abandono. A [FIDO Alliance](https://www.corbado.com/glossary/fido-alliance) posiciona o DBSC como algo que eleva o nível de segurança ao mesmo tempo em que reduz o atrito para o usuário.