Hashing explicado: por que é sua melhor aposta proteger as senhas armazenadas

Views: 1231

O que é hashing?

Hashing é um processo criptográfico que pode ser usado para validar a autenticidade e integridade de vários tipos de entrada. É amplamente utilizado em sistemas de autenticação para evitar o armazenamento de senhas em texto simples em bancos de dados, mas também é utilizado para validar arquivos, documentos e outros tipos de dados. O uso incorreto de funções de hashing pode levar a sérias violações de dados, mas não usar o hashing para proteger dados confidenciais é ainda pior.

Hashing versus criptografia

O hash é uma função criptográfica unilateral, enquanto a criptografia foi projetada para funcionar nos dois sentidos. Os algoritmos de criptografia pegam a entrada e uma chave secreta e geram uma saída de aparência aleatória chamada de texto cifrado. Esta operação é reversível. Qualquer pessoa que conheça ou obtenha a chave secreta pode descriptografar o texto cifrado e ler a entrada original.

As funções de hash não são reversíveis. A saída de uma função de hashing é uma string de caracteres de comprimento fixo chamada de valor hash, resumo ou simplesmente hash. Eles não devem ser necessariamente mantidos em segredo, porque não podem ser convertidos de volta aos seus valores originais. No entanto, uma propriedade importante de uma função de hash é que, quando o hash é feito, uma entrada exclusiva deve sempre resultar no mesmo valor de hash. Se duas entradas diferentes podem ter o mesmo valor de hash, isso é chamado de colisão e, dependendo de quão fácil é computacionalmente encontrar tal colisão, a função de hash pode ser considerada quebrada do ponto de vista da segurança.

O hash é quase sempre preferível à criptografia ao armazenar senhas em bancos de dados porque, no caso de um comprometimento, os invasores não obterão acesso às senhas em texto simples e não há razão para o site saber a senha em texto simples do usuário. Se você já recebeu de várias empresas avisos de que “nossos representantes nunca pedirão sua senha”, isso é parte do motivo pelo qual eles não o fazem: eles não precisam fazer isso porque não têm sua senha. Eles têm uma representação criptográfica irreversível de sua senha – seu valor hash.https://imasdk.googleapis.com/js/core/bridge3.435.0_en.html#goog_753507041Volume 0%

Dito isso, as empresas que sofrem violações de segurança costumam usar indevidamente o termo “criptografia” em suas divulgações públicas e avisam aos clientes que suas senhas estão seguras porque foram criptografadas. Provavelmente, isso ocorre porque o público em geral não está muito familiarizado com o significado de hashing, então seus departamentos de RP desejam evitar confusão. Isso torna difícil para observadores externos avaliarem os riscos associados a uma violação, no entanto, porque se as senhas fossem realmente criptografadas, o risco seria maior do que se fossem criptografadas e a próxima pergunta deveria ser: A chave de criptografia também foi comprometida? Casos de criptografia sendo usada em vez de hash para senhas acontecem.

Em 2013, a Adobe sofreu uma violação de segurança que resultou no roubo de informações de milhões de contas, incluindo senhas criptografadas. A Adobe atualizou a maioria de seus sistemas para usar hashing, mas o servidor violado era um backup que a empresa planejava desativar e que armazenava senhas criptografadas com a cifra Triple DES no modo ECB. Embora os invasores não tenham obtido a chave de descriptografia, o uso dessa cifra no modo ECB é conhecido por vazar informações, permitindo que ataques de força bruta recuperem um número significativo de senhas.

“A criptografia só deve ser usada em casos extremos onde é necessário obter a senha original”, disse o Open Web Application Security Project (OWASP) em suas recomendações para armazenamento de senhas . “Alguns exemplos de onde isso pode ser necessário são: se o aplicativo precisar usar a senha para autenticar em um sistema legado externo que não oferece suporte a SSO [ou] se for necessário recuperar caracteres individuais da senha. A capacidade de descriptografar senhas representa um sério risco de segurança, por isso deve ser totalmente avaliado o risco. Sempre que possível, uma arquitetura alternativa deve ser usada para evitar a necessidade de armazenar senhas em uma forma criptografada. “

