Fri, 10 Apr 2026
← VoltarO DBSC aumenta a segurança vinculando sessões de autenticação aos dispositivos, evitando o roubo de cookies por meio de malware.
O roubo de biscoitos segue um padrão bem estabelecido. O malware Infostealer se infiltra em um dispositivo, extrai cookies de autenticação e os exfiltra para um servidor controlado pelo invasor. Como os cookies geralmente têm vida útil prolongada, os invasores podem acessar contas sem senhas e, em seguida, agrupar e vender as credenciais roubadas. Depois que o malware obtém acesso a uma máquina, ele pode ler os arquivos locais e a memória onde os navegadores armazenam cookies de autenticação.
O que o DBSC faz As credenciais de sessão vinculadas ao dispositivo (DBSC) do Google agora estão entrando em disponibilidade pública para usuários do Windows no Chrome 146, com suporte para macOS chegando em uma versão subsequente. O protocolo vincula criptograficamente sessões de autenticação a um dispositivo específico usando módulos de segurança apoiados por hardware: o Trusted Platform Module (TPM) no Windows e o Secure Enclave no macOS. Esses módulos geram um par de chaves pública/privada exclusivo que não pode ser exportado da máquina. Uma visão geral do protocolo DBSC mostrando a interação entre o navegador e o servidor (Fonte: Google) Quando uma sessão está ativa, o Chrome deve provar a posse da chave privada correspondente para o servidor antes que o servidor emita novos cookies de sessão.
Esses cookies duram pouco. Um invasor que os exfiltrar descobrirá que eles expiram rapidamente e não podem ser renovados sem a chave privada, que não pode sair do dispositivo. "Esse design permite que sites grandes e pequenos atualizem para sessões seguras e vinculadas ao hardware, adicionando registros dedicados e pontos de extremidade de atualização aos seus back-ends, mantendo a compatibilidade completa com o front-end existente. O navegador lida com a criptografia complexa e a rotação de cookies em segundo plano, permitindo que o aplicativo da web continue usando cookies padrão para acesso como sempre fez", explicaram os pesquisadores do Google.
O Google executou uma versão anterior do protocolo em suas próprias propriedades no ano passado. Para sessões protegidas pelo DBSC, o Google observou uma redução mensurável no roubo de sessões desde o início da implantação. Propriedades de privacidade Cada sessão DBSC é apoiada por uma chave criptográfica distinta. Essa arquitetura evita que os sites usem as credenciais para correlacionar a atividade de um usuário em diferentes sessões ou sites no mesmo dispositivo.
O protocolo não transmite identificadores de dispositivos ou dados de atestado ao servidor; ele compartilha apenas a chave pública por sessão necessária para verificar a prova de posse. Essa restrição impede que o DBSC funcione como um mecanismo de impressão digital de dispositivos ou permita o rastreamento entre sites. Padronização e envolvimento da indústria O DBSC foi desenvolvido através do processo W3C e adotado pelo Grupo de Trabalho de Segurança de Aplicações Web. O Google trabalhou com a Microsoft no design do padrão.
O Google também realizou dois Origin Trials no ano passado para coletar feedback da comunidade web mais ampla. A Okta estava entre as plataformas web que participaram desses testes e contribuiu com feedback sobre se o protocolo atende aos seus requisitos operacionais. O que vem a seguir O trabalho contínuo de desenvolvimento do Google no DBSC abrange três áreas. A primeira é a identidade federada: em ambientes corporativos onde o logon único é comum, a equipe está construindo ligações de origem cruzada para que uma sessão de terceira parte confiável permaneça continuamente vinculada à mesma chave de dispositivo usada durante o login inicial do provedor de identidade, preservando a cadeia de confiança em todo o processo federado.
A segunda área é o registro avançado. Alguns ambientes precisam de garantias mais fortes no momento em que uma sessão é criada pela primeira vez. O Google está desenvolvendo mecanismos para vincular sessões DBSC a materiais de chaves confiáveis pré-existentes, como certificados mTLS ou cha ves de segurança de hardware, no momento do registro. A terceira área é o suporte mais amplo a dispositivos.
O Google está explorando chaves baseadas em software para estender a proteção a dispositivos que não possuem hardware seguro dedicado. Download: Relatório Vermelho 2026 da Picus Security