Do MD5/SHA-1 para o futuro

Se o SHA-1 já é considerado não seguro o MD5 eu não preciso nem comentar sobre ele…

Para quem não viu, em fevereiro de 2017, o Google junto com o instituto CWI confirmou a colisão de SHA-1 e fez a publicação da matéria explicando os processos, linkse aqui.

Olhando para esse cenário, é bem interessante (leia-se: melhor fazer) mudar a forma como você esta gerando os hashs de senhas de seus usuários.

Vamos ao cenário proposto. Você tem uma base de usuários que esta toda usando MD5 (ou SHA-1) e não é interessante você enviar um e-mail para todos eles dizendo que eles precisam alterar suas senhas, com isso, você precisa atualizar o hash de senhas de forma transparente.

A forma como o PHP trata as senhas é com as funções “password_” (você pode ler sobre elas Como armazenar as senhas corretamente com PHP e COST do password_hash), estas funções permitem a nós trabalhar com as senhas da forma mais segura possível para o PHP e além disso, sua implimentação correta nos possibilita estar sempre atualizados nas questões de hashs mais seguros.

Como resolver o cenário de uma base com hashs antigos.

A forma como você faz login hoje é mais ou menos dessa forma:

Como o MD5 gera sempre o mesmo hash para o mesmo dado que foi passado, muitos utilizam o MD5 na consulta do MySQL para trazer o usuário que já tem aquele e-mail e senha, se você esta fazendo isso vai precisar alterar para essa forma, pois na hora de verificar a senha precisamos passar a senha que o usuário informou e o hash para a função “password_verify”.

Entendendo como as funções “password_” operam, devemos alterar o código acima para este:

Esse código basicamente faz a mesma validação de MD5, porém quando o usuário é válido para o MD5 ele já faz um novo hash de senha utilizando a “password_hash” e quando não passa no MD5 ainda não quer dizer que falhou o login, ele vai verificar se o hash é o novo e dessa forma validar com “password_verify”, além disso, você pode ver a função “password_needs_rehash”, ela é utilizada para verificar se o hash ainda é válido para as configurações, imagine que nós melhoramos nossa infraestrutura e com isso podemos mudar o valor da opção “cost”, com isso um hash gerado com “cost 10” não é mais válido para um “cost 11” e por conta disso devemos refazer o hash assim melhorando a segurança dele. Isso também é válido para quando mudamos o algorítimo de hash.

Como você pode ver no comentário da validação MD5, esta marcado para remover essa condição, isso porque quando você não tiver mais senhas em MD5 essa condição será inútil.

Agora a última parte, digamos que você deixe esse código por 1 ano em seu sistema e mesmo assim você ainda tem senhas MD5 em sua base de dados, como resolver isso, já que você não quer deixar seus usuários expostos, mesmo aqueles que não utilizam mais seu sistema.

Como me disse o @ericktedeschi. “Deixa assim por um ano e depois faz o reset da senha, se o cara esta a um ano sem entrar no seu sistema ele nem deve lembrar a senha”. É isso, passou muito tempo, de um reset na senha daqueles usuários. Dessa forma você não vai ter a senha deles em MD5.

Isso é tudo. Fazendo a implementação correta das funções “password_”, você esta protegendo seus usuários e ainda fazendo com que novos algoritmos de hash sejam implementados sem alterações estruturais de seu código.

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

This site uses Akismet to reduce spam. Learn how your comment data is processed.