A recuperação de senhas online costumava significar entregar seu arquivo a um servidor remoto e confiar nele. A recuperação baseada no navegador inverte isso: o arquivo nunca sai do seu dispositivo, e o trabalho criptográfico acontece localmente por meio do WebAssembly. Este post explica como isso é possível e por que é uma melhoria significativa de privacidade.

O modelo antigo: enviar e torcer

As ferramentas clássicas de recuperação online pedem que você envie o arquivo para um servidor que faz o trabalho. O problema é que um ZIP ao qual você perdeu o acesso costuma ser exatamente o tipo de arquivo que você menos gostaria de entregar, como registros financeiros, backups ou documentos pessoais.

Uma vez enviado, esse arquivo passa a residir no disco de outra pessoa. Ele pode ser registrado em logs, armazenado em cache ou retido, e você não tem como verificar o que realmente acontece com ele. Mesmo quando o serviço tem boas intenções, enviar dados sensíveis simplesmente amplia o número de lugares dos quais eles podem vazar.

O modelo que roda primeiro no seu dispositivo

Os navegadores modernos podem fazer tudo o que a recuperação precisa sem um servidor no meio:

  • A File API lê os bytes do arquivo diretamente do seu disco para a memória da página quando você seleciona o arquivo. Esses bytes permanecem na aba do navegador.
  • O WebAssembly executa a criptografia pesada, incluindo PBKDF2, HMAC e CRC, rápido o suficiente para testar senhas localmente. Na derivação de chave do AES, a ferramenta também mede a Web Crypto nativa do navegador e a usa no lugar quando ela é mais rápida no seu dispositivo.
  • Um conjunto de Web Workers, um por núcleo da CPU, executa a busca em threads em segundo plano, de modo que a interface permanece responsiva. As candidatas de máscara e força bruta são geradas dentro dos workers; uma lista de palavras que você digita ou abre de um arquivo é entregue a eles pela página. Nenhuma delas é enviada pela rede.

Nada nesse fluxo exige o envio do seu arquivo para lugar nenhum.

Por que o WebAssembly importa aqui

Verificar uma senha AES é dominado pelo PBKDF2-HMAC-SHA1 com 1000 iterações, calculado uma vez por tentativa. Esse é um laço numérico intenso, exatamente o tipo de trabalho que o JavaScript puro faz de forma relativamente lenta e que o WebAssembly compilado faz rapidamente. Executar o caminho crítico em WebAssembly, ou na Web Crypto nativa do navegador, em vez de JavaScript puro, é o que torna a recuperação local prática em vez de dolorosamente lenta. Isso não muda a matemática subjacente, mas permite que seu próprio hardware teste muito mais candidatas por segundo.

O que realmente acontece, passo a passo

  1. Você escolhe um arquivo. O navegador o lê localmente, e o arquivo não é enviado a lugar nenhum.
  2. A página analisa a estrutura do arquivo para encontrar suas entradas, detectar o esquema de criptografia e escolher a entrada que os workers vão testar, de preferência a menor entrada criptografada grande o bastante para confirmar uma senha de forma decisiva (entre as entradas de até 256 MB comprimidos).
  3. As candidatas de máscara e força bruta são geradas dentro dos workers; uma lista de palavras (a sua e, se ativada, a lista embutida de senhas comuns) é passada a eles pela página, e os workers acrescentam as variações que você ativou.
  4. Cada candidata é verificada primeiro com o filtro barato e, depois, com uma verificação de confirmação para qualquer sobrevivente.
  5. Quando uma senha é confirmada, ela é exibida para você, apenas na sua tela.

Em nenhum momento o arquivo, uma candidata ou a senha final é transmitido. A etapa de confirmação recalcula o HMAC no AES, e descriptografa e verifica o CRC-32 em uma entrada ZipCrypto de pelo menos 4 bytes armazenada (Store) ou comprimida com Deflate, então em um arquivo AES uma senha errada praticamente nunca é relatada, e em quase todos os ZipCrypto uma senha relatada passou por uma verificação que uma senha errada supera cerca de uma vez a cada 2^40 candidatas: muito raramente, mas não nunca numa busca muito longa. Quando só uma entrada ZipCrypto mais curta pode ser testada, o resultado informa que a senha passou apenas por uma verificação rápida. A página como funciona explica a rara exceção e dá o quadro completo.

