Eu li que, ao fazer o hash de uma senha, muitos programadores recomendam o uso do algoritmo BCrypt.
Estou programando em c # e gostaria de saber se alguém sabe de uma boa implementação para BCrypt? Encontrei esta página , mas realmente não sei se é falsa ou não.
O que devo saber ao escolher um esquema de hash de senha? O BCrypt é uma implementação 'boa'?
Respostas:
Primeiro, alguns termos que são importantes:
Hashing - O ato de pegar uma string e produzir uma sequência de caracteres que não podem ser revertidos para a string original.
Criptografia simétrica - (geralmente chamada de 'criptografia') - O ato de pegar uma string e produzir uma sequência de caracteres que podem ser descriptografados para a string original através do uso da mesma chave de criptografia que a criptografou.
Tabela Arco-Íris - uma tabela de pesquisa que contém todas as variações de caracteres com hash em um algoritmo de hash específico.
Salt - uma string aleatória conhecida anexada à string original antes de ser hash.
Para o .NET Framework, o Bcrypt ainda não possui uma implementação de referência verificada . Isso é importante porque não há como saber se há falhas sérias em uma implementação existente. Você pode obter uma implementação do BCrypt for .NET aqui . Não sei o suficiente sobre criptografia para dizer se é uma implementação boa ou ruim. A criptografia é um campo muito profundo. Não tente criar seu próprio algoritmo de criptografia . Seriamente.
Se você estiver implementando sua própria segurança de senha (suspiro), precisará fazer várias coisas:
Infelizmente, mesmo se você fizer tudo isso, um hacker determinado ainda pode descobrir as senhas, isso levaria muito tempo. Esse é o seu principal inimigo: o tempo .
O algoritmo bcrypt funciona porque são necessárias cinco ordens de magnitude mais para o hash de uma senha que o MD5 ; (e ainda muito mais longo que o AES ou o SHA-512). Isso força o hacker a gastar muito mais tempo para criar uma tabela de arco-íris para procurar suas senhas, tornando muito menos provável que suas senhas corram o risco de serem invadidas.
Se você estiver salgando e hash suas senhas e cada sal for diferente, um hacker em potencial precisará criar uma tabela arco-íris para cada variação de sal , apenas para ter uma tabela arco-íris para uma senha salgada + com hash. Isso significa que, se você possui 1 milhão de usuários, um hacker precisa gerar 1 milhão de tabelas arco-íris. Se você estiver usando o mesmo sal para todos os usuários, o hacker precisará gerar apenas 1 tabela arco-íris para invadir com êxito o seu sistema.
Se você não está salgando suas senhas, tudo o que um invasor precisa fazer é acessar uma tabela Rainbow existente para todas as implementações existentes (AES, SHA-512, MD5) e apenas verificar se uma delas corresponde ao hash. Isso já foi feito , um invasor não precisa calcular essas tabelas do Rainbow .
Mesmo com tudo isso, você deve usar boas práticas de segurança . Se eles puderem usar com êxito outro vetor de ataque (XSS, SQL Injection, CSRF, etc. ) em seu site, uma boa segurança de senha não importa. Parece uma declaração controversa, mas pense bem: se eu posso obter todas as informações do usuário por meio de um ataque de injeção de SQL, ou posso permitir que seus usuários me forneçam seus cookies através do XSS, não importa a qualidade da sua senha. segurança é .
Outros recursos:
Nota: Por favor, recomende outros bons recursos. Devo ter lido uma dúzia de artigos de dezenas de autores, mas poucos escrevem tão claramente sobre o assunto quanto Jeff. Edite os artigos à medida que os encontrar.
Você não deve usar o BCrypt no .NET. Você deve usar o PBKDF2 como está na implementação da estrutura .NET integrada. É a única implementação verificada criptograficamente disponível gratuitamente no .NET, além de ser o algoritmo recomendado pelo NIST .
O StackId usou o BCrypt anteriormente e mudou-se para PBKDF2 por esse mesmo motivo:
Para os curiosos, estamos usando hash de senhas com PBKDF2. O código relevante está aqui ( http://code.google.com/p/stackid/source/browse/OpenIdProvider/Current.cs#1135 ), através de algumas camadas indiretas. Em uma iteração anterior, estávamos usando o BCrypt; mas mudou-se para PBKDF2 à medida que é incorporado à estrutura .NET, enquanto o BCrypt exigiria que verificássemos uma implementação (não é uma tarefa pequena).
Kevin Montrose, 27 de maio de 2011
Edit: O significado de verificado em termos criptográficos parece não ser facilmente entendido, uma implementação verificada significa que foi criptograficamente comprovado que foi implementado sem erros. O custo disso pode facilmente chegar a US $ 20.000 ou mais. Lembro-me disso quando estava pesquisando sobre o OpenSSL e li onde eles declararam que não concluíram todo o processo de verificação, mas se você precisar verificar completamente, eles podem apontar o caminho certo e os custos mencionados. Alguns requisitos governamentais incluem mandatos para algoritmos de criptografia verificados.
As implementações de bcrypt no .NET não foram verificadas. Usando uma implementação de criptografia não verificada, você não pode ter certeza absoluta de que não há falhas maliciosas intencionais, como permitir uma backdoor no que é criptografado ou falhas de implementação não intencionais que resultam em dados criptograficamente inseguros.
Edição de 2014: Para quem questionou a imperatividade de usar algoritmos criptográficos verificados, observe a devastação causada pelo hack de coração explorado no OpenSSL. Esse é o custo do uso de uma implementação não verificada. É seguro .... até você descobrir que qualquer pessoa pode apenas ler todo o conteúdo da memória do seu servidor.
O autor da mudança que introduziu o Heartbleed, Robin Seggelmann, afirmou que "perdeu a validação de uma variável que contenha um comprimento" e negou qualquer intenção de enviar uma implementação falha. Após a divulgação da Heartbleed, Seggelmann sugeriu se concentrar no segundo aspecto, afirmando que o OpenSSL não é revisado por pessoas suficientes.
Esta é a definição de uma implementação não verificada. Mesmo o menor defeito pode resultar em uma paralisação de toda a segurança.
Edição de 2015: removido o idioma baseado em recomendações e substituído por absolutos. Comentário original incorporado de Kevin Montrose para a posteridade.