Vaulted
Auditoria de 5 minutos

Verifique você mesmo a criptografia zero-knowledge do Vaulted

Não confie nas ferramentas de segurança — verifique-as. Quatro testes no navegador, sem instalações, cinco minutos.

O checklist de 60 segundos

Dê uma lida rápida primeiro. O passo a passo detalhado abaixo cobre cada etapa em profundidade.

  1. 1

    Abra as DevTools → aba Network

    No Vaulted, pressione Cmd+Option+I (macOS) ou F12 (Windows/Linux). Mude para a aba Network e filtre por Fetch/XHR.

  2. 2

    Crie um segredo e inspecione o POST

    Digite uma string canário reconhecível (ex.: CANARY-12345) e clique em Create. Localize a requisição POST /api/secrets. Abra a aba Payload — você verá apenas ciphertext (base64) e iv. Procure pelo seu canário no corpo; ele não está ali.

  3. 3

    Inspecione o link de compartilhamento

    Observe o link gerado. A chave de descriptografia fica depois do # (o fragmento da URL). Segundo a RFC 3986, os navegadores nunca enviam os fragmentos ao servidor — nem nas linhas de requisição, nem nos cabeçalhos, nem nos referrers.

  4. 4

    Confirme que a descriptografia roda no lado do cliente

    Abra o link em uma nova aba. A resposta GET de /api/secrets/[id] devolve apenas ciphertext. No painel Sources, procure por crypto.subtle.decrypt — essa chamada roda no seu navegador, não no nosso servidor.

Abra o Vaulted e comece →Leia o modelo de ameaças

O que você está verificando

A promessa do Vaulted é específica: o servidor nunca vê o seu texto simples nem a sua chave de criptografia. Isso se desdobra em quatro propriedades observáveis:

  1. O texto simples nunca aparece em nenhuma requisição de rede.
  2. A chave de criptografia nunca aparece em nenhuma requisição de rede.
  3. O fragmento da URL (onde a chave fica) nunca chega ao servidor.
  4. Os dados do lado do servidor, sozinhos, não conseguem reconstruir o segredo.

Se as quatro se mantêm, a arquitetura é zero-knowledge por construção — sem precisar de linguagem de marketing.

Teste 1 — O texto simples nunca trafega pela rede

  1. Abra vaulted.fyi.
  2. Abra as DevTools e mude para a aba Network. Filtre por Fetch/XHR.
  3. Digite uma string reconhecível no campo do segredo — algo como CANARY-12345.
  4. Clique em Create.

Você verá um único POST para /api/secrets. Clique nele e veja a aba Payload.

O corpo contém um campo ciphertext e um campo iv. Ambos são blobs codificados em base64url. Procure no payload por CANARY-12345 — não está ali. O texto simples foi criptografado no navegador antes de a requisição ser disparada.

Se quiser ser minucioso, mude a limitação de rede para “Slow 3G” e repita. O texto cifrado continua parecendo ruído; o texto simples continua sem aparecer em lugar algum.

Teste 2 — A chave também não trafega pela rede

Depois de criar o segredo, o Vaulted mostra a você um link de compartilhamento. Ele tem este aspecto:

https://vaulted.fyi/s/abc123#dGhpcyBpcyBhIGtleQ
                              ^^^^^^^^^^^^^^^^^^^^
                              encryption key (base64url)

A parte que vem depois de # é o fragmento da URL. Segundo a RFC 3986, os navegadores processam os fragmentos localmente — eles nunca aparecem nas linhas de requisição HTTP, nos cabeçalhos ou nos referrers.

Para provar isso:

  1. Copie o link de compartilhamento.
  2. Abra-o em uma nova aba com a aba Network das DevTools aberta.
  3. Localize a requisição GET /s/abc123.
  4. Veja a aba Headers — a URL completa da requisição, sem fragmento.
  5. Veja a aba Request — sem fragmento.
  6. Verifique document.referrer na página seguinte — o fragmento foi removido.

A chave que o destinatário precisa para descriptografar o segredo estava na URL, mas ficou no navegador dele. O servidor viu GET /s/abc123 e nada mais.

Teste 3 — O servidor sozinho não consegue descriptografar

Abra um terminal e faça um curl direto no segredo:

curl https://vaulted.fyi/api/secrets/abc123

Você receberá de volta um JSON contendo ciphertext e iv. Esse é todo o estado do lado do servidor do seu segredo.

Agora tente entender isso. Sem a chave do fragmento da URL, você não consegue. AES-256-GCM com uma chave aleatória gerada corretamente é, para todos os efeitos práticos, indistinguível de ruído aleatório. Um dump completo do banco de dados dos servidores do Vaulted produziria exatamente isto — blobs criptografados e metadados.

Essa é a definição literal de zero-knowledge: o servidor armazena dados que não consegue ler.

Teste 4 — A criptografia acontece em JavaScript que você pode ver

O Vaulted usa a Web Crypto API, que é uma primitiva do navegador — não há WASM ofuscado nem módulo nativo escondendo o trabalho. Você pode ver a criptografia acontecer.

  1. Nas DevTools, abra a aba Sources.
  2. Procure por crypto.subtle.encrypt (use Cmd+Option+F para a busca global).
  3. Coloque um ponto de interrupção na linha que chama crypto.subtle.encrypt.
  4. Provoque a criação de um novo segredo.
  5. O ponto de interrupção é atingido. Inspecione os argumentos: você verá o seu texto simples como um Uint8Array, a chave AES-GCM e um IV aleatório novo.
  6. Avance sobre a chamada. O resultado é o texto cifrado que é enviado.

Agora você está vendo o texto simples se transformar em texto cifrado, no seu navegador, antes de qualquer requisição de rede. Não há outro caminho que os dados poderiam tomar.

O que isso prova

  • Nenhum texto simples sai do navegador. Teste 1.
  • Nenhuma chave sai do navegador. Teste 2.
  • O servidor não consegue descriptografar com o que armazena. Teste 3.
  • A criptografia é real e acontece no lado do cliente. Teste 4.

Essa é toda a promessa zero-knowledge, demonstrada contra um sistema de produção em funcionamento em cinco minutos.

O que isso não prova

A verificação é um trabalho honesto — vale a pena ser claro sobre os seus limites.

  • Os testes provam o comportamento neste momento. Uma futura mudança de código poderia quebrar a propriedade. Se você precisa de garantia contínua, inscreva-se no changelog e execute os testes novamente de tempos em tempos.
  • Eles não protegem contra o seu próprio dispositivo. Um keylogger ou uma extensão de navegador maliciosa podem ler o texto simples após a descriptografia. Isso está fora do controle de qualquer aplicação web.
  • Eles assumem que o JavaScript que você executou é o JavaScript que o Vaulted serve. Um atacante direcionado que comprometesse a CDN poderia servir um bundle diferente para um único usuário. Subresource Integrity e builds reproduzíveis mitigam isso; consulte nosso modelo de ameaças para todos os detalhes.

Indo além

Se você quiser se aprofundar:

O argumento mais forte a favor de uma ferramenta de segurança não é o marketing dela. É que você consegue desmontá-la e confirmar que ela faz o que diz. O Vaulted foi construído para que você consiga.

Perguntas frequentes

Tem perguntas ou encontrou algo estranho? Escreva para [email protected] — publicamos nossa política de divulgação responsável e respondemos em até 48 horas.
Compartilhar um segredo →