O que fazer antes de armazenar ou utilizar as senhas na sua aplicação. Um problema comum que sempre termina em debates apaixonados. Veja como e por que neste artigo.
Este é a primeira parte de uma série de artigos sobre Autenticação. Neste artigo será abordado como armazenar senha de maneira segura.
Por que armazenar de maneira segura?
A maior parte dos cyber ataques, tem alguma relação com funcionários da empresa. Seja por má intenção ou por negligência.
Quem já passou por um processo de certificação do PCI/DSS sabe que a maior parte das técnicas de segurança visa proteger o sistema dos próprios funcionários da empresa. Principalmente de tecnologia.
Senha é a ruina dos desenvolvedores. Autenticação é algo incrivelmente complicado. E uma parte desta complexidade está no armazenamento da senha. A recomendação é: Sempre que possivel, utilize um sistema ou framework existente. Uma autenticação feita por amadores, é uma autenticação amadora.
Mas e se você não puder? Qual a melhor maneira de armazenar senhas no seu sistema?
O jeito errado
Uma boa forma de fazer certo é começando pelo errado. Saber o que não fazer nos guia para como fazer.
Plain Text
Guardar uma senha sem nenhuma criptografia é a pior decisão a ser tomada. Ninguém deveria abrir uma tabela do banco e visualizar todas as senhas em plain text. Se quiser facilitar ainda mais para o atacante, coloque as senhas no Pastebin.
Encoded
Raramente utilizo a primeira pessoa para escrever os artigos. Mas dessa vez pedirei licença.
Base64, Base32 ? Prefiro ver as senhas em Clear Text. Assim tenho a sensação de que quem fez, nem ao menos se preocupou com isso. Quando vejo Base64, Base32 ou qualquer variação dessas me frusto. Pois quem fez tinha a clara intenção de proteger e não teve preocupação em pesquisar. Em minha trajetória, já vi essa decisão ser tomada por mais de uma vez. Frustante!
Criptografada
Criptografar é um pouco melhor que guardar o Password encoded. Criptografia é uma via de mão dupla. Algo criptografado é possivel descriptografar a partir de uma chave. E esse é o problema fundamental em criptgrafar senhas. Aonde estará a chave? E o processo de validação da senha precisa descriptografar para comparar. E se um atacante comprometer a chave terá acesso a todas as senhas do banco.
Calma, antes que você se pergunte: Como assim criptografia não é recomendado? Continue lendo.
Criptografia e Hashing
É comum devs falarem sobre senhas criptografadas, mas que na verdade estão falando sobre senhas com hash.
Uma senha criptografada é um texto que foi tornado ilegível por meio de um processo que usou dados extras. Como uma key. Que pode ser revertida com o conhecimento da mesma key. Ou de um distinto, matematicamente a chave relacionada, no caso de criptografia assimétrica.
Para hashing de senha, por outro lado, não há chave. O processo de hashing é como um moedor de carne. Não há como recuperar a vaca depois do processo.
Criptografias hash são funções que qualquer um pode calcular, eficientemente, através de entradas arbitrárias. Eles são determinísticos (a mesma entrada produz a mesma saída, para todos).
Se o algoritmo é MD5, SHA-* (SHA1, SHA2, SHA3 etc...) ? Então é hashing.
Hash - O Jeito certo
Uma vez que a senha passe pelo processo de hashing, a senha ainda é bastante útil. Por mais que o processo de hashing não seja reversível o resultado do hash da senha do usuário resultará no mesmo valor. E logo pode ser comparada com aquela armazenada. Duas senhas distintas resultarão, com probabilidade muito alta, em dois valores de hash distintos. Na prática, beira o impossivel a senha digitada errada pelo usuário colidir com o mesmo hash.
Como o hash é determinístico, a mesma entrada de texto, produz o mesmo valor de hash. Assim, uma senha com hash é suficiente para verificar se uma determinada senha está correta ou não.
Por que hash?
O atacante pode ter tido acesso as senhas através de um SQL Injection. Extraviado uma fita de backup. Pode ser um DBA, ou dev com acesso ao banco.
Neste artigo não será explorado como o invasor conseguiu o acesso a senha criptografada do repositório. Fato é. Isso aconteceu. Você tem um grande problema.
O hash vai ajudar a proteger a senha verdadeira do teu usário. É como uma segunda linha de defesa. O atacante já passou pela primeira.
Uma vez que o atacante está em posse de algumas senhas, ou todas elas. O próximo passo é descobrir as senhas.
E é diante deste cenário que aplicar uma criptografia unidirecional protege a senha do teu usuário. Se você usar o algoritmo correto, é matematicamente improvável determinar qual é a senha de um hash. Você pode então armazenar livremente esse hash em seu banco de dados.
Basta utilizar hash e estou seguro?
Não. Há uma infinidade de algoritmos hash e muitos deles não são apropriados para hashing de senhas.
Um algoritmo de hash para senha deve ser lento. Algoritimos lentos de hash são resilientes a ataques de hardware.
Na segunda parte deste artigo será abordado as vulnerabilidades do Hash. Os tipos de ataques mais comum e quais algoritimos mais indicados para utilizar em hash de senha.
Conclusão
Nesta primeira parte foi abordado porque o hash é a técnica mais indicada para armazenar senhas.
Não é qualquer algoritmo de hash. Existem falhas. Iremos abordar esse tema na Parte 2.
Espero que tenham gostado dessa primeira parte e tenha ajudado vocês.
Referências
Comments