# Hashes Com e Sem Salt em Uploads de Público

> Guias de segurança mandam sempre usar salt. Plataformas de anúncios não conseguem corresponder dados com salt. Os dois estão certos – eis a diferença.

- Source: https://www.8apps.co/pt/blog/hashes-com-e-sem-salt-uploads-de-publico
- Markdown: https://www.8apps.co/pt/blog/hashes-com-e-sem-salt-uploads-de-publico.md
- Published: 2026-09-02
- Author: Equipe 8apps
- Language: pt

---
## 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](/pt/google-workspace/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](https://www.edpb.europa.eu/system/files/2025-01/edpb_guidelines_202501_pseudonymisation_en.pdf) – lido em 20/08/2026