Imagine que um criminoso rouba o cookie de sessão do seu banco ou e-mail — aquele pequeno arquivo que prova ao servidor que você já fez login — e usa isso para entrar na sua conta sem precisar da sua senha, sem precisar do seu segundo fator de autenticação, sem deixar rastro. Esse ataque, chamado de session hijacking (sequestro de sessão), é uma das formas mais silenciosas e devastadoras de comprometimento de contas na internet. E ele está em alta. Agora, o Google acaba de ativar no Chrome uma proteção que promete tornar esse tipo de golpe praticamente inútil: o Device Bound Session Credentials (DBSC).
Segundo o Ars Technica, o Chrome está adotando o DBSC como o que pode ser a melhor proteção já criada contra esse tipo de sequestro de conta. A mudança não é apenas mais uma atualização de segurança cosmética — ela representa uma mudança de paradigma na forma como os navegadores gerenciam sessões autenticadas. Para o usuário brasileiro, que lida com um dos ambientes de fraude digital mais agressivos do mundo, entender o que muda é essencial.
O problema: por que roubar cookies ainda funciona em 2026
Autenticação de dois fatores (2FA), senhas fortes, gerenciadores de senha — tudo isso resolve o problema de login, mas não o problema de sessão. Quando você faz login em qualquer serviço, o servidor gera um cookie de sessão e o armazena no seu navegador. A partir daí, cada requisição que você faz carrega esse cookie, e o servidor entende: “esse é o usuário autenticado”. O problema é que esse cookie é um arquivo de texto. Se um malware, um ataque de phishing sofisticado ou uma injeção de script conseguir extraí-lo do seu navegador, o atacante pode simplesmente importá-lo no próprio navegador e estar logado como você — em qualquer lugar do mundo, sem precisar da sua senha ou do seu celular.
Esse vetor é especialmente crítico porque o 2FA não ajuda em nada aqui: a sessão já foi autenticada. O token de autenticação foi gerado antes do roubo. Famílias inteiras de malware — como o Lumma Stealer, o Raccoon e o RedLine — têm como função primária exatamente isso: extrair cookies de sessão de navegadores para venda em mercados clandestinos. No Brasil, esse tipo de credencial roubada alimenta golpes bancários, fraudes em e-commerce e invasões a contas corporativas.
A solução: o que é o DBSC e como ele funciona
O Device Bound Session Credentials resolve o problema na raiz ao vincular criptograficamente a sessão ao dispositivo físico do usuário. Em vez de um cookie de sessão ser um arquivo de texto transportável, o DBSC faz com que a validade da sessão dependa de uma chave criptográfica privada armazenada no chip de segurança do dispositivo — o TPM (Trusted Platform Module), presente na maioria dos computadores modernos com Windows 11, ou equivalentes em Mac e Linux.
O funcionamento, em termos práticos, é o seguinte: quando você faz login em um site que suporta DBSC, o Chrome gera um par de chaves criptográficas (pública e privada) no TPM do seu dispositivo. A chave privada nunca sai do hardware — ela não pode ser exportada, copiada ou extraída por software, nem mesmo por malware com privilégios elevados. O servidor armazena a chave pública e, periodicamente, desafia o navegador a provar que ainda está no mesmo dispositivo, assinando um token com a chave privada. Se o cookie for roubado e usado em outro computador, o desafio falha — porque a chave privada não está lá.
“Device-bound session credentials thwart an increasingly common form of account takeover” — Ars Technica, descrevendo o impacto prático do DBSC no Chrome.
Vale destacar que o DBSC não substitui o 2FA nem a senha — ele atua em uma camada diferente e complementar. A autenticação inicial continua igual. O que muda é que, após o login, a sessão fica amarrada ao hardware. É como se o seu crachá de acesso ao banco fosse biométrico e intransferível: mesmo que alguém o copie, não funciona em outro corpo.
Ficha técnica da proteção: o que muda no Chrome
| Característica | Sessões tradicionais (cookies) | DBSC (Device Bound Session Credentials) |
|---|---|---|
| Armazenamento da credencial | Arquivo de texto no navegador | Chave criptográfica no TPM/hardware |
| Exportável/copiável | Sim — facilmente | Não — chave privada nunca sai do chip |
| Útil se roubado em outro dispositivo | Sim | Não |
| Requer suporte do site | Não | Sim (adoção progressiva) |
| Compatível com 2FA existente | Sim | Sim (camada adicional) |
| Requer hardware especial | Não | TPM 2.0 (padrão desde 2016) |
Limitações reais: o que o DBSC não resolve
Transparência é fundamental aqui. O DBSC é uma proteção poderosa, mas não é bala de prata. Primeiro, os sites precisam implementar suporte ativo à tecnologia — ela não funciona automaticamente em qualquer página. O Google já anunciou suporte no Google Accounts, e espera-se que grandes plataformas (Microsoft, bancos, redes sociais) adotem progressivamente. Mas a maioria dos sites menores vai demorar anos para implementar.
Segundo, o DBSC não protege contra ataques que ocorrem enquanto a sessão está ativa no dispositivo legítimo — como ataques man-in-the-browser, onde o malware injeta código diretamente no navegador e faz requisições a partir do dispositivo correto. Terceiro, dispositivos sem TPM 2.0 — computadores mais antigos, alguns modelos de entrada — não se beneficiam da proteção em sua forma mais robusta.
Por fim, há a questão da privacidade: vincular sessões ao hardware levanta preocupações legítimas sobre rastreamento de dispositivos. O Google afirma que o design do DBSC foi pensado para evitar que isso vire um mecanismo de fingerprinting, com chaves diferentes por site e sem identificador global — mas a implementação real precisará ser auditada pela comunidade de segurança ao longo do tempo.
Contexto: por que isso importa agora
O timing não é acidental. O mercado de infostealer malware — programas especializados em roubar credenciais e cookies — explodiu nos últimos três anos. Segundo relatórios da indústria de segurança, logs de infostealers com cookies de sessão válidos são vendidos por valores que variam de alguns dólares a centenas de dólares por lote, dependendo do valor das contas comprometidas. Serviços de streaming, contas bancárias, painéis de e-commerce e até contas de jogos (com itens valiosos ou skins raras) são alvos frequentes.
No Brasil, o cenário é particularmente grave. O país é historicamente um dos mais afetados por malware bancário e fraudes digitais na América Latina. Golpes que combinam phishing, malware de roubo de sessão e engenharia social custam bilhões de reais por ano ao sistema financeiro e a consumidores individuais. Uma tecnologia como o DBSC, quando adotada pelos grandes bancos digitais brasileiros — Nubank, Itaú, Bradesco, Inter — poderia reduzir drasticamente esse vetor de ataque.
O Chrome domina cerca de 65% do mercado de navegadores no Brasil, segundo dados históricos do StatCounter. Isso significa que, quando o DBSC estiver amplamente implementado, a maioria dos usuários brasileiros estará protegida automaticamente — sem precisar instalar nada, sem configurar nada. A proteção é transparente.
Comparação com proteções existentes
Vale comparar o DBSC com outras abordagens de segurança de sessão que já existem. O cookie HttpOnly impede que JavaScript leia o cookie, mas não impede que malware com acesso ao sistema de arquivos o extraia. O SameSite cookie protege contra CSRF (Cross-Site Request Forgery), mas não contra roubo direto. As passkeys (chaves de acesso, baseadas em FIDO2) resolvem o problema do login sem senha, mas também não protegem a sessão pós-autenticação. O DBSC preenche exatamente essa lacuna que as outras tecnologias deixam em aberto.
A Microsoft está desenvolvendo tecnologia similar para o Edge, e o padrão está sendo discutido no W3C (o consórcio que define os padrões da web), o que sugere que pode se tornar uma especificação universal de navegadores no futuro. Firefox ainda não anunciou adoção, mas a pressão do ecossistema deve acelerar isso.
O que isso significa para você
Para o usuário comum e gamer: No curto prazo, nada muda na sua experiência — você não vai notar diferença alguma. No médio prazo, quando plataformas como Steam, Battle.net e contas de jogos implementarem DBSC, o risco de ter sua conta invadida por roubo de sessão cai drasticamente. Quem já perdeu uma conta com centenas de horas de jogo ou itens valiosos sabe o quanto isso importa. Mantenha o Chrome atualizado e certifique-se de que seu PC tem TPM 2.0 habilitado na BIOS.
Para quem trabalha com criação de conteúdo ou usa serviços em nuvem: Contas do Google Workspace, YouTube, Adobe Creative Cloud e similares são alvos valiosos. O DBSC, já implementado nas contas Google, começa a proteger exatamente essas contas. Se você usa o Chrome como navegador principal de trabalho (e a maioria usa), já está no caminho certo.
Para quem usa o PC para trabalho corporativo ou lida com dados sensíveis: Essa é a notícia mais relevante do ciclo. Ataques de sequestro de sessão são um vetor comum em comprometimentos corporativos — um funcionário infectado com infostealer pode expor credenciais de sistemas internos mesmo com 2FA ativo. Administradores de TI devem monitorar a adoção do DBSC pelas ferramentas que utilizam e considerar políticas que incentivem o uso do Chrome com TPM habilitado em dispositivos corporativos.
Custo-benefício: Zero. A proteção é gratuita, vem embutida no Chrome e não exige hardware adicional para quem já tem um PC com TPM 2.0 — o que inclui praticamente qualquer máquina vendida nos últimos cinco anos com Windows 11. Se você ainda usa Windows 10 em hardware antigo sem TPM, esse é mais um motivo para considerar uma atualização de hardware no futuro próximo.
O DBSC não é a solução final para todos os problemas de segurança na web — nenhuma tecnologia isolada é. Mas é um passo genuinamente importante, que fecha uma brecha que os atacantes exploram há mais de uma década. Quando grandes sites brasileiros — especialmente bancos e fintechs — adotarem o padrão, o impacto prático para o consumidor nacional será significativo. Vale ficar de olho.
