Duas regras que parecem se contradizer
Toda cartilha de segurança diz: nunca armazene um hash sem salt. Todo fluxo de upload de plataforma de anúncios dá a entender: nos entregue o SHA-256 puro do valor normalizado. Quem encontra uploads de público pela primeira vez pergunta, com razão, qual das regras está errada. Nenhuma está – elas resolvem problemas opostos.
Para que serve um salt
Um salt é um dado extra misturado à entrada antes do hash, de modo que entradas idênticas produzam digests diferentes. Essa propriedade é todo o ponto no armazenamento de credenciais: dois usuários com a mesma senha recebem hashes diferentes, e tabelas de consulta pré-computadas morrem. O salting é o padrão porque, naquele contexto, o objetivo é a não vinculabilidade.
Por que a correspondência precisa do oposto
A correspondência de públicos funciona precisamente porque entradas idênticas produzem digests idênticos. Você aplica hash em john@example.com do seu jeito; a plataforma aplica hash no próprio registro de john@example.com do mesmo jeito; os digests coincidem – e essa coincidência é a correspondência. Introduza um salt que só você conhece e seus digests não correspondem a nada na Terra: uma lista perfeitamente segura de zero usuários correspondidos. Hashing determinístico e sem salt não é uma plataforma sendo relaxada com segurança; é o mecanismo fazendo o seu trabalho.
A consequência que você precisa assumir
Um digest sem salt sobre um espaço de chaves pequeno é fraco por construção. Números de telefone em especial: enumere o plano nacional de numeração, aplique hash em tudo, e a coluna "anonimizada" se lê como texto puro para quem tiver a tabela. Isso não tem conserto – a fraqueza e a correspondência são a mesma propriedade. Daí decorre a regra de manuseio: um arquivo de upload é formatação para transporte, não proteção. Controle o acesso, compartilhe deliberadamente, apague quando a campanha terminar. (O argumento completo está no nosso guia "Hashing não é anonimização".)
Onde cada regra se aplica, em uma tabela
| Contexto | Salt? | Por quê |
|---|---|---|
| Senhas, credenciais | Sempre | Não vinculabilidade; eliminar tabelas de consulta |
| Uploads de público em plataformas de anúncios | Não | A correspondência exige digests determinísticos |
| Análises internas pseudonimizadas | Com chave/salt | Você controla os dois lados, então use uma chave secreta |
A terceira linha merece o parêntese: quando você é tanto quem aplica o hash quanto quem faz a correspondência – ao juntar conjuntos de dados dentro dos seus próprios sistemas –, não há plataforma com que corresponder, e um hash com chave lhe dá proteção real. Reserve o SHA-256 puro para os uploads que o exigem.
Onde o Hash Data se encaixa
O Hash Data produz os digests padrão que os uploads de público esperam, dentro do Google Planilhas – vários algoritmos como fórmulas e o =HASHPHONE(), que normaliza para E.164 e aplica o hash em uma única etapa. O que ele não pode mudar é a física acima – e é por isso que esta página existe ao lado do produto, em vez de fingir o contrário.
Fontes
- Diretrizes 01/2025 do EDPB sobre Pseudonimização – lido em 20/08/2026