Como o bcrypt pode ter sais embutidos?

O artigo de Coda Hale "Como armazenar com segurança uma senha" afirma que:

O bcrypt possui sais embutidos para evitar ataques à tabela do arco-íris.

Ele cita este artigo , que diz que na implementação do OpenBSD de bcrypt:

O OpenBSD gera o sal bcrypt de 128 bits a partir de um fluxo de chaves arcfour (arc4random (3)), semeado com dados aleatórios que o kernel coleta a partir das temporizações do dispositivo.

Eu não entendo como isso pode funcionar. Na minha concepção de sal:

• Ele precisa ser diferente para cada senha armazenada, para que uma tabela arco-íris separada precise ser gerada para cada senha armazenada.
• Ele precisa ser armazenado em algum lugar para que possa ser repetido: quando um usuário tenta fazer login, tentamos a senha, repetimos o mesmo procedimento de sal e hash que fizemos quando armazenamos a senha originalmente e comparamos

Quando estou usando o Devise (um gerenciador de login do Rails) com o bcrypt, não há coluna salt no banco de dados, então estou confuso. Se o sal for aleatório e não for armazenado em nenhum lugar, como podemos repetir com segurança o processo de mistura?

Em resumo, como o bcrypt pode ter sais embutidos ?

Isto é bcrypt:

Gere um sal aleatório. Um fator de "custo" foi pré-configurado. Colete uma senha.

Derive uma chave de criptografia da senha usando o fator de custo e sal. Use-o para criptografar uma sequência conhecida. Armazene o custo, o sal e o texto cifrado. Como esses três elementos têm um comprimento conhecido, é fácil concatená-los e armazená-los em um único campo, e ainda assim poder separá-los mais tarde.

Quando alguém tentar se autenticar, recupere o custo e o sal armazenados. Derive uma chave da senha de entrada, custo e sal. Criptografe a mesma sequência conhecida. Se o texto cifrado gerado corresponder ao texto cifrado armazenado, a senha será uma correspondência.

O Bcrypt opera de maneira muito semelhante aos esquemas mais tradicionais baseados em algoritmos como PBKDF2. A principal diferença é o uso de uma chave derivada para criptografar texto sem formatação conhecido; outros esquemas (razoavelmente) assumem que a função de derivação de chave é irreversível e armazenam a chave derivada diretamente.

Armazenado no banco de dados, um bcrypt"hash" pode ser algo como isto:

$ 2a $ 10 $ vI8aWBnW3fID.ZQ4 / zo1G.q1lRps.9cGLcZEiGDMVr5yUP1KUOYTa

Na verdade, são três campos, delimitados por "$":

• 2aidentifica a bcryptversão do algoritmo que foi usada.
• 10é o fator de custo; 2 ¹⁰ iterações da função de derivação de chave são usadas (o que não é suficiente, a propósito. Eu recomendaria um custo de 12 ou mais.)
• vI8aWBnW3fID.ZQ4/zo1G.q1lRps.9cGLcZEiGDMVr5yUP1KUOYTaé o sal e o texto cifrado, concatenados e codificados em uma Base-64 modificada. Os primeiros 22 caracteres decodificam para um valor de 16 bytes para o sal. Os caracteres restantes são texto cifrado a ser comparado para autenticação.

Este exemplo é retirado da documentação para implementação em ruby ​​de Coda Hale.

Acredito que essa frase deveria ter sido redigida da seguinte forma:

O bcrypt possui sais embutidos nos hashes gerados para evitar ataques à tabela do arco-íris.

O bcryptutilitário em si não parece manter uma lista de sais. Em vez disso, os sais são gerados aleatoriamente e anexados à saída da função, para que sejam lembrados posteriormente (de acordo com a implementação Java debcrypt ). Em outras palavras, o "hash" gerado por bcryptnão é apenas o hash. Pelo contrário, é o hash e o sal concatenados.

Para tornar as coisas ainda mais claras,

Direção de registro / login ->

A senha + salt é criptografada com uma chave gerada a partir de: cost, salt e a senha. chamamos esse valor criptografado de cipher text. em seguida, anexamos o salt a esse valor e o codificamos usando base64. anexando o custo a ele e esta é a sequência produzida a partir de bcrypt:

$2a$COST$BASE64

Este valor é armazenado eventualmente.

O que o invasor precisaria fazer para encontrar a senha? (outra direção <-)

Caso o invasor tenha controle sobre o banco de dados, o invasor decodificará facilmente o valor base64 e poderá ver o sal. o sal não é secreto. embora seja aleatório. Então ele precisará descriptografar o arquivo cipher text.

O que é mais importante: não há hash nesse processo, mas criptografia cara da CPU - descriptografia. portanto, as tabelas arco-íris são menos relevantes aqui.

Isso é da documentação da interface PasswordEncoder da Spring Security,

 * @param rawPassword the raw password to encode and match
 * @param encodedPassword the encoded password from storage to compare with
 * @return true if the raw password, after encoding, matches the encoded password from
 * storage
 */
boolean matches(CharSequence rawPassword, String encodedPassword);

O que significa que você precisará corresponder ao rawPassword que o usuário digitará novamente no próximo login e corresponderá à senha codificada em Bcrypt, armazenada no banco de dados durante o login / registro anterior.