Como o hashing é usado na autenticação

Em sistemas de autenticação, quando os usuários criam uma nova conta e inserem a senha escolhida, o código do aplicativo passa essa senha por meio de uma função de hashing e armazena o resultado no banco de dados. Quando o usuário deseja se autenticar posteriormente, o processo é repetido e o resultado é comparado ao valor do banco de dados. Se for uma correspondência, o usuário forneceu a senha correta.

Se o usuário esquecer sua senha, o processo de recuperação de senha envolve a validação de sua identidade – geralmente comprovando a propriedade do e-mail que foi usado para criar uma conta clicando em um link de redefinição de senha exclusivo enviado por e-mail – e permitindo que o usuário defina um nova senha e, portanto, um novo hash de senha no banco de dados. Se o processo de recuperação de senha resultar no envio de sua senha antiga ao usuário por e-mail ou na exibição no navegador, a implementação não é segura e as melhores práticas de segurança não foram seguidas.

Dito isso, mesmo se o hash for usado, os desenvolvedores podem cometer erros de implementação, por exemplo, usando uma função de hash que é sabidamente insegura e vulnerável a ataques de cracking de força bruta. Exemplos de esquemas de hashing que costumavam ser muito populares, mas foram descontinuados, são MD5 e SHA-1.

Desenvolvido em 1991, o MD5 foi a função de hashing de fato por muito tempo, mesmo depois que os criptoanalistas mostraram que ele é teoricamente inseguro. Infelizmente, o MD5 ainda é amplamente usado hoje em aplicativos antigos ou por desenvolvedores que não entendem de segurança. O primeiro ataque de colisão parcial foi teorizado em 1996 e uma colisão total foi demonstrada em 2004. Hoje, as colisões MD5 podem ser encontradas em segundos em um computador doméstico normal e o algoritmo é extremamente vulnerável a ataques de força bruta.

SHA-1 (Secure Hash Algorithm 1) foi projetado pela NSA em 1995 e era um padrão NIST recomendado. A função é conhecida por ser insegura contra invasores bem financiados com acesso ao poder da computação em nuvem desde 2005. Em 2017, pesquisadores de segurança do Centrum Wiskunde e Informatica (CWI) na Holanda, Nanyang Technological University (NTU) em Cingapura e Inria em A França, trabalhando com o Google, provou ser uma colisão prática contra o SHA-1 ao produzir dois arquivos PDF diferentes com a mesma assinatura SHA-1. SHA-1 foi descontinuado para certificados TLS e outros usos, mas ainda é amplamente usado em dispositivos e sistemas mais antigos para uma variedade de finalidades, incluindo a validação de assinaturas de arquivo em repositórios de código, atualizações de software e muito mais.

Para hashing e armazenamento de senha, um rascunho recente da IETFrecomenda o uso de Argon2 (o vencedor da competição de hash de senha de 2015), Bcrypt, Scrypt ou PBKDF2. No entanto, o hash envolve mais do que apenas o algoritmo usado. Por exemplo, um comprimento mínimo de senha de oito caracteres também é importante porque torna os ataques de força bruta que dependem de ataques de dicionário – listas de senhas comuns de outras violações de dados – muito mais difíceis.

Cada função hash também pode ser implementada de forma que várias iterações, ou passagens, do algoritmo de hash sejam executadas para cada senha. Isso também é conhecido como fator de trabalho e seu objetivo é tornar o resultado computacionalmente mais intensivo para trincar usando métodos de força bruta. Embora um fator de trabalho mais alto aumente a segurança, ele também torna cada operação de hash mais intensiva e demorada em termos de computação, porque o algoritmo é executado várias vezes.

