# Hash, sal, bcrypt e Argon2: o que faz com a tua palavra-passe um site bem feito

> Um site bem feito não sabe a tua palavra-passe: guarda uma impressão digital. E a função que calcula essa impressão tem de ser lenta de propósito, porque é a única defesa em que o defensor e o atacante correm exactamente a mesma corrida.

2026-03-26 · David Carrero · password.es
Original: https://password.es/pt/blog/hash-sal-bcrypt-argon2/

---

Um site bem feito não sabe a tua palavra-passe. Não é que não queira: é que não
pode.

Soa a truque, porque de cada vez que a escreves o sistema deixa-te entrar, e para
te deixar entrar tem de verificar alguma coisa. Mas verificar não é saber. O
servidor guarda uma **impressão digital** calculada a partir da tua
palavra-passe; quando escreves, volta a calcular a impressão e compara. Se
coincidirem, entras. **Em momento algum é preciso que a palavra-passe esteja
escrita seja onde for.**

Daí sai o sinal mais claro para distinguir um serviço sério de um que não o é: se
ao esqueceres-te dela ta enviam por email, tinham-na guardada. E o que está
guardado acaba, mais cedo ou mais tarde, nas mãos de outra pessoa.

## 1979: a ideia de não as guardar — e a de o fazer devagar

Em 1979, **Robert Morris e Ken Thompson** publicaram na *Communications of the
ACM* «Password Security: A Case History», onde contavam o que tinham feito no
Unix. É um relato do que aprenderam, e nele ficam assentes duas ideias que hoje
damos por evidentes.

A primeira não foram eles que a inventaram — guardar o hash em vez da
palavra-passe já se fazia antes —, mas explicaram-na melhor do que ninguém: **não
guardar a palavra-passe, guardar o seu hash**. Uma função que converte a tua
palavra-passe num valor de aspecto arbitrário e que não se pode desandar: do hash
não se regressa à palavra-passe.

A segunda é mesmo deles: **o sal**. Um valor aleatório diferente para cada
utilizador, que se mistura com a palavra-passe antes de calcular o hash. Sem sal,
duas pessoas com a mesma palavra-passe têm o mesmo hash — o ficheiro roubado
transforma-se num jogo de encontrar repetidos — e, pior, alguém pode pré-calcular
uma tabela gigantesca uma única vez e usá-la contra todas as bases de dados do
mundo. **O sal não torna a tua palavra-passe mais difícil de adivinhar: faz com
que adivinhá-la não sirva de nada a mais ninguém.**

Mas nesse mesmo artigo há uma terceira ideia, muito menos citada, e é a que
importa aqui: fizeram a função **deliberadamente lenta**. Não por descuido. De
propósito. Cifrar uma palavra-passe custava muito mais do que tecnicamente era
preciso, porque a quem entra uma vez por manhã tanto lhe faz, e a quem
experimenta milhões de candidatas não.

Está ali o assunto todo, numa frase com quase cinquenta anos.

## Porque é que a lentidão é a única defesa honesta

Quase todas as defesas informáticas são assimétricas: custam pouco a quem se
defende e muito a quem ataca. Cifrar é barato; decifrar sem a chave é inviável. O
defensor joga com vantagem estrutural.

O armazenamento de palavras-passe não. **Aqui defensor e atacante executam
exactamente a mesma função.** Tu calculas o hash para verificar que acertaste;
ele calcula-o para verificar se acertou. É a única corrida da segurança onde os
dois correm com as mesmas pernas.

Quando não consegues correr mais do que o teu rival, resta uma jogada: **encarecer
a pista para os dois**. Tu pagas esse custo uma vez por início de sessão. Ele,
uma vez por tentativa. Como precisa de ordens de grandeza mais tentativas do que
tu, a mesma factura afecta-vos de forma incomparável. É isso que faz um hash de
palavras-passe.

Por isso é que as funções rápidas e óptimas para outras coisas — o SHA-256, por
exemplo — são uma escolha péssima aqui. São rápidas. Rápido é exactamente o que
não queremos.

## 1999: bcrypt, e o custo como peça ajustável

O problema de uma função lenta é que o hardware não fica quieto. O que em 1979 era
lento, mais tarde é instantâneo. Uma defesa calibrada contra os computadores de
uma década envelhece sozinha, sem que ninguém lhe toque.

