A Google começou a disponibilizar ao público a tecnologia Device Bound Session Credentials (DBSC) para usuários do Windows no navegador Chrome 146, após anunciá-la pela primeira vez em abril de 2024, com expansão para o macOS prevista para uma futura versão do Chrome. A tecnologia tem como alvo um dos problemas mais comuns de segurança de sessões: o roubo de cookies que permite aos invasores acessar contas sem precisar de senhas.
O roubo de sessões geralmente ocorre quando o usuário baixa um malware sem querer. Depois de executado, o programa pode extrair os cookies atuais do navegador ou esperar que o usuário faça login em novas contas e, então, enviar esses tokens para um servidor controlado pelo invasor. A Google afirma que famílias de malwares ladrões de informações, como o LummaC2, tornaram-se mais sofisticadas na coleta de credenciais.
O risco desses cookies aumenta devido ao período de validade prolongado de alguns deles; os invasores podem usá-los para obter acesso não autorizado às contas e, depois, agrupá-los, negociá-los ou vendê-los entre agentes criminosos. Além disso, malwares avançados, depois de obterem acesso ao dispositivo, conseguem ler os arquivos e a memória nos quais os navegadores armazenam cookies de autenticação. Por isso, a Google considera que não há uma forma confiável de impedir a extração de cookies apenas com software, independentemente do sistema operacional.
Vinculando a sessão a uma chave que não deixa o dispositivo
A DBSC muda esse modelo ao vincular criptograficamente a sessão de autenticação a um dispositivo específico. A tecnologia usa módulos de segurança com suporte de hardware, como o TPM no Windows e o Secure Enclave no macOS, para criar um par exclusivo de chaves pública e privada. A chave privada não pode ser exportada do dispositivo.
O servidor só emite novos cookies de curta duração depois que o Chrome comprova que possui a chave privada vinculada à sessão. Como o invasor não consegue roubar essa chave, quaisquer cookies extraídos expiram rapidamente e se tornam inúteis para acessar as contas. A Google afirma ter observado uma grande redução no roubo de sessões protegidas pela DBSC desde o lançamento de uma versão inicial do protocolo durante o ano passado.
Sites grandes e pequenos podem adotar sessões vinculadas ao hardware adicionando endpoints dedicados de registro e atualização aos seus sistemas de back-end, mantendo a compatibilidade com a interface front-end atual. O navegador cuida das operações complexas de criptografia e da rotação dos cookies em segundo plano, enquanto o aplicativo web continua usando cookies padrão para acessar seus serviços.
Protegendo sessões sem rastrear o usuário
A DBSC foi projetada levando a privacidade em consideração. Cada sessão é baseada em uma chave separada, impedindo que os sites usem essas credenciais para vincular a atividade do usuário entre sessões diferentes ou entre vários sites no mesmo dispositivo. O protocolo também não envia ao servidor identificadores do dispositivo nem dados de atestação, com exceção da chave pública da sessão, necessária para comprovar a posse da chave privada.
Segundo a Google, essa troca limitada de informações reduz os riscos de usar a tecnologia para rastreamento entre sites ou para criar uma impressão digital identificadora do dispositivo.
Um padrão aberto e em desenvolvimento contínuo
A DBSC foi projetada desde o início como um padrão aberto para a web por meio do processo do W3C e da adoção pelo grupo de trabalho de segurança de aplicativos web. A Google colaborou com a Microsoft na criação do padrão, enquanto diversas plataformas web, incluindo a Okta, participaram dos testes de Origin Trials durante o ano passado e forneceram feedback com base nos testes e no uso.
A Google oferece aos desenvolvedores um guia de implementação, além das especificações do protocolo, de um repositório no GitHub e de uma página para relatar bugs ou sugerir recursos.
As áreas de desenvolvimento futuras incluem:
- Proteção da identidade federada: expandir a DBSC para permitir a vinculação entre diferentes recursos, de modo que a sessão da parte confiadora permaneça vinculada à chave original do dispositivo usada junto ao provedor de identidade durante todo o processo de login único.
- Recursos avançados de registro: vincular sessões a materiais de chave confiáveis já existentes, como certificados mTLS ou chaves de segurança de hardware, em vez de criar uma nova chave no momento do login.
- Suporte a uma gama maior de dispositivos: estudar a adição de chaves baseadas em software para proteger dispositivos que não incluem hardware de segurança dedicado.