Por que o processamento local é de fato mais privado

  • O arquivo nunca sai do seu dispositivo, então não há upload para interceptar, armazenar ou vazar.
  • As senhas em teste não são registradas nem transmitidas; cada candidata é testada em um worker e depois descartada.
  • Não há registros do lado do servidor com os nomes ou o conteúdo dos seus arquivos, porque não há servidor lidando com eles.

Este é o cerne da nossa abordagem de segurança: a forma mais privada de lidar com um arquivo sensível é não movê-lo de forma alguma.

O que a ferramenta mantém, e por quanto tempo

Como a recuperação é executada dentro da página, sua pegada é pequena. Os bytes do arquivo ficam na aba enquanto ela está aberta, cada candidata é testada em um worker e depois descartada, e o progresso e as estimativas de tempo vêm da sua própria taxa de teste. Duas coisas podem sobreviver à aba, ambas só no seu dispositivo. Um ZIP que você solta ou escolhe na página inicial fica no armazenamento do navegador até a página de recuperação abri-lo e apagá-lo, então ele só sobrevive à aba se a página de recuperação não chegar a abrir. E uma busca por máscara ou força bruta em andamento salva as configurações (incluindo o nome e o tamanho do arquivo e a máscara que você digitou) e o progresso, para você retomar depois de recarregar a página ou de fechar a aba; esse registro é apagado quando a busca termina, quando você clica em Parar ou quando escolhe Começar do zero. Nenhuma das duas é enviada a lugar nenhum; a política de privacidade diz o que cada uma contém e como apagá-las. Não há conta nem histórico de recuperações no servidor.

Os limites, sem rodeios

Rodar primeiro no seu dispositivo ganha em privacidade, mas não é uma varinha mágica:

  • A velocidade depende do seu próprio hardware. Um notebook testa menos candidatas AES por segundo do que uma máquina grande testaria, então uma senha forte permanece fora de alcance, que é justamente o propósito da criptografia.
  • A recuperação ainda depende de restringir a busca. O processamento local muda onde o trabalho acontece, não a matemática da adivinhação.

Nada disso muda a recomendação, porque uma senha forte ser difícil de adivinhar é precisamente o que protege seus dados. Quando você quiser tentar, tudo é executado na página de recuperação.

Verifique você mesmo a alegação de privacidade

Você não precisa acreditar na palavra de ninguém:

  • Abra as ferramentas de desenvolvedor do navegador, vá até a aba Rede, depois selecione um arquivo e inicie uma recuperação curta. Você verá a página baixar os próprios scripts, incluindo o worker e o teste de compatibilidade do WebAssembly, e nada que leve o seu arquivo. A única requisição que envia dados é um POST para /api/error, e só se o próprio código do site encontrar um erro; ela leva a mensagem de erro e o stack trace, o caminho da página e o user-agent do navegador (a seção 4 da política de privacidade lista todos os campos), nunca dados do arquivo ou senhas.
  • Para uma segunda checagem, deixe a aba Rede aberta enquanto essa busca roda: você não verá nenhuma requisição para outro site nem envio do seu arquivo. As requisições que aparecem vão para este site, como o script que cada worker carrega, e nenhuma leva o seu arquivo ou uma senha.

Como sempre, execute a recuperação apenas em arquivos que você possui ou está autorizado a abrir.

Em resumo

  • A recuperação baseada no navegador lê seu arquivo localmente com a File API e nunca o envia.
  • O WebAssembly torna a lenta derivação de chave do AES rápida o suficiente para rodar no seu próprio dispositivo.
  • Web Workers mantêm a interface responsiva, e nenhuma candidata passa pela rede.
  • Você pode conferir por conta própria que o seu arquivo nunca sai da sua máquina.