Em 1999, **Niels Provos e David Mazières** apresentaram o **bcrypt** na USENIX
Annual Technical Conference, com um título que diz logo tudo: *A Future-Adaptable
Password Scheme*.

A ideia: que o custo **não esteja na função, mas num parâmetro**. O bcrypt tem um
factor de custo que és tu que decides e que fica guardado junto ao hash. Se o
hardware ficar muito mais rápido, sobes o número e as palavras-passe novas voltam
a custar o que devem, sem mudar de algoritmo.

**É um desenho que assume a sua própria obsolescência e se prepara para ela.** Há
pouquíssimo software que faça isso.

## 2009: scrypt, e a descoberta de que o tempo não chega

O bcrypt encarece o tempo de cálculo, e resultou. Até que o atacante deixou de
usar o mesmo tipo de máquina que o defensor.

Um servidor tem uns poucos núcleos rápidos e de uso geral. Uma GPU tem uma
barbaridade de núcleos pequenos a fazer o mesmo em paralelo, e um ASIC vai mais
longe: silício fabricado para executar uma única operação. Se a tua defesa
consiste em «esta operação custa X», alguém pode construir hardware que faça
muitos X ao mesmo tempo. O defensor continua com o servidor dele.

Em 2009, **Colin Percival** apresentou o **scrypt** com outro argumento: *Stronger
Key Derivation via Sequential Memory-Hard Functions*. Se o custo está só no
cálculo, paraleliza-se. Mas **a memória não é oferecida**. Obriga a função a usar
muita RAM e a percorrê-la de forma que não se possa contornar, e de repente o
atacante não pode multiplicar núcleos: cada núcleo precisaria da sua própria
memória. E os núcleos de uma GPU têm muita potência e muito pouca RAM para cada
um.

**Percival não encareceu a operação. Encareceu o hardware necessário para a
repetir em massa.** É uma mudança de nível: ataca-se o orçamento do atacante, não
o relógio dele.

## 2015: Argon2, e o fim do debate

Existirem várias opções razoáveis não ajudava ninguém a escolher. Por isso a
comunidade criptográfica fez o que costuma fazer quando quer arrumar um assunto:
um concurso público. A **Password Hashing Competition** recebeu candidatos,
submeteu-os a análise aberta durante anos e em **2015** proclamou vencedor o
**Argon2**.

O Argon2 herda as duas lições: custo em tempo e custo em memória, ambos ajustáveis
em separado, mais o número de fios de execução. Não é magia. É a síntese arrumada
de 1979, 1999 e 2009, revista por gente cujo trabalho consistia em tentar
parti-la.

## O que isto significa para ti

Quase nada disto está nas tuas mãos, e convém dizê-lo: **o hash é o site que o
escolhe, não tu**. Podes ter a melhor palavra-passe do mundo e guardarem-ta em
texto simples num Excel.

Mas o outro lado da equação depende mesmo de ti. Todo este edifício — o sal, o
custo, a memória — serve para **encarecer cada tentativa** do atacante. O que
decide de quantas tentativas ele precisa é a tua palavra-passe. Se estiver num
dicionário, nenhuma função lenta te salva: cai logo nas primeiras. Se for comprida
e não se parecer com nada, esse preço por tentativa multiplica-se por um número de
tentativas que não cabe no tempo disponível.

Por isso é que o nosso [gerador](/pt/) mede **bits de entropia** e não
percentagens, e por isso é que o [verificador](/pt/verificador/) procura a tua
palavra-passe em dicionários antes de contar símbolos. **Eles põem o preço por
tentativa; tu pões o número de tentativas.** Nenhuma das duas metades funciona sem
a outra.

E sim: continua a ser a mesma pergunta de sempre. Só que agora, do outro lado,
alguém tenta respondê-la muitas vezes por segundo, e andamos desde 1979 a tentar
que cada uma dessas vezes lhe custe dinheiro.

---

*Fontes: R. Morris e K. Thompson, «Password Security: A Case History»,
Communications of the ACM, 1979 · N. Provos e D. Mazières, «A Future-Adaptable
Password Scheme», USENIX Annual Technical Conference, 1999 (bcrypt) · C.
Percival, «Stronger Key Derivation via Sequential Memory-Hard Functions», 2009
(scrypt) · Password Hashing Competition, vencedor Argon2, 2015.*