“Não existe uma regra de ouro para o fator de trabalho ideal – isso dependerá do desempenho do servidor e do número de usuários no aplicativo”, disse o OWASP em suas recomendações. “Determinar o fator de trabalho ideal exigirá experimentação no (s) servidor (es) específico (s) usado (s) pelo aplicativo. Como regra geral, o cálculo de um hash deve levar menos de um segundo, embora em sites de tráfego mais alto deva ser significativamente menor que isso.”

Sal e pimenta

Outra prática recomendada para o armazenamento seguro de senhas é combinar cada senha com uma sequência de caracteres gerada aleatoriamente, chamada de “sal” e, em seguida, fazer o hash do resultado. O salt, que deve ser único para cada usuário e senha, é então armazenado junto com o hash.

Salting senhas torna certos tipos de ataque muito mais difíceis ou impossíveis de executar. Por exemplo, os invasores podem pré-computar hashes para um grande número de combinações de senha e, em seguida, armazená-los em um banco de dados conhecido como rainbow table. Mais tarde, quando encontrarem um hash de senha que vazou, eles podem apenas realizar uma pesquisa no banco de dados para ver se ele corresponde a algum dos hashes pré-calculados. Como as senhas de sal também mudam o hash resultante, esses ataques se tornam ineficientes.

Salting também evita que invasores descubram senhas duplicadas em um banco de dados. Mesmo se dois ou mais usuários escolherem a mesma senha, o servidor gerará sais diferentes para eles e os hashes resultantes serão diferentes. A recomendação é que os sais tenham pelo menos 16 caracteres, o que aumenta significativamente a complexidade e o comprimento das strings de texto simples que precisam ser quebradas usando métodos de força bruta intensivos em computação.

Para adicionar outra camada de segurança, além dos sais, os desenvolvedores também podem combinar todas as senhas com uma string gerada aleatoriamente de pelo menos 32 caracteres chamada pimenta. Ao contrário de um salt, que é único para cada senha, o pepper é o mesmo para todas as senhas, mas não deve ser armazenado dentro do banco de dados. O objetivo da pimenta é dificultar que os invasores quebrem os hashes, mesmo quando obtêm o banco de dados completo do aplicativo, incluindo os sais.

A pimenta pode ser armazenada em um arquivo de configuração de aplicativo que é protegido com as permissões apropriadas do sistema de arquivos ou em um local mais seguro como um módulo de segurança de hardware (HSM).

“Uma abordagem alternativa é fazer o hash das senhas como de costume e, em seguida, criptografar os hashes com uma chave de criptografia simétrica antes de armazená-los no banco de dados, com a chave atuando como a pimenta”, disse OWASP. “Isso evita alguns dos problemas com a abordagem tradicional de apimentar e permite uma rotação muito mais fácil da pimenta se houver suspeita de que ela esteja comprometida.”

Atualizando hashes

Os aplicativos que usam um algoritmo de hash inseguro ou fraco devem ser migrados para funções de hash modernas. Uma maneira de fazer isso poderia ser usar os hashes antigos como entrada para o novo algoritmo de hash, essencialmente re-hash dos hashes antigos. No entanto, embora isso resolva o problema imediato, torna os hashes resultantes mais vulneráveis ​​a cracking do que se fossem gerados diretamente da entrada original do usuário.

Por isso, é recomendável que os hashes sejam gerados novamente com o novo algoritmo moderno na próxima vez que os usuários fizerem login e inserirem suas senhas. Se o usuário não estiver ativo e não fizer login por um determinado período de tempo, sua senha poderá ser redefinida e ele poderá ser forçado a redefinir a senha quando fizer logon na próxima vez.

Finalmente, a regra de ouro para todos os desenvolvedores ao lidar com criptografia : não crie seus próprios algoritmos personalizados. A criptografia é muito difícil e os algoritmos que são padronizados e amplamente usados ​​são geralmente o resultado de esforços de pesquisa acadêmica que estão sujeitos à revisão por pares de outros criptógrafos e criptanalistas.

FONTE: CSO ONLINE