Executando verificação de segurança...
25

Uma curiosidade sobre o bcrypt que não se fala muito

Publiquei essa história no LinkedIn hoje e achei que seria interessante trazer aqui no tabnews também.

Essa semana navegando pela internet descobri algo sobre o bcrypt que eu não sabia e solucionou uma dúvida que ficou na minha cabeça por bastante tempo.

Tudo começou há alguns meses que nossa QA estava testando uma API e criou uma conta de teste com uma senha de 255 caracteres que era o limite do banco. Funcionou perfeitamente. Mas na hora de fazer login, ela teve a brilhante ideia de digitar os 255 caracteres corretos + mais um monte de caracteres errados no final... e conseguiu logar normalmente.

Ficamos sem entender o que diabos estava acontecendo. Revisamos o código, testamos várias combinações, mas nada fazia sentido. Então limitamos os DTOs de entrada para 255 caracteres tanto no login quanto no register que era o que fazia sentido.

Mas nessa semana, estava assistindo um vídeo no YouTube sobre criptografia a peça que faltava se encaixou, em algum momento o autor do vídeo mencionou brevemente que o bcrypt tem limite de 72 caracteres.

O que me deixou espantado é que o bcrypt não retorna erro quando você passa desse limite. Simplesmente ignora tudo que vem depois do caractere 72. Ou seja, "minhasenha123" + 200 caracteres aleatórios vira só "minhasenha123" na hora do hash.

Imediatamente corrigimos nossos DTOs de validação para limitar senhas a 72 caracteres ao invés de 255 que era o padrão.

Quando contei isso para o pessoal aqui do time, ninguém conhecia essa limitação. Aparentemente é uma daquelas coisas que você só descobre quando tropeça nela e eu nunca iria ter achado esse problema se a QA não tivesse testado essa combinação absurda.

Há anos que utilizo o bcrypt e não sabia dessa limitação. Por isso estou vindo compartilhar. Você já sabia dessa?

Carregando publicação patrocinada...
3
1
1

QA é realmente uma arte.

Eu como desenvolvedor nunca pensaria nessa limitação, já que uma senha de 72 caracteres já é grande pra caramba, 255 nem passaria pela minha mente de ser permitido.

Mas faz todo sentido que haja esse tipo de validação.

1

kkkkk é verdade os QA tem um talento especial pra encontrar essas coisas que a gente nunca pensaria como dev.

De fato nunca tinha parado para me preocupar com isso. Até porque na prática não é um problema de segurança grave, a pessoa ainda precisa acertar os 72 caracteres da forma correta. Mas é curioso como essas descobertas surgem dos testes mais 'absurdos' que os QAs fazem!

1

interessante... mas fico pensando dificilmente as pessoas pegam esse tipo de "falha", visto que ou o banco ou a api ja barra senhas maiores que 15 ou 20 digitos

1

Super relevante a informação. Olhando o bcrypt lib.rs tem essa limitação de 72 bytes e retorna um erro caso o password for maior.

if password.len() > 72 {
        return Err(pyo3::exceptions::PyValueError::new_err(
            "password cannot be longer than 72 bytes, truncate manually if necessary (e.g. my_password[:72])",
        ));
    }
1
1

Você já viu o Argon2? Se não, é interessante olhar sobre ele!

É um algoritmo de hash novo (criado em ~2015), vencedor da Password Hashing Competition, eu troquei o bcrypt por ele, performa melhor, mais personalizável e seguro. Para quem não pode arcar com o limite técnico de 72 caracteres do bcrypt, o Argon2 é uma ótima alternativa.

0