Credenciais de sessão vinculadas ao dispositivo (DBSC) explicadas

Whitepaper empresarial de Passkeys. Guias práticos, padrões de implementação e KPIs para programas de passkeys.

Obter whitepaper

Status de suporte dos navegadores

Legenda: ✅ Disponibilidade geral | 🚧 Anunciado/em desenvolvimento | ⏸️ Teste encerrado | 🔄 Avaliando/monitorando | ❌ Ainda não disponível

Nota: o DBSC é GA no Windows com TPM a partir do Chrome 146 (abril de 2026). O suporte ao macOS por meio do 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

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 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. 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 por meio da adoção dos padrões FIDO (Fast Identity Online) e chaves de acesso, os invasores estão mudando seu foco para a "porta dos fundos": a sessão ativa. Fazer 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 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. Com o Chrome 146 (abril de 2026) lançando o DBSC em GA no Windows, 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, projetada para arquitetos de segurança, gerentes de produto e desenvolvedores. Ele explora a arquitetura técnica, as implicações comerciais da "segurança 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 funcionam juntos para uma resistência mais forte ao 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?
9. Como o DBSC se integra ao Shared Signals (CAEP/RISC) para resposta a ameaças em tempo real?

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.

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 (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 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, 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.

O DBSC introduz um segundo fator de autenticação 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. Periodicamente, o navegador deve provar que ainda possui a chave privada, assinando um desafio do servidor. A especificação exige um armazenamento de chaves "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.

As chaves de acesso 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 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 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.

Como as chaves de acesso e o DBSC funcionam juntos

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). Ele não depende da conexão de rede subjacente, tornando-o compatível com balanceadores de carga, proxies e infraestrutura de nuvem existentes.

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 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.

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.

