Adeus aos cookies roubados agora a autenticação fica ligada ao dispositivo no Chrome

Há anos que os atacantes procuram formas simples e lucrativas de acessar contas online: em vez de quebrar senhas, roubam o que já concede acesso temporário a um serviço: os cookies de sessão. Esses tokens, se duram o suficiente, permitem a um intruso entrar em uma conta sem necessidade de conhecer a senha, e muitas vezes acabam empacotados e revendidos no mercado do crime cibernético. Para contrariar esta ameaça, o Google decidiu atar essas sessões à própria máquina do usuário através de uma tecnologia que agora começa a chegar a todos os usuários do Chrome no Windows.

Device Bound Session Credentials (DBSC) É a resposta do Google ao problema da “exfiltração de sessões”. Em termos simples, em vez de a mera posse de um cookie baste para entrar em uma conta, o Chrome pode exigir que o navegador demonstre criptograficamente que o cookie está sendo usado desde o mesmo dispositivo que a gerou. Desse modo, se um malware consegue copiar o cookie e a envia para um servidor controlado pelo atacante, esse cookie perde valor porque não pode provar que provém do equipamento legítimo.

A técnica apoia-se em módulos de segurança presentes no hardware: no Windows se aproveita o Trusted Platform Module (TPM) e, em computadores Apple, o equivalente seria o Secure Enclave. Estes ambientes permitem criar chaves criptográficas privadas que não podem ser exportadas fora do dispositivo. Quando o servidor precisa de emitir ou renovar um token de sessão, solicita ao Chrome um teste de posse dessa chave privada. Chrome assina ou participa em um protocolo que demonstra essa posse sem revelar a chave em si. O resultado é que os cookies são convertidos em efímeras e ligados à máquina, não transferíveis.

O Google começou a testar o DBSC em versão beta aberta e agora anuncia que a funcionalidade está disponível para todos os usuários do Windows que atualizem o Chrome 146; o suporte para macOS chegará em uma versão posterior do navegador. A empresa explica que, quando o dispositivo não possui armazenamento seguro de chaves, o DBSC não quebra o fluxo de autenticação: simplesmente volta ao comportamento tradicional para não deixar o usuário sem acesso. Esta transição suave é importante para não causar fricções em equipamentos mais antigos ou em ambientes virtualizados onde não exista TPM físico.

Os impulsores da função afirmam ter observado uma redução notável nas tentativas de roubo de sessão desde os primeiros testes, o que sugere que atar as sessões ao hardware pode degradar significativamente a rentabilidade do negócio para os operadores de "stealers" - famílias de malware que extraem dados do sistema. Se você quer entender como esses programas maliciosos funcionam e porque são tão perigosos, há análises técnicas acessíveis por exemplo no blog de Malwarebytes sobre famílias como Vidar e outras ameaças semelhantes: Malwarebytes Labs.

O DBSC não surge num vácuo: faz parte de uma tendência maior para a autenticação «ligada ao dispositivo» e o uso generalizado de elementos seguros de hardware. Nesse ecossistema há ligações com padrões e tecnologias como a WebAuthn e a FIDO Alliance, que buscam reduzir a dependência de palavras-passe e levar a verificação criptográfica à autenticação cotidiana. Se você se interessar por aprofundar as normas de autenticação moderna, a FIDO Alliance oferece documentação acessível: fidoalliance.org.

Privacidade e limites. O Google concebeu a arquitetura com critérios claros de privacidade: a verificação é feita com uma chave por sessão e, segundo a empresa, não implica enviar identificadores do dispositivo nem dados de atestação que permitam correlacionar atividade entre sites. Por outras palavras, a intenção é melhorar a segurança sem converter as chaves de sessão num mecanismo de acompanhamento. Isso é importante porque uma solução que protegesse sessões, mas permitisse perfilar usuários teria sido inaceitável.

No entanto, existem limitações práticas que convém ter em conta. Se um atacante conseguir um controle completo do dispositivo (por exemplo, através de um rootkit ou acesso físico prolongado), pode restaurar ou manipular estados locais e potencialmente sortear mitigações. Além disso, ambientes virtualizados e máquinas sem TPM físico representam desafios: o mecanismo simplesmente se desactiva e volta ao comportamento tradicional para manter a usabilidade. Há também questões operacionais para empresas: a gestão de dispositivos, a migração de utilizadores entre máquinas, ou políticas de recuperação de credenciais podem exigir soluções complementares (por exemplo, escrows de chaves ou procedimentos de restauração) que devem ser concebidas com cuidado.

No plano institucional, a chegada de DBSC representa um ponto interessante para equipamentos de segurança e administradores: pode reduzir o risco associado a cookies roubados, mas não substitui outras defesas. A combinação de múltiplas camadas —atualizações frequentes do navegador, autenticação multifator (MFA), proteção endpoint e formação ao usuário sobre o perigo do malware — continua sendo a estratégia mais robusta. Para entender melhor o papel do TPM no Windows e como se integra na cadeia de confiança, a Microsoft oferece documentação técnica acessível aqui: Microsoft Learn – TPM. A Apple, por sua vez, documenta seu Secure Enclave em suas páginas de segurança do desenvolvedor: Secure Enclave – Apple.

Outro aspecto positivo é que o Google trabalhou com a Microsoft para que o projeto seja compatível com um objetivo mais amplo: converter a técnica em algo interoperável e, na medida do possível, convertível em um padrão aberto que outros navegadores e serviços possam adotar. Essa abordagem colaborativa aumenta as chances de que a proteção não fique limitada a um único ecossistema e, com sorte, oeve a segurança do conjunto da web.

Para o usuário meio o conselho é direto: manter o Chrome atualizado (a proteção chega com versões recentes), usar MFA em todas as contas que o permitam e considerar chaves físicas de segurança quando possível. Em ambientes empresariais, os equipamentos de TI devem avaliar como a DBSC se encaixa nas suas políticas de gestão de dispositivos e nos seus fluxos de recuperação de contas. O objetivo não é substituir as boas práticas, mas reduzir uma janela de exposição que até agora era especialmente rentável para os atacantes.

Se você quer ler as notas oficiais das atualizações do Chrome ou seguir as informações de segurança publicadas pelo Google, as páginas de anúncios do Chrome e o blog de segurança do Google são bons pontos de partida: Chrome Releases e Google Security Blog. A combinação destas peças — documentação do navegador, informação sobre o hardware de segurança e análise de ameaças — ajuda a entender por que atar sessões ao dispositivo pode representar uma melhoria real na luta contra o roubo de sessões.