Como os algoritmos de hashing de senha funcionam e por que você nunca escreve o seu próprio

Views: 602
0 0
Read Time:5 Minute, 52 Second

Você está fascinado com criptografia? Você não está sozinho: muitos engenheiros estão. Ocasionalmente, alguns deles decidem ir tão longe quanto escrever suas próprias funções de hash criptográfico personalizados e usá-las em aplicativos do mundo real. Embora compreensivelmente sedutor, fazê-lo quebra a regra número 1 da comunidade de segurança:?? Não escreva sua própriacriptomoeda. ツ?

Como funcionam os algoritmos de hashing e o que há de especial no hashing de senhas? O que é preciso para um algoritmo se preparar para o uso generalizado da produção? A segurança através da obscuridade é uma boa ideia? Deixe-me ver. ツ?

Como funciona o hashing de senhas? ツ?

Antes de armazenar a senha de um usuário no banco de dados do seu aplicativo, você deve aplicar uma função de hash criptográfico a ela. (Você não está armazenando senhas em texto simples, certo? Bom. Só estou perguntando.) ツ?

Qualquer função de hash criptográfico converte uma entrada de comprimento arbitrário (também conhecida como “mensagem”) em uma saída de comprimento fixo (também conhecida como “hash”, “message digest”). Um?? funçãode hash criptográfico segura?? Deve ser:ツ?

  • Determinista: hashing a mesma entrada deve sempre renderizar a mesma saída. ツ?
  • Unidirecionária: gerar uma mensagem deentrada com base em uma determinada saída deve ser inviável. ツ?
  • Resistentea duas mensagens deentrada que hash para a mesma saída também deve ser inviável. ツ?
  • Altamente randomizado: uma pequena mudança na entrada deve levar a uma mudança significativa e não corrigida na produção (também conhecida como “efeito avalanche”). Sem essa propriedade, a aplicação de métodos de criptoanálise permitirá fazer previsões sobre a entrada com base na saída. ツ?

Agora, há hashing criptográfico geral, e então há hashing de senha que é um pouco especial. ツ?

As funções de hash criptográficas padrão são projetadas para serem rápidas, e quando você está hashing senhas, torna-se um problema.?? Ohashing de senha deve ser lento. ?? Você quer tornar o mais difícil possível para o invasor aplicar ataques de força bruta a senhas em seu banco de dados caso ele vaze. É por isso que você quer fazer senhas hash computacionalmente caras. Quão caro? Bem, é uma troca entre conveniência para seus usuários legítimos quando eles validam suas senhas e dificultam ataques de força bruta para o invasor. ツ?

Para tornar o hash computacionalmente caro, um tipo especial de funções é comumente usado:?? principaisfunções de derivação?? (KDFs). Sob o capô, os KDFs invocam funções de hashing, mas adicionam um sal aleatório antes do hashing, e depois aplicam inúmeras (geralmente milhares ou dezenas de milhares) iterações de hashing. Idealmente, eles fazem ataques de força bruta tanto intensivos em CPU quanto em memória intensiva. ツ?

Uma função de derivação chave produz uma chave derivada de uma tecla base e outros parâmetros. Em uma função de derivação de chave baseada em senha, a chave base é uma senha e os outros parâmetros são um valor de sal e uma contagem de iteraçãoツ? (RFC 2898: Especificação de criptografia baseada em senha Versão 2.0).

Em discussões de hashing de senha, os termos “função hash” (como MD5 ou SHA-1) e “função de derivação de teclas” (como PBKDF2 ou Argon2) são frequentemente usados de forma intercambiável, embora tecnicamente não sejam os mesmos. ツ?

Por que você não deveria escrever seu próprio algoritmo de hashing de senha? ツ?

Ambos escrevendo um algoritmo de hash personalizado e criando sua própria implementação de um algoritmo bem conhecido são ideias ruins. Por quê? ツ?

Você provavelmente não tem as habilidades. Vamos encarar: criptografia é difícil, e bagunçar um algoritmo ou implementação é fácil, mesmo para os profissionais. Você deve ir para a criação de seu próprio hashing de senha, algumas das coisas que você precisa cuidar incluem:ツ?

  • Garantindo?? resistênciapré-imagem?? Para evitar o cálculo da entrada com base na saída de hash. ツ?
  • Garantindo?? altaresistência à colisão?? Para evitar encontrar duas entradas que hash para a mesma saída. ツ?
  • Randomização e?? Efeitoavalanche?? Para garantir que os atacantes não possam encontrar facilmente padrões de hashing e correlações entre a entrada e a saída. ツ?
  • Resiliência a uma ampla gama deツ? ataques de canal lateral?? (ou seja, ataques baseados em detalhes de implementação de algoritmos e examinando os efeitos físicos causados pela invocação da implementação), como ataques de cronometragem e ataques de cache. ツ?
  • Minimizando quaisquer ganhos de eficiência alcançáveis pelos atacantes através do uso de?? Hardwareotimizado para rachaduras?? Como ASIC, FPGA e GPUs. ツ?

Isso é muito no seu prato – ainda mais dado isso?? Vocênão terá acesso a testadores qualificados?? Da comunidade de criptografia para ajudá-lo a encontrar vulnerabilidades (inevitáveis). ツ?

Você provavelmente vai querer depender de segredo e obscuridade?? Mantendo seu algoritmo privado. Fazê-lo quebra a doutrina fundamental da criptografia conhecida como ツ? Kerckhoff estáツ?princípio:?? “um criptoistema deve ser seguro mesmo que tudo sobre o ツ? sistema, exceto a chave, é o conhecimento público. ?? A obscuridade pode fornecer uma vantagem de curto prazo, mas confiar nela a longo prazo é uma má prática:ツ?

  • Hiding vulnerabilities prevents revealing and repairing them as part of an openツ?discussion andツ?increases the probability of exploits.ツ?
  • If your password database ever leaks, there’s a good chance that the source code of your application will leak along with it, and as soon as your untested algorithm becomes known to the attacker, they’ll have an easy time cracking it.ツ?

You’ll put sensitive user data at risk. Leaking sensitive user data is one of the worst things that can happen to a business. This is something that instantly undermines trust, turns customers away, and is very expensive to remediate. Some companies and lots of developers are prone to the Not Invented Here fallacy, but password hashing is probably the worst thing you can choose to re-implement.ツ?

Most importantly,??ッyou won’t know when your algorithm gets broken.ツ?

Established algorithms and implementations benefit from??ッyears of testing and polishing??ッby large communities of cryptography experts who help reveal and fix vulnerabilities without any malicious intent.ツ?

Uma vez que seu próprio algoritmo e/ou implementação não estará disponível para ninguém com boa vontade, os atacantes serão a única categoria de pessoas dispostas a quebrá-lo. Uma vez que eles fazem isso, eles não vão te dar uma cabeça–paracima; ツ você só saberá quando os dados confidenciais de seus usuários sãoツ? comprometido,ツ?e seu negócio está em sérios problemas. ツ?

Mas e se você? Realmente?? Quer aumentar sua criptografia e aprender fazendo? ツ?

Isso é ótimo! Vá em frente e pratique. Leia as implementações de referência dos algoritmos existentes, brinque com suas próprias implementações, procure conselhos na comunidade e tenha um ótimo momento aprendendo algo novo e emocionante! ツ?

Só não use o que escreveu em suas aplicações de produção. ツ?

Para saber mais, leia nosso decodificador de vulnerabilidade em criptomoedas inseguras.ツ?

FONTE: SECURITY BOULEVARD

POSTS RELACIONADOS