Se você precisa enviar uma senha, chave de API ou credencial de banco de dados para alguém fora do seu sistema, o padrão mais seguro é criptografá-la no navegador do remetente, enviar apenas texto cifrado para um servidor e entregar a chave de descriptografia ao destinatário de uma forma que o servidor nunca veja. Esta é a essência do compartilhamento de conhecimento zero. Abaixo está um exemplo prático de criptografia que mostra como enviar credenciais com conhecimento zero, além de um fluxo de trabalho simples que você pode adotar hoje.
Como o "conhecimento zero" se parece na prática
Conhecimento zero neste contexto significa que o serviço que retransmite sua mensagem não pode lê-la. A chave de criptografia nunca sai dos navegadores, o servidor vê apenas texto cifrado e o segredo é destruído após o uso.
Dois detalhes fazem isso funcionar:
- Criptografia do lado do cliente, para que o texto plano exista apenas nos navegadores do remetente e do destinatário.
- Chave no fragmento de URL, para que a chave nunca seja transmitida ao servidor. O fragmento, tudo após o #, não é enviado em solicitações HTTP, ver RFC 3986, Seção 3.5.
Para criptografia autenticada, implementações modernas normalmente usam AES-GCM com uma chave de 256 bits, que é padronizada pelo NIST, ver NIST SP 800-38D. Se você quer uma introdução rápida ao algoritmo e por que as organizações confiam nele, leia nosso guia em linguagem simples, AES 256 explicado para não engenheiros.
Um exemplo mínimo de criptografia no navegador (apenas para educação)
O seguinte JavaScript mostra o núcleo de um fluxo de conhecimento zero usando a API Web Crypto. Gera uma chave aleatória de 256 bits, criptografa uma credencial com AES‑GCM, envia apenas texto cifrado e IV para um servidor, depois constrói um link que carrega a chave de descriptografia no fragmento.
Importante, este código é para aprendizado, não para produção. Como o OWASP aconselha, não crie sua própria criptografia ou protocolo em produção, use bibliotecas e serviços verificados, ver a Folha de referência de armazenamento criptográfico do OWASP e a documentação da API Web Crypto.
// Exemplo mínimo de conhecimento zero com AES-GCM (apenas para educação)
// 1) Criptografar no navegador 2) Enviar apenas texto cifrado 3) Colocar chave no fragmento de URL
const te = new TextEncoder();
const td = new TextDecoder();
function toB64url(buf) {
const bytes = buf instanceof ArrayBuffer ? new Uint8Array(buf) : new Uint8Array(buf.buffer || buf);
let bin = "";
for (let i = 0; i < bytes.length; i++) bin += String.fromCharCode(bytes[i]);
return btoa(bin).replace(/\+/g, "-").replace(/\//g, "_").replace(/=+$/g, "");
}
function fromB64url(s) {
const base64 = s.replace(/-/g, "+").replace(/_/g, "/") + "===".slice((s.length + 3) % 4);
const bin = atob(base64);
const out = new Uint8Array(bin.length);
for (let i = 0; i < bin.length; i++) out[i] = bin.charCodeAt(i);
return out;
}
async function createZeroKnowledgeLink(secret) {
// Chave AES-GCM de 256 bits
const key = await crypto.subtle.generateKey({ name: "AES-GCM", length: 256 }, true, ["encrypt", "decrypt"]);
// Nunca reutilize um IV com a mesma chave
const iv = crypto.getRandomValues(new Uint8Array(12));
const plaintext = te.encode(secret);
const ciphertext = await crypto.subtle.encrypt({ name: "AES-GCM", iv }, key, plaintext);
const keyRaw = await crypto.subtle.exportKey("raw", key);
// Enviar apenas texto cifrado + IV para sua API de retransmissão
const payload = {
ciphertext: toB64url(ciphertext),
iv: toB64url(iv),
expireViews: 1, // acesso único
ttlSeconds: 600 // expiração de 10 minutos
};
// Substitua pelo seu endpoint backend que armazena texto cifrado de forma efêmera
const res = await fetch("/api/secret", {
method: "POST",
headers: { "Content-Type": "application/json" },
body: JSON.stringify(payload)
});
const { id } = await res.json();
// Coloque a chave de descriptografia no fragmento de URL para que o servidor nunca a receba
const keyB64 = toB64url(keyRaw);
const link = `https://your-app.example/secret/${id}#k=${keyB64}`;
return link;
}
// A lógica do navegador do destinatário faria o inverso: buscar texto cifrado, importar chave do fragmento, descriptografar localmente.
async function openZeroKnowledgeLink(id, keyB64) {
const r = await fetch(`/api/secret/${id}`); // o servidor deve retornar 404 e excluir após a primeira leitura
const { ciphertext, iv } = await r.json();
const keyRaw = fromB64url(keyB64);
const cryptoKey = await crypto.subtle.importKey("raw", keyRaw, { name: "AES-GCM" }, false, ["decrypt"]);
const pt = await crypto.subtle.decrypt(
{ name: "AES-GCM", iv: fromB64url(iv) },
cryptoKey,
fromB64url(ciphertext)
);
return td.decode(pt);
}Notas para precisão e segurança:
- AES-GCM requer um IV único para cada criptografia com uma determinada chave. Use um IV aleatório de 96 bits por mensagem e nunca o reutilize.
- O servidor deve impor acesso único e exclusão na primeira recuperação. Mantenha apenas texto cifrado e metadados mínimos, nunca armazene chaves ou texto plano.
- Se você precisa de frases-senha inseridas por humanos, use um KDF como PBKDF2 ou Argon2 para derivar uma chave forte antes do AES-GCM. Para a maioria das transferências de credenciais ad-hoc, uma chave aleatória no fragmento de URL é mais simples e mais forte.
Se você prefere não construir ou manter isso sozinho, o Nurbak já implementa um modelo de conhecimento zero com AES‑256, links de uso único, sem registro de dados, registros de acesso de auditoria e um painel de administração limpo. Veja nossa análise, Criptografia do Lado do Cliente vs. do Servidor: Por Que Importa para Seus Segredos.
Passo a passo: enviar credenciais com conhecimento zero
Aqui está um processo conciso e repetível que as equipes usam para chaves de API, senhas de banco de dados, credenciais de emergência SSO e códigos de recuperação.
- Prepare a credencial. Limite-a ao menor privilégio, adicione uma expiração e, se possível, crie um valor temporário que você rotacionará após a transferência.
- Crie um link autodestrutivo de uso único. Use uma ferramenta de conhecimento zero que criptografa no navegador e exclui o texto cifrado após o primeiro acesso ou TTL curto.
- Entregue o contexto e o link em canais separados. Envie o link através do seu canal normal e envie qualquer contexto ou instruções em um segundo canal. Isso reduz os riscos de pré-visualização acidental e ajuda na verificação resistente a phishing.
- Confirme o recebimento. Peça ao destinatário para confirmar que armazenou o segredo em seu gerenciador de senhas, depois revogue ou rotacione imediatamente quaisquer credenciais temporárias.
- Registre o evento. Mantenha evidência de auditoria de que uma transferência ocorreu sem armazenar texto plano. Ferramentas como o Nurbak fornecem registros de acesso de auditoria que registram o acesso sem comprometer o conteúdo.
O que cada parte pode ver em cada passo
| Passo | Navegador do remetente | Servidor de retransmissão | Navegador do destinatário |
|---|---|---|---|
| Criar link | Texto plano antes da criptografia, depois chave e texto cifrado | Apenas texto cifrado e metadados | Ainda nada |
| Entregar link | URL com chave no fragmento | Sem chave, sem texto plano | URL com chave no fragmento |
| Abrir link | Nada novo | Leitura única, exclui texto cifrado | Descriptografa texto cifrado localmente, vê texto plano |
Esta minimização de dados é o coração do compartilhamento de conhecimento zero. Não há nada útil para extrair do serviço de retransmissão porque ele nunca possui a chave.
Ameaças para planejar, com mitigações
Mesmo um design criptográfico forte pode falhar se você ignorar riscos operacionais. Aborde essas questões comuns.
- Pré-visualizações de links e scanners. Alguns sistemas de chat e e-mail buscam links automaticamente, o que pode consumir links de uso único. Mitigue com um TTL curto, acesso único, instrução ao usuário para copiar e colar o link no navegador, e considere enviar o link como texto simples sem desdobramento automático quando possível.
- Phishing e confusão de domínio. Treine destinatários para verificar o domínio antes de abrir qualquer link secreto. Considere uma frase pré-compartilhada ou chamada para verificação quando as apostas são altas.
- Comprometimento do dispositivo. Links de conhecimento zero protegem dados em trânsito e em repouso no retransmissor, mas não protegem um endpoint comprometido. Incentive destinatários a abrir links apenas em dispositivos gerenciados ou confiáveis.
- Reutilização de credenciais. Sempre rotacione ou revogue credenciais temporárias após o uso. Trate a transferência como bem-sucedida apenas depois de remover a porta dos fundos de persistência.
Para orientação mais ampla sobre o manuseio de segredos, considere a Folha de referência de gerenciamento de segredos do OWASP.
Por que links de conhecimento zero superam e-mail e tickets para credenciais únicas
| Método | O que o provedor pode ler | Risco de persistência | Adequação |
|---|---|---|---|
| E-mail ou ticket | Texto plano disponível em múltiplos sistemas e backups | Alto, cópias existem por anos | Não adequado para credenciais |
| Compartilhamento de item de gerenciador de senhas | Varia por fornecedor, alguns são criptografados de ponta a ponta | Médio, requer conta e coordenação | Bom para compartilhamento de longo prazo dentro de uma organização |
| Link de conhecimento zero de uso único | Apenas texto cifrado, sem chave, sem texto plano | Baixo, uso único com TTL curto | Ideal para transferências ad-hoc entre organizações |
Se você precisa enviar um segredo rapidamente para um fornecedor, freelancer ou cliente, links de conhecimento zero de uso único oferecem a melhor combinação de velocidade, segurança e auditabilidade.
Considerações de conformidade em 2026
- SOC 2 e ISO 27001. Esses frameworks esperam menor privilégio, retenção mínima e auditabilidade. Links de conhecimento zero ajudam você a atender essas expectativas ao eliminar texto plano persistente e fornecer eventos de acesso rastreáveis.
- GDPR e Direito ao Esquecimento. E-mail e chat propagam cópias entre sistemas e backups, o que complica solicitações de exclusão. Links efêmeros e autodestrutivos ajudam você a minimizar dados pessoais retidos. Para uma análise mais profunda, leia nosso guia, Conformidade com GDPR e o Direito ao Esquecimento: Por Que Você Precisa de Links Autodestrutivos.
Quando construir vs. comprar
O exemplo acima ilustra como a criptografia funciona. Transformá-lo em um serviço de nível de produção requer mais trabalho, incluindo segurança de links contra scanners, garantias de exclusão única, expirações confiáveis, limitação de taxa, telemetria e relatórios de conformidade. A maioria das equipes prefere não possuir essa superfície.
O Nurbak implementa o padrão de conhecimento zero imediatamente, com criptografia AES‑256 do lado do cliente, links autodestrutivos, sem registro ou armazenamento de dados, registros de acesso de auditoria e um painel de administração para políticas e análises. Se você só quer uma forma segura e profissional de entregar segredos, é mais rápido e seguro usar uma ferramenta projetada para esse propósito do que montar a sua própria.
Perguntas frequentes
O que é um link de conhecimento zero? Um link de uso único onde a criptografia acontece no navegador e a chave de descriptografia está incorporada no fragmento de URL. O servidor apenas armazena texto cifrado e não pode descriptografá-lo.
Por que colocar a chave no fragmento de URL? O fragmento não é enviado ao servidor durante solicitações HTTP, então o servidor não pode aprender a chave. O navegador do destinatário a usa localmente para descriptografar.
O AES‑256 GCM é seguro para este caso de uso? Sim, quando implementado corretamente com um IV aleatório único por mensagem e criptografia autenticada. Ver NIST SP 800-38D. Evite esquemas personalizados e use bibliotecas verificadas.
Isso substitui gerenciadores de senhas? Não. Use um gerenciador de senhas para armazenar credenciais de longo prazo. Links de conhecimento zero são ideais para transferências ad-hoc entre organizações que não devem persistir em e-mail ou chat.
Como evito que pré-visualizações de links consumam um link de uso único? Use ferramentas que suportem expirações curtas e acesso único, instrua destinatários a copiar o link no navegador e evite canais que busquem links automaticamente. Separe o link do contexto circundante quando possível.
Posso auditar transferências sem armazenar texto plano? Sim. Você pode registrar metadados sobre criação de links e eventos de acesso. O Nurbak fornece registros de acesso de auditoria mantendo o conteúdo da mensagem com conhecimento zero.
Pronto para enviar credenciais com conhecimento zero, sem construir sua própria criptografia ou protocolos? Crie um link criptografado do lado do cliente e autodestrutivo em minutos com o Nurbak. Aprenda como a arquitetura funciona em Criptografia do Lado do Cliente vs. do Servidor ou obtenha um passo a passo direto em Como compartilhar um segredo com links de uso único. Quando estiver pronto, visite Nurbak para gerar seu primeiro link de conhecimento zero.