Bcrypt

O que existe de verdade dentro de um hash bcrypt

Um hash bcrypt é uma única string de sessenta caracteres, e cada parte dela está à vista. Nada nela é secreto além da senha que a produziu, e essa não está ali de jeito nenhum. Ler um hash por dentro não exige chave, nem senha, nem cálculo algum: esta página faz isso no instante em que você cola um.

• A variante, o campo com que a string começa: $2b$, $2a$ ou $2y$. Ela diz segundo as regras de quem o hash foi produzido.
• O custo, escrito com exatamente dois dígitos: de 04 a 31. Ele é um expoente, então custo 12 quer dizer 2^12 — 4.096 — rodadas de estiramento de chave, e o custo 13 dá o dobro do trabalho do 12 em vez de um treze avos a mais.
• O sal, vinte e dois caracteres: dezesseis bytes aleatórios, guardados à vista ao lado da resposta que eles salgaram.
• O digest, os últimos trinta e um caracteres: vinte e três bytes de saída. É a única parte que depende da senha, e ele não é o hash — o hash é a string inteira.

O alfabeto de onde saem esses caracteres é o do próprio bcrypt, e não é o Base64 padrão: ele vai ./A-Za-z0-9, então um ponto e uma barra abrem onde o Base64 põe o mais e a barra no fim. Decodificar isso com um decodificador Base64 comum devolve bytes errados em vez de um erro, e essa é uma maneira clássica de perder uma tarde.

O limite de setenta e dois bytes é contado em bytes, e isso pesa

O bcrypt lê no máximo setenta e dois bytes de uma senha e ignora tudo o que vem depois. Não setenta e dois caracteres — setenta e dois bytes de UTF-8, então quantos caracteres isso dá depende do que custam as letras de cada idioma: as vinte e seis letras latinas sem sinais custam um byte cada uma, e qualquer outra letra custa mais. Em português a diferença é pequena e real ao mesmo tempo: cada vogal acentuada — á, à, â, ã, é, ê, í, ó, ô, õ, ú — e também o ç custam dois bytes, então uma senha com alguns acentos chega ao limite alguns caracteres antes dos setenta e dois. Uma feita só dessas letras o alcançaria em trinta e seis.

• O ASCII custa um byte por caractere, então quem fala inglês chega ao limite em setenta e dois caracteres e quase nunca chega.
• O hebraico, o árabe, o russo e o grego custam dois bytes por letra, então o limite chega aos trinta e seis caracteres.
• O japonês, o coreano e o chinês custam três, então ele chega aos vinte e quatro.
• A maioria dos emojis custa quatro, e muitos dos que as pessoas realmente digitam são vários pontos de código unidos, então um punhado deles já é todo o orçamento.

O contador de bytes embaixo do campo da senha está ali para que isso seja algo que você vê chegando em vez de descobrir depois. E o corte cai no byte, não no caractere, exatamente como faz toda implementação de referência — então um caractere multibyte em cima da fronteira perde uma parte de si e conserva o resto. Esse é o comportamento compatível e não um defeito, e esta página diz isso quando acontece.

E agora a parte que explica todo o resto: o truncamento é invisível na resposta. O escalonamento da chave mistura no seu estado exatamente setenta e dois bytes de chave e nunca dá a volta com uma mais longa, então gerar o hash de uma senha de cem bytes e gerar o dos seus primeiros setenta e dois bytes produzem o mesmo digest. Não há nada para uma implementação detectar nem nada para ela relatar, e é por isso que nenhuma biblioteca levanta um erro e por isso duas senhas longas diferentes que coincidem nos primeiros setenta e dois bytes correspondem ao mesmo hash armazenado. Esta página também não pode recusar uma senha longa — se você está conferindo contra um hash que um sistema real produziu truncando, precisa da resposta — então ela dá a resposta e diz o que foi cortado.

A variante muda o prefixo e não o digest

A variante parece um número de versão e não é. As três que esta ferramenta escreve não estão ordenadas, nenhuma substitui outra, e escolher entre elas é uma decisão de compatibilidade e não de segurança.

• $2b$ é aquela em que o OpenBSD parou e é a que Python, Node e Go emitem hoje. Aqui ela é o padrão e é a resposta certa quando nada obriga a outra.
• $2a$ é a mais antiga, e algumas instalações veteranas de Java e Spring Security ainda esperam vê-la.
• $2y$ é a que o password_hash do PHP e, portanto, o Laravel escrevem, então um hash colado nesse mundo costuma pedi-la.

O que separa as três é como elas tratam uma chave com mais de 255 bytes, e o bcrypt já parou de ler nos setenta e dois — então nenhuma senha que você consiga digitar aqui alcança essa diferença. Para tudo o que esta ferramenta um dia vá receber, as três produzem os mesmos vinte e três bytes e só se separam nos quatro caracteres da frente. Troque a variante e o digest não se move.

