epixoip/hmac-bcryptA função de hash de senha hmac-bcrypt
Este repositório contém implementações de referência da função de hash de senha hmac-bcrypt em vários idiomas. Cada implementação de referência tenta ser um port 1:1 das implementações originais em C e Perl criadas por @epixoip sempre que possível, e são totalmente compatíveis entre si (ou seja, produzem e validam os mesmos valores de hash).
Cada implementação de referência define duas funções procedurais com os seguintes pseudo-protótipos:
string hmac_bcrypt_hash(password, settings?, pepper?)
boolean hmac_bcrypt_verify(password, expected, pepper?)
Consulte os casos de teste fornecidos com cada implementação de referência para saber como integrar e usar essas funções no seu projeto. Uma interface procedural foi escolhida por simplicidade, mas você é livre para incorporar essas funções em classes ou objetos como desejar.
O parâmetro settings neste contexto refere-se a uma string de configurações bcrypt padrão contendo o identificador de hash (2a), o custo log2 (ex.: 13) e um valor de salt opcional de 22 bytes codificado em radix64 (ex.: LhayLxezLhK1LhWvKxCyLO). Esses valores são concatenados em uma string delimitada por cifrão; ex.: $2a$13$LhayLxezLhK1LhWvKxCyLO.
O parâmetro settings é opcional; na maioria das vezes, deve ser deixado nulo/vazio para usar o custo padrão de 13 e um salt gerado. No máximo, se você desejar usar um valor de custo diferente de 13, pode fornecer apenas o id + valor de custo (ex.: $2a$10$). Não é recomendado criar e fornecer seus próprios valores de salt!
O parâmetro pepper define um segredo compartilhado global e também é opcional; se for nulo/vazio, o valor padrão de hmac_bcrypt é usado. Isso serve principalmente para defesa contra ataques de shucking, mas também pode ser usado para aumentar a segurança, a dificuldade e o custo de quebra (especialmente quando usado em conjunto com um HSM).
A função de hash de senha hmac-bcrypt utiliza bcrypt com pré-hash e pós-hash adequados, combinados com um pepper opcional. Em pseudocódigo, isso é bastante simples:
pre_hash = hmac_sha512_base64(password, pepper)
mid_hash = bcrypt(pre_hash, settings)
post_hash = hmac_sha512_base64(mid_hash, pepper)
return settings + post_hash
O pré-hash é empregado para permitir comprimentos de entrada maiores que o máximo de 72 bytes de entrada do bcrypt. O SHA-512 foi selecionado devido ao seu tamanho de palavra de 64 bits, que é favorável a defensores via CPU, mas prejudica atacantes via GPU. No entanto, um valor SHA-512 bruto não pode ser usado por vários motivos:
Para mitigar ataques de shucking, o pré-hash precisa ser salgado -- ou, neste caso, apimentado -- e o HMAC fornece um veículo conveniente para chavear um hash. O valor HMAC resultante é então codificado com base64 para produzir uma entrada limpa, composta apenas por caracteres ASCII comuns, que mitiga problemas com bytes nulos e dados binários.
O leitor atento notará que hmac_sha512_base64 produz 88 bytes de dados, enquanto o bcrypt tem um tamanho máximo de entrada de 72 bytes. Isso não é um problema; na verdade, é preferível a utilizar um algoritmo de hash que produza menos dados de entrada, como o sha256. Queremos preencher todos os 72 bytes, e nenhuma segurança é perdida ao truncar o sha512 para 432 bits (isso é maior que os 384 bits fornecidos pelo sha384).
O pós-hash é empregado principalmente para diferenciar hashes hmac-bcrypt de hashes bcrypt -- ou seja, os comprimentos serão diferentes -- mas também para adicionar uma camada extra de proteção devido ao pepper. A etapa de pós-hash pode até ser executada com o valor do pepper armazenado em um HSM (altamente recomendado!) para proteção adicional.
Embora a resistência de memória (memory hardness) tenha sido um experimento interessante, o caminho correto para alcançar resistência à aceleração é, claramente, a resistência de cache (cache hardness). As velocidades e a largura de banda da memória continuam aumentando, enquanto a RAM se torna maior, mais barata e mais densa. Mas os tamanhos de cache, as velocidades de cache e os custos de cache são relativamente estáticos. Até mesmo as instruções de hardware scatter/gather não tiveram o impacto dramático que previmos que teriam nos algoritmos cache-hard.
Os melhores algoritmos memory-hard -- Argon2 e scrypt -- são, na verdade, menos resistentes à aceleração do que algoritmos cache-hard para um tempo de execução alvo inferior a 1000ms, o que os torna ótimos KDFs, mas não tão eficientes para autenticação em tempo real.
Idealmente, usaríamos uma função de hash de senha intencionalmente cache-hard, como pufferfish ou bscrypt. No entanto, essas funções são mais novas, menos estudadas e têm poucas bibliotecas disponíveis. O bcrypt, porém -- embora involuntariamente cache-hard -- está prontamente disponível para praticamente todas as linguagens e frameworks. Dos algoritmos que temos prontamente disponíveis, o bcrypt fornece a maior resistência à aceleração para autenticação interativa em tempo real (tempo de execução alvo < 1000ms), então a resposta óbvia é aproveitar o bcrypt que temos disponível.
No entanto, o bcrypt tem algumas limitações notáveis, como seus críticos mais vocais são rápidos em apontar:
O hmac-bcrypt resolve essas duas questões, e mais.