bcrypt e armazenamento de senhas
Guardar senha com hash rápido é um erro de projeto, não de execução: o mesmo motivo que torna SHA-256 ótimo para checksum de arquivo o torna péssimo para senha. bcrypt existe justamente para inverter essa lógica, sendo devagar de propósito, e o fator de custo é o botão que controla quão devagar.
60 caracteres fixos: versão, custo e salt vão embutidos antes do hash de 31 caracteres restante.
É o padrão desta ferramenta e um valor comum em produção, equilibrando resistência a força bruta com tempo de login aceitável.
8 vezes mais lento que o custo 12; útil em sistemas de baixo volume de login onde latência maior é aceitável em troca de mais resistência.
Porque o bcrypt gera um salt aleatório novo a cada execução e o embute no início do hash. Isso é proposital: dois usuários com a mesma senha terão hashes diferentes, o que impede ataques por tabela (rainbow tables). A verificação usa o salt que está dentro do próprio hash, então funciona mesmo com o valor mudando.
Porque o salt já vem embutido no próprio texto do hash, nos 22 caracteres logo após o segundo `$`; ao verificar uma senha, a função extrai esse salt do hash salvo e recalcula com ele, então uma única string por usuário basta para autenticação, sem tabela extra nem risco de desalinhar salt e hash.
É uma diferença de 2¹¹, ou 2048 vezes mais iterações, já que o custo é exponente de base 2: custo 4 roda 2⁴ = 16 iterações, quase instantâneo mas fraco contra força bruta; custo 15 roda 2¹⁵ = 32768, seguro mas perceptivelmente mais lento em cada tentativa de login.
Não além dos primeiros 72 bytes: bcrypt tem um limite fixo de entrada de 72 bytes e ignora silenciosamente qualquer caractere além disso no cálculo do hash, então uma senha de 100 caracteres produz o mesmo hash que os primeiros 72 bytes dela, sem ganho de segurança pelo excedente.
Porque SHA-256 foi desenhado para ser rápido, a mesma propriedade que o torna ideal para checksum de arquivo o torna vulnerável a força bruta offline em escala, já que uma GPU calcula bilhões de tentativas SHA-256 por segundo; bcrypt resolve isso sendo deliberadamente lento por um fator de custo ajustável, o que SHA-256 puro nunca ofereceu.
Cada +1 no custo dobra o tempo de cálculo. 10–12 é o equilíbrio recomendado hoje; valores altos protegem mais contra força bruta, mas tornam o login mais lento.
Por segurança, todo o cálculo de bcrypt (geração e verificação) acontece no seu navegador com aleatoriedade da WebCrypto. A senha e o hash nunca são enviados a nenhum servidor.