# Quanto tempo demora mesmo a quebrar a tua palavra-passe > O tempo que uma palavra-passe aguenta não é decidido pela palavra-passe: é decidido pelo hash com que o site a guardou. E disso ninguém te avisa no registo. 2026-03-04 · David Carrero · password.es Original: https://password.es/pt/blog/quanto-tempo-demora-mesmo-a-quebrar-a-tua-palavra-passe/ --- Quando um site te diz que a tua palavra-passe demoraria *três milhões de anos* a ser quebrada, está a omitir a parte importante da frase. A pergunta certa não é quanto tempo demora. É **quanto tempo demora contra o quê**. E a resposta ao *contra o quê* não és tu que a decides. Decidiu-a um programador da loja onde compraste umas sapatilhas em 2019, quando escolheu como guardar a tua palavra-passe na base de dados. Tu escreveste a mesma cadeia de vinte caracteres nos dois sítios. Num aguenta séculos, no outro cai antes do almoço. ## O número que falta na equação Um ataque por força bruta é aritmética vulgar: número de candidatos que é preciso testar, a dividir pelos candidatos que consegues testar por segundo. O primeiro factor depende da tua palavra-passe — do comprimento, do alfabeto, de estar ou não num dicionário. O segundo **não tem absolutamente nada a ver contigo**. O segundo factor depende de duas coisas: o hardware do atacante e, sobretudo, a função com que o site converteu a tua palavra-passe naquela salgalhada que guarda na tabela de utilizadores. Essa função chama-se *hash*, e nem todas custam o mesmo a calcular. O MD5 e o SHA-1 foram desenhados para serem rápidos. É uma virtude: são funções de hash de uso geral, pensadas para resumir mensagens e verificar integridade, e aí o que queremos é processar um gigabyte sem dar tempo de ir buscar um café. Quando alguém as usa para guardar palavras-passe, essa virtude passa a ser o problema. Uma função que consegues calcular milhões de vezes por segundo é uma função que **o atacante também consegue calcular milhões de vezes por segundo** — e ele tem placas gráficas e o fim de semana todo pela frente. O bcrypt e o Argon2 foram desenhados com o objectivo contrário. São lentos de propósito e — isto é o que tem elegância — com lentidão regulável. Niels Provos e David Mazières apresentaram o bcrypt em 1999 com um título que diz tudo: *A Future-Adaptable Password Scheme*. A ideia era que a função pudesse ficar mais cara com os anos, ao ritmo a que o hardware fosse ficando mais barato. O Argon2, que venceu a Password Hashing Competition em 2015, deu mais uma volta ao parafuso: não custa só tempo, custa **memória**, que é justamente aquilo que as GPU têm à mão com menos folga. Entre um hash rápido e um hash lento bem configurado não há uma diferença de percentagens. Há ordens de grandeza. Muitas. ## Os benchmarks existem, e são públicos Nada disto é especulação. O *hashcat*, a ferramenta que meio mundo usa para quebrar palavras-passe — os bons incluídos —, traz um modo de benchmark que qualquer pessoa pode correr na sua própria máquina e que mede, algoritmo a algoritmo, quantas vezes por segundo se consegue calcular cada um. A comunidade publica essas tabelas sempre que sai uma GPU nova. O interessante nessas tabelas não é nenhum número em concreto — que aliás caduca a cada geração de hardware — mas **a distância entre as linhas**. Ordenas a lista por velocidade e vês o MD5 lá no topo, num planeta só dele. Desces, desces mais, e no fundo da tabela estão o bcrypt e o Argon2, com números que não se parecem nada com os primeiros. É a mesma palavra-passe. É a mesma GPU. A única coisa que mudou foi a forma como o site decidiu guardá-la. Por isso «3 milhões de anos» sem dizer contra que hash é marketing, não é uma medição. É como anunciar que o teu carro demora seis horas a chegar sem mencionar o destino. ## Offline e online: dois mundos que não se tocam Há uma segunda distinção que quase ninguém explica e que altera o resultado de forma igualmente brutal. Num ataque **online**, o atacante testa palavras-passe contra o formulário de entrada, como faria um utilizador. O ritmo não é o hardware dele que o impõe: é o servidor. Pode haver limite de tentativas, bloqueio temporário, um *captcha*, atraso entre pedidos, alertas quando se detectam mil falhas vindas do mesmo endereço. Contra um site decentemente defendido, um ataque online é lento, barulhento e bastante estúpido. A aritmética é tão má para o atacante que a força bruta pura quase não se tenta: testam-se as quatro palavras-passe do costume contra milhões de contas, que já é outro jogo. Num ataque **offline**, o atacante já tem o despejo da base de dados. Leva-o para casa. Ali não há servidor, nem limite de tentativas, nem ninguém a olhar: há as placas gráficas dele e a factura da luz. Pode andar a tentar durante meses sem que ninguém dê por isso, e saberá que acertou sozinho, comparando hashes. É aqui que o hash decide tudo, porque o hash é literalmente a única coisa que o trava. E convém ser honesto quanto às probabilidades: o cenário offline não tem nada de exótico. É o que acontece sempre que uma base de dados é divulgada. Quando o LinkedIn perdeu a sua, em 2012, a análise do despejo divulgado mostrou que guardava as palavras-passe com SHA-1 **sem sal**: um hash rápido e sem o ingrediente que impede pré-calcular tabelas. O facto de terem sido quebradas tantas e tão depressa não foi só por os utilizadores escolherem mal. Foi, sobretudo, uma decisão de engenharia que nenhum utilizador chegou a ver. ## O que fazemos aqui, e porque o dizemos O nosso [verificador](/pt/verificador/) assume **10¹² tentativas por segundo, offline, contra um hash rápido**. Está escrito na própria página, por baixo do resultado, e não é transparência decorativa: sem esse dado, o tempo que te mostra não significa nada. É deliberadamente o mau cenário. Assumimos que a base de dados já foi divulgada, que o atacante tem hardware a sério, que o site guardou a tua palavra-passe da pior maneira razoavelmente possível e que ainda por cima conhece o teu alfabeto e o teu comprimento. Se o site usou bcrypt bem configurado, o número real sobe muitas ordens de grandeza e a tua palavra-passe aguenta muitíssimo mais do que te dizemos. Preferimos errar para esse lado. **Um verificador que te dá os parabéns está a dar os parabéns a si próprio.** ## A conclusão incómoda A tua palavra-passe não tem um tempo de quebra. Tem um tempo de quebra *por cada sítio onde a usaste*, e esse tempo é fixado por gente que não conheces com critérios que não publica. Daqui deduzem-se duas coisas, e são as do costume. A primeira: como não podes controlar o hash, **controla a entropia**, que é a metade da equação que é mesmo tua — por isso é que o [gerador](/pt/) te mostra bits e não uma percentagem simpática. A segunda, e mais importante: se cada sítio tiver a sua própria palavra-passe, aquele que a guardou em MD5 só pode oferecer a desse sítio. Porque o elo fraco não é a tua palavra-passe. É o pior sítio onde a escreveste. --- *Fontes: benchmarks públicos do hashcat (`hashcat -b`), consultáveis e reproduzíveis · N. Provos e D. Mazières, «A Future-Adaptable Password Scheme», USENIX, 1999 · Password Hashing Competition, vencida pelo Argon2 em 2015 · o modelo de ameaça declarado no verificador de password.es: 10¹² tentativas/s, offline, hash rápido · brecha do LinkedIn de 2012: a empresa confirmou a fuga, e o uso de SHA-1 sem sal foi estabelecido ao analisar o despejo publicado.*