Funções de hash explicadas: SHA-256, checksums e hash de senhas
Uma função de hash transforma qualquer entrada — uma palavra, uma senha, um arquivo de 4 GB — em uma impressão digital curta e de comprimento fixo. A mesma entrada sempre gera a mesma impressão digital, e a menor alteração gera uma completamente diferente. Por isso os hashes são a forma padrão de verificar se um arquivo chegou intacto, de guardar senhas sem guardar as próprias senhas e de assinar mensagens. Este guia explica o que torna um hash seguro, quais algoritmos ainda são confiáveis, como conferir um arquivo baixado e por que o hash rápido, certo para um arquivo, é o errado para uma senha.
O que uma função de hash faz
Uma função de hash lê dados de qualquer tamanho e devolve um resumo (digest) de comprimento fixo. O SHA-256, o mais comum hoje, sempre devolve 256 bits, escritos como 64 caracteres hexadecimais, seja a entrada uma única letra ou a imagem de um disco inteiro.
c3c211099e2db0d1bb97343886c2b7e23981b636107a296a9fe642b99ca4cc1bSHA-256 de nTools.420849368aee5e9b6838f98b4dde3f493de84c420baa785ea58a08acc2c0cfafSHA-256 de ntools: só uma letra passou para minúscula, e o resumo não tem nenhuma relação com o anterior.
Toda função de hash é determinística — a mesma entrada gera o mesmo resumo em qualquer computador — e rápida de calcular. Um hash criptográfico acrescenta as garantias da próxima seção, e são elas que o tornam útil para a segurança.
Um resumo não é uma cópia compactada: 64 caracteres não comportam um arquivo de 4 GB. Em teoria, muitas entradas compartilham cada resumo; um hash seguro apenas torna inviável encontrá-las na prática.
O que torna um hash seguro
O padrão americano que define o SHA-256, o FIPS 180-4, descreve os algoritmos como seguros porque certas buscas são computacionalmente inviáveis. Na prática, são três propriedades:
- Resistência à pré-imagem: dado um resumo, ninguém consegue encontrar uma entrada que o produza. É isso que significa “de mão única”.
- Resistência à segunda pré-imagem: dado um arquivo, ninguém consegue criar um arquivo diferente com o mesmo resumo.
- Resistência a colisões: ninguém consegue encontrar duas entradas diferentes quaisquer com o mesmo resumo, mesmo escolhendo as duas livremente.
A resistência a colisões é a primeira a cair, porque o atacante controla as duas entradas. Foi o que aconteceu com o MD5 e o SHA-1. Isso importa porque assinaturas digitais e certificados são calculados sobre um hash do documento: dois documentos com o mesmo hash compartilham a mesma assinatura.
MD5, SHA-1, SHA-2 e SHA-3
| Algoritmo | Resumo | Situação |
|---|---|---|
MD5 | 128 bits, 32 caracteres hexadecimais | Quebrado: colisões são viáveis na prática. A RFC 6151 (2011) o descarta onde quer que a resistência a colisões seja necessária, como em assinaturas digitais. |
SHA-1 | 160 bits, 40 caracteres hexadecimais | Quebrado: primeira colisão pública em 2017. O NIST diz que ele deve ser eliminado gradualmente até 31 de dezembro de 2030. |
SHA-256 | 256 bits, 64 caracteres hexadecimais | Seguro. Faz parte da família SHA-2 (FIPS 180-4) e é o padrão habitual hoje. |
SHA-384, SHA-512 | 384 e 512 bits, 96 e 128 caracteres hexadecimais | Seguros. Também são SHA-2, com um resumo mais longo. |
SHA-3 | De 224 a 512 bits, conforme a variante | Seguro. Padronizado em 2015 (FIPS 202) com base em um projeto diferente, o Keccak, para complementar o SHA-2, não para substituí-lo. |
A colisão do SHA-1, batizada de SHAttered, foi anunciada pelo Google e pelo CWI Amsterdam em 23 de fevereiro de 2017: dois arquivos PDF diferentes com o mesmo resumo SHA-1, encontrados com cerca de 9,2 quintilhões de cálculos de SHA-1. Desde então, o MD5 e o SHA-1, como hashes simples, sobrevivem apenas como verificações rápidas contra danos acidentais. A documentação da Microsoft para o comando de hash de arquivos do Windows diz o mesmo: use-os só para validações simples de alteração, nunca para arquivos que precisam ser protegidos contra adulteração.
O Gerador de hash do nTools oferece SHA-256, SHA-384 e SHA-512. Ele usa a Web Crypto API embutida no navegador, que também aceita SHA-1 — com o aviso de não usá-lo em criptografia — e não oferece MD5 de forma alguma.
Como conferir um arquivo baixado
Quem distribui software costuma divulgar um checksum (soma de verificação) ao lado do arquivo, geralmente SHA-256. Depois de baixar, você calcula o resumo da sua cópia e compara.
- Veja qual algoritmo foi usado por quem publicou o arquivo e copie o checksum divulgado.
- Calcule o resumo do arquivo baixado com o mesmo algoritmo: no Gerador de hash do nTools, para arquivos de até 200 MB, ou com um comando como os abaixo, para qualquer tamanho.
- Compare todos os caracteres, não só os primeiros e os últimos. Em hexadecimal, maiúsculas e minúsculas não fazem diferença.
Get-FileHash .\file.isoWindows PowerShell. SHA-256, a menos que você acrescente -Algorithm.sha256sum file.isoLinux.shasum -a 256 file.isomacOS.
Se os resumos coincidem, isso prova que o arquivo é exatamente aquele cujo hash foi calculado; não prova quem o calculou. Um atacante capaz de substituir o arquivo em um site geralmente também consegue substituir o checksum na mesma página. Por isso projetos como o Ubuntu também assinam a sua lista de checksums: primeiro você verifica a assinatura com o GPG, depois confere o arquivo com a lista. Uma vez conferida a impressão digital da chave de assinatura no site do próprio projeto, o resultado vale mesmo que você tenha baixado de um espelho não confiável.
Hash, criptografia e codificação
| Método | Reversível? | Chave? | Usado para |
|---|---|---|---|
| Hash (ex.: SHA-256) | Não | Não | Verificar integridade, identificar dados, guardar senhas com um algoritmo lento |
| Criptografia (ex.: AES) | Sim, com a chave | Sim | Manter dados em sigilo |
| Codificação (ex.: Base64) | Sim, por qualquer pessoa | Não | Transportar dados binários como texto, em e-mails, URLs e JSON |
Base64 e a codificação de URL não protegem nada: mudam a forma como os dados são escritos, não quem pode lê-los. Senhas criptografadas também são piores do que senhas guardadas como hash, alerta a OWASP: a criptografia funciona nos dois sentidos, então quem consegue descriptografar recupera as senhas originais. Ela só serve para o caso raro em que o original precisa ser recuperado.
Por que um hash rápido é a escolha errada para senhas
Um site nunca deve guardar a sua senha, apenas um hash dela: no login, ele calcula o hash do que você digita e compara o resultado. O problema é a velocidade. Um hash que confere um download de 4 GB em segundos permite que qualquer pessoa que roube o banco de dados teste bilhões de tentativas por segundo.
| Algoritmo | Tentativas por segundo, uma RTX 4090 | Tempo para testar todas as senhas de 8 caracteres com letras minúsculas e dígitos |
|---|---|---|
| MD5 | 164 bilhões | 17 segundos |
| SHA-1 | 51 bilhões | 56 segundos |
| SHA-256 | 22 bilhões | 2 minutos |
| SHA-512 | 7,5 bilhões | 6 minutos |
| PBKDF2-HMAC-SHA256, 600.000 iterações | cerca de 15.000 | cerca de 6 anos |
| bcrypt, custo 10 | cerca de 5.750 | cerca de 15 anos |
Velocidades do benchmark do hashcat 6.2.6 em uma placa de vídeo NVIDIA RTX 4090. As duas últimas linhas foram extrapoladas a partir das configurações do próprio benchmark (999 iterações de PBKDF2, bcrypt com custo 5), porque o tempo cresce na mesma proporção do trabalho. A busca cobre todas as 36⁸ candidatas, cerca de 2,8 trilhões. Ataques reais são ainda mais rápidos: usam muitas placas ao mesmo tempo e testam primeiro as senhas mais prováveis.
Salt: a mesma senha, um hash diferente
Sem salt, todo mundo cuja senha é 123456 tem o mesmo hash armazenado, e os atacantes mantêm tabelas com os hashes de milhões de senhas comuns; assim, encontrá-las é uma simples consulta, não uma busca.
8d969eef6ecad3c29a3a629280e686cf0c3f5d5a86aff3ca12020c923adc6c92SHA-256 de 123456, sem salt: o mesmo em todo banco de dados que o armazena dessa forma.
Um salt é um valor aleatório criado para cada senha, armazenado ao lado do hash dela e misturado a ele. Não é secreto. A função dele é tornar cada hash armazenado único, de modo que tabelas pré-calculadas fiquem inúteis e cada conta precise ser atacada separadamente.
A NIST SP 800-63B-4 exige que as senhas recebam salt e hash com um esquema adequado de hash de senhas e um salt de pelo menos 32 bits, e recomenda um fator de custo tão alto quanto for viável. Também recomenda uma etapa extra com chave, usando uma chave secreta guardada separadamente dos hashes, de preferência em um módulo de segurança de hardware. A OWASP chama esse segredo de pepper.
O que usar no lugar
Funções de hash de senha são lentas de propósito, recebem o salt como entrada e têm um parâmetro de custo que deve subir à medida que o hardware fica mais rápido. O OWASP Password Storage Cheat Sheet indica estes mínimos:
| Algoritmo | Configuração mínima | Quando usar |
|---|---|---|
Argon2id | 19 MiB de memória, 2 iterações, paralelismo 1 | Primeira escolha. Cada tentativa exige memória, o que reduz a vantagem das placas de vídeo. Especificado na RFC 9106 (2021). |
scrypt | N = 2¹⁷, r = 8, p = 1 | Quando o Argon2id não estiver disponível. Também exige memória. |
bcrypt | Custo 10 ou mais | Sistemas mais antigos. A maioria das implementações aceita no máximo 72 bytes de senha; senhas mais longas são cortadas ou rejeitadas. |
PBKDF2-HMAC-SHA256 | 600.000 iterações | Quando a conformidade com o FIPS-140 é obrigatória. |
Esses valores são mínimos, pensados para manter um login em uma fração de segundo no servidor e, ao mesmo tempo, tornar cada tentativa cara. Você não tem como ver qual deles um site usa, e é por isso que os conselhos do guia de senhas — longa, aleatória e nunca reutilizada — partem do pior caso.
HMAC: um hash com chave
Um hash simples mostra que os dados não mudaram, mas qualquer pessoa pode calculá-lo: quem altera os dados pode simplesmente recalcular o hash. O HMAC, definido na RFC 2104 em 1997, mistura uma chave secreta ao hash, de modo que só quem tem a chave consegue gerar ou verificar o resultado.
É assim que APIs assinam requisições, que webhooks provam que vieram do remetente e que muitos JSON Web Tokens são assinados: o algoritmo de JWT HS256 é HMAC com SHA-256.
Perguntas frequentes
Dá para reverter um hash?
Não. O resumo não contém a entrada, então não há nada para decodificar. O que os atacantes fazem é adivinhar: calculam o hash de candidatas até que uma coincida. Isso funciona com entradas curtas ou comuns, como senhas, e falha com entradas longas e aleatórias.
O MD5 ainda serve para alguma coisa?
Para detectar alterações acidentais, como uma cópia corrompida ou um arquivo duplicado, sim. Não onde alguém possa adulterar os dados de propósito, e nunca para senhas ou assinaturas.
Dois arquivos podem ter o mesmo resumo SHA-256?
Em teoria, sim: existem mais arquivos possíveis do que resumos. Na prática, nunca foi encontrada uma colisão no SHA-256 completo, e uma busca por força bruta levaria cerca de 2¹²⁸ tentativas.
Um resumo mais longo é sempre mais seguro?
Só até certo ponto. Com 256 bits, uma busca por colisões já fica muito fora de alcance; a solidez do algoritmo importa mais, como o SHA-1 mostrou. SHA-384 e SHA-512 são usados quando alguma norma os exige ou para ter uma margem extra.
Meu arquivo é enviado quando calculo o hash dele no nTools?
Não. O arquivo é lido e tem o hash calculado no seu navegador, e só o resumo aparece na tela.
Anterior da série ← Força de senhas explicada: comprimento, entropia e frases-senha
Referências
- NIST FIPS 180-4 — Secure Hash Standard (SHS) (August 2015)
- NIST FIPS 202 — SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions (August 2015)
- RFC 6151 — Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms (March 2011)
- NIST — NIST Retires SHA-1 Cryptographic Algorithm (December 2022)
- EFF — Cryptographers Demonstrate Collision in Popular SHA-1 Algorithm (February 2017)
- MDN Web Docs — SubtleCrypto: digest() method
- Microsoft Learn — Get-FileHash
- Ubuntu — How to verify your Ubuntu download
- hashcat v6.2.6 benchmark, NVIDIA GeForce RTX 4090
- NIST SP 800-63B-4 — Authenticators: password verifiers (July 2025)
- OWASP — Password Storage Cheat Sheet
- RFC 9106 — Argon2 Memory-Hard Function for Password Hashing and Proof-of-Work Applications (September 2021)
- RFC 2104 — HMAC: Keyed-Hashing for Message Authentication (February 1997)
- RFC 7518 — JSON Web Algorithms (JWA) (May 2015)
Guias relacionados
- Endereços IP explicados: IPv4, IPv6 e as faixas reservadas
- Sub-redes e CIDR explicados: prefixos, máscaras e hosts utilizáveis
- Registros DNS explicados: A, AAAA, CNAME, MX, TXT e NS
- Um site está fora do ar ou é só com você? Como verificar, passo a passo
- Códigos de status HTTP e erros da Cloudflare: o que significam 403, 404, 429, 500, 503 e 521
- Timestamps Unix e fusos horários explicados
- Contagem de datas: dias entre datas, anos bissextos e semanas ISO
- Formatos de imagem explicados: JPEG, PNG, WebP, AVIF e HEIC
- Força de senhas explicada: comprimento, entropia e frases-senha
- UUIDs explicados: v4, v7 e como escolher a versão certa
- QR codes explicados: capacidade, correção de erros e tamanho de impressão
- Porcentagens e IVA explicados: somar, tirar e acumular
- Erros comuns em JSON e como corrigi-los
- Edição de PDFs no navegador: o que se mantém ao juntar, dividir e converter