Mon. Oct 3rd, 2022

O que é hash?
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 de texto simples em bancos de dados, mas também é usado para validar arquivos, documentos e outros tipos de dados. O uso incorreto de funções de hash pode levar a graves violações de dados, mas não usar hash para proteger dados confidenciais em primeiro lugar é ainda pior.

Hash versus criptografia
O hash é uma função criptográfica unidirecional, enquanto a criptografia é projetada para funcionar nos dois sentidos. Os algoritmos de criptografia recebem entrada e uma chave secreta e geram uma saída de aparência aleatória chamada 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 hash é uma cadeia de caracteres de comprimento fixo chamada valor de hash, resumo ou simplesmente hash. Estes não são necessariamente mantidos em segredo porque não podem ser convertidos de volta em seus valores originais. No entanto, uma propriedade importante de uma função de hash é que, quando em hash, 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.

Hashing é quase sempre preferível à criptografia ao armazenar senhas dentro de bancos de dados porque, no caso de um comprometimento, os invasores não terão acesso às senhas de texto simples e não há razão para o site saber a senha de texto simples do usuário. Se você já recebeu esses avisos de que “nossos representantes nunca pedirão sua senha” de várias empresas, isso é parte do motivo pelo qual eles não o farão: eles não têm utilidade para isso porque não têm sua senha. Eles têm uma representação criptográfica irreversível de sua senha—seu valor de hash.

Dito isso, as empresas que sofrem violações de segurança geralmente usam mal o termo “criptografia” em suas divulgações públicas e informam aos clientes que suas senhas são seguras porque foram criptografadas. Isso provavelmente ocorre porque o público em geral não está muito familiarizado com o significado de hash, então seus departamentos de relações públicas querem evitar confusão. No entanto, torna difícil para observadores externos avaliar os riscos associados a uma violação, porque se as senhas foram realmente criptografadas, o risco é maior do que se elas fossem hash e a próxima pergunta deve 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 havia atualizado 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 deve ser usada apenas em casos extremos em que é 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 se autenticar em um sistema legado externo que não suporta 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 quanto ao risco. Sempre que possível, uma arquitetura alternativa deve ser usada para evitar a necessidade de armazenar senhas de forma criptografada.”

Como o hash é usado na autenticação
Nos 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 hash e armazena o resultado no banco de dados. Quando o usuário deseja 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 provando a propriedade do e-mail que foi usado para criar uma conta clicando em um link exclusivo de redefinição de senha 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 da senha antiga ao usuário por e-mail ou na exibição no navegador, a implementação é insegura e as práticas recomendadas de segurança não foram seguidas.

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

Desenvolvido em 1991, o MD5 foi a função de hash de fato por um longo tempo, mesmo depois que os criptoanalistas mostraram que é 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 completa foi demonstrada em 2004. Hoje, colisões MD5 podem ser encontradas em segundos em um computador doméstico comum 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. O SHA-1 foi preterido para certificados TLS e outros usos, mas ainda é amplamente usado em dispositivos e sistemas mais antigos para diversas finalidades, incluindo validação de assinaturas de arquivos em repositórios de código, atualizações de software e muito mais.

Para hash e armazenamento de senha, um rascunho recente do IETF recomenda o uso de Argon2 (o vencedor da Competição de Hashing de Senha de 2015), Bcrypt, Scrypt ou PBKDF2. No entanto, há mais no hashing 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 de hash também pode ser implementada para 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 quebrar 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 computacionalmente intensiva e mais longa 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 a 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 do 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 “salt” e, em seguida, fazer o hash do resultado. O sal, que deve ser exclusivo para cada usuário e senha, é armazenado junto com o hash.

Saltar 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 número muito grande de combinações de senhas e armazená-los em um banco de dados conhecido como tabela arco-íris. Mais tarde, quando eles encontram um hash de senha vazado, eles podem simplesmente realizar uma pesquisa no banco de dados para ver se ele corresponde a algum dos hashes pré-computados. Como as senhas salgadas também alteram o hash resultante, esses ataques se tornam ineficientes.

Saltar também impede que invasores descubram senhas duplicadas em um banco de dados. Mesmo que dois ou mais usuários tenham escolhido a mesma senha, o servidor gerou diferentes sais 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 computacionalmente intensivos.

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 hashes, mesmo quando obtêm o banco de dados completo do aplicativo, incluindo os sais.

O pepper pode ser armazenado em um arquivo de configuração do 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 pimenta”, disse o OWASP. “Isso evita alguns dos problemas com a abordagem tradicional de apimentar e permite uma rotação muito mais fácil da pimenta se acredita-se 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 pode ser usar os hashes antigos como entrada para o novo algoritmo de hash, essencialmente refazendo os hashes antigos. No entanto, embora isso resolva o problema imediato, torna os hashes resultantes mais vulneráveis ​​a rachaduras do que se fossem gerados diretamente da entrada original do usuário.

Por isso, é recomendável que os hashes sejam regenerados 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 login 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 padronizados e amplamente utilizados 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 criptoanalistas.

Leave a Reply

Your email address will not be published. Required fields are marked *