Existem mais duas e esta ferramenta as nomeia em vez de calculá-las. $2x$ não é uma correção: a Openwall a cunhou de propósito para reproduzir um bug de extensão de sinal, de modo que os hashes feitos pelo código quebrado ainda pudessem ser conferidos, e implementá-la aqui seria pôr um defeito conhecido dentro da ferramenta. $2$ é a original, de antes de o byte zero final ser acrescentado à chave. Nenhuma das duas é emitida por nada atual; se você tem uma na mão, ela saiu de um sistema velho o bastante para a variante ser o menor dos seus achados.

O custo, e o que ele custa na sua própria máquina

O custo é o fator de trabalho, de 4 a 31, e é um expoente: cada passo dobra o tempo. É nisso que consiste o bcrypt inteiro. O hash de uma senha precisa ser lento, porque um atacante com uma tabela roubada paga o mesmo preço em cada tentativa, e dobrar o custo corta pela metade o número de tentativas por segundo que o dinheiro dele compra.

Quanto um custo dado leva de verdade é um fato sobre a máquina que o roda, não um número que dê para escrever de antemão: um celular e um servidor estão a duas ordens de grandeza um do outro. Por isso esta página mede em vez de citar: ao carregar, ela roda um hash curto no seu próprio dispositivo e extrapola dali, e é por isso que a estimativa ao lado do controle do custo fica vazia por um instante e depois aparece. Acima de alguns segundos ela pergunta antes de começar, para que um dígito digitado errado não seja lido como uma página travada.

Para escolher um número: 12 é o que o Laravel e o pacote bcrypt do Python emitem por padrão e hoje é um piso razoável em produção. Custos mais baixos servem para fixtures de teste, onde uma suíte que semeia cinquenta usuários não deveria gastar um segundo por usuário. Custos acima de 15 vale a pena medir contra o seu tráfego real de login antes de publicá-los, porque cada entrada também paga o preço.

# Apache: escrever uma linha de htpasswd com custo 12
htpasswd -nbBC 12 alice "correct horse battery staple"

# PHP e Laravel: o password_hash emite $2y$
php -r 'echo password_hash("correct horse battery staple", PASSWORD_BCRYPT);'

# Python: o pacote bcrypt emite $2b$, e o gensalt recebe o custo
python -c "import bcrypt; print(bcrypt.hashpw(b'correct horse battery staple', bcrypt.gensalt(12)))"

O sal, e quando um hash feito aqui não é para armazenar

O sal são dezesseis bytes aleatórios sorteados novos para cada hash, e ele fica à vista dentro da própria string. Não é um segredo e nunca foi para ser: o trabalho dele é fazer com que duas senhas idênticas produzam dois hashes sem relação entre si, de modo que uma tabela roubada não possa ser atacada um dicionário pré-calculado por vez.

É por isso também que a mesma senha dá aqui um hash diferente toda vez que você aperta o botão. Não é uma falha e a resposta anterior não está vencida: um sal novo é o bcrypt funcionando. Qualquer um daqueles hashes corresponde à senha, porque o sal viaja dentro da string que é conferida.

O campo avançado do sal existe para um trabalho só: reproduzir exatamente o hash de outra pessoa, para que duas implementações possam ser comparadas. Cole um hash inteiro nele e o custo e a variante o acompanham sozinhos, então a senha certa reproduz a entrada caractere por caractere. Tudo o que você produzir desse jeito serve para comparar e não para armazenar: um sal usado duas vezes é um sal que parou de fazer o trabalho dele.

Um hash bcrypt não pode ser revertido

As pessoas chegam a páginas como esta procurando um jeito de descriptografar um hash bcrypt. Não existe um, e o motivo não é que seja difícil: a senha não está na string. Sessenta caracteres carregam uma variante, um custo, dezesseis bytes aleatórios e vinte e três bytes de saída, e nenhum arranjo disso contém uma senha de tamanho algum. Nada foi criptografado, então não há nada para descriptografar.

O que um site pode fazer — e é o que fazem os que anunciam descriptografia — é adivinhar. Basta pegar uma lista de senhas comuns, gerar o hash de cada uma contra o seu sal e no seu custo, e ver se alguma corresponde. O bcrypt foi projetado para tornar exatamente isso caro, que é para o que serve o custo, e esta ferramenta não oferece isso de forma alguma.

A versão honesta dessa pergunta costuma ser outra, e essa tem resposta: o que há nesta string, e esta senha em particular a produz? As duas estão nesta página. Cole o hash para ver tudo o que ele carrega, e acrescente uma senha para ter um sim ou um não.