graph TD
    A[Usuário baixa<br/>software malicioso] -->|Execução| B[Infostealer é ativado<br/>no dispositivo]
    B --> C[Localiza dados do navegador]
    C --> D[Armazenamento de cookies do<br/>Chrome/Edge/Firefox]
    C --> E[Banco de dados de senhas]
    C --> F[Carteiras de criptomoedas]

    D --> G[Descriptografa usando as<br/>credenciais do SO]
    E --> G
    F --> G

    G --> H[Cria arquivo de log<br/>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<br/>próprio navegador]
    L --> M[Contorna o MFA]
    M --> N[Invasão de conta<br/>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-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) 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 (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 de criptomoedas.

Esses logs são agregados e vendidos em mercados da dark web 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 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 (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, aparecendo para o servidor como se o usuário estivesse retornando a uma guia ativa.

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 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 / chaves de acesso interrompe) para roubo de cookies (que 2SV / chaves de acesso geralmente não interrompe).

Historicamente, os mecanismos de risco tentaram detectar o roubo de sessão analisando impressões digitais de dispositivos, observando a string User-Agent, 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.

O Device Bound Session Credentials (DBSC) introduz uma API e protocolo padronizados 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.

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.

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

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, 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
   
   \<JWT Header\>.\<JWT Payload containing Public Key\>.\<Signature\>
   

4. Vinculação de sessão: O servidor valida a assinatura para garantir que a chave pública 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 específica. A partir deste momento, a sessão está "vinculada".

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.

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: \<Session ID\>
   Secure-Session-Response: \<JWT Signature of Challenge\>
   

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.

graph LR
    subgraph "Dispositivo da vítima"
        A[Sessão do usuário<br/>com DBSC]
        B[Chave privada<br/>HSM/TPM]
        C[Cookie +<br/>ID da sessão]
        A --> B
        A --> C
        B -.->|Não exportável| X[Não é possível extrair<br/>a chave privada]
    end

    subgraph "Cenário de ataque"
        D[RedLine Stealer<br/>infecta o dispositivo]
        D --> E[Rouba cookie<br/>e ID da sessão]
        E --> F[Exporta para<br/>o invasor]
    end

    subgraph "Dispositivo do invasor"
        G[Importa cookie<br/>roubado]
        H[Tenta<br/>usar a sessão]
        I[O servidor solicita a<br/>atualização do DBSC]
        J[Não consegue assinar<br/>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.

A privacidade é um objetivo central de design do DBSC. A especificação do W3C 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.

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.

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.

As iniciativas de segurança são frequentemente vistas como centros de custo 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 é cara. Prevenir o hack em primeiro lugar reduz diretamente esse fardo operacional.
• Otimização de conversão: No comércio eletrônico, 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.

Estruturas regulatórias como o RGPD (Regulamento Geral sobre a Proteção de Dados) 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 2 exige a "Autenticação Forte do Cliente" (SCA). Embora o SCA se concentre no login, a vinculação dinâmica 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.

Os white papers da FIDO Alliance destacam o conceito de "Níveis de Garantia".

• Garantia moderada: Usa chaves de acesso sincronizadas (como as do 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 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.

Para apreciar plenamente o DBSC, devemos compará-lo com outras tecnologias que tentaram resolver problemas semelhantes.

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

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. 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.

O DPoP (RFC 9449) é 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 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.

Sinergia: Como observa a 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 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.

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.

%%{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<br/>(CrowdStrike, Defender)
    participant IdP as Provedor de Identidade<br/>(Okta, Google, Azure)
    participant SP1 as Provedor de Serviços 1<br/>(Slack)
    participant SP2 as Provedor de Serviços 2<br/>(Salesforce)
    participant SP3 as Provedor de Serviços 3<br/>(App Bancário)
    participant Session as Sessão do Usuário<br/>(Protegida por DBSC)

    Note over ST,Session: Fase de Detecção de Ameaças
    ST->>ST: Detecta malware no<br/>dispositivo do usuário
    ST->>IdP: Sinal RISC:<br/>"Dispositivo Comprometido"

    Note over IdP,SP3: Fase de Propagação do Sinal
    IdP->>SP1: Evento CAEP:<br/>"Dispositivo Comprometido"
    IdP->>SP2: Evento CAEP:<br/>"Dispositivo Comprometido"
    IdP->>SP3: Evento CAEP:<br/>"Dispositivo Comprometido"

    Note over SP1,Session: Fase de Execução (com DBSC)
    Session->>SP1: Próxima tentativa de atualização<br/>(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), 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 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.

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.

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, encerrando a fase de Origin Trial. O suporte ao macOS, usando o 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.
  • 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, 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.

A Microsoft está participando ativamente.

• Status: O Edge realizou um Origin Trial do DBSC 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) para o Entra/Azure AD 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.

A postura da Apple é crítica para a cobertura móvel.

• Status: O WebKit possui um problema de posição de padrões 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".

A Mozilla possui um problema de posição de padrões 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.

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:

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.

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. 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 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.

• 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.

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.

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.

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 são convenientes, mas criam uma lacuna de confiança: quando um usuário autentica com uma chave de acesso 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 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 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.

Nos próximos anos, a web será híbrida. Alguns usuários terão navegadores compatíveis com o DBSC (Chrome no Windows 11); outros estarão em sistemas mais antigos. Lidar com essa fragmentação é difícil. O mecanismo Passkey Intelligence da Corbado é projetado para lidar exatamente com esse tipo de lógica de fallback, 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.

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 (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 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 imagina. Com o Chrome 146 lançando o DBSC em GA no Windows em abril de 2026 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 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 é 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.

Sobre a Corbado

Corbado é a Passkey Intelligence Platform para times de CIAM que rodam autenticação consumer em escala. Mostramos o que logs de IDP e ferramentas genéricas de analytics não enxergam: quais dispositivos, versões de SO, navegadores e gerenciadores de credenciais suportam passkeys, por que os registros não viram logins, onde o fluxo WebAuthn falha e quando uma atualização de SO ou navegador quebra silenciosamente o login — tudo sem substituir Okta, Auth0, Ping, Cognito ou seu IDP interno. Dois produtos: Corbado Observe adiciona observabilidade para passkeys e qualquer outro método de login. Corbado Connect entrega passkeys gerenciados com analytics integrado (junto ao seu IDP). VicRoads roda passkeys para mais de 5M de usuários com Corbado (+80% de ativação de passkey). Fale com um especialista em Passkeys →

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.

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.

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.

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 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.