Bcrypt é um bom algoritmo de hash para usar em C #? Onde posso encontrá-lo? [fechadas]

Question

Eu li que quando hashing uma senha, muitos programadores recomendo usar o algoritmo bcrypt.

Estou programando em C # e está querendo saber se alguém sabe de uma boa implementação de bcrypt? Eu encontrei este página , mas eu realmente não sei se é falsa ou não.

O que eu deveria estar ciente de quando se escolhe um esquema de senha hashing? É bcrypt um 'bom' implementação?

Answer 1

Em primeiro lugar, alguns termos que são importantes:

Hashing - O ato de tomar uma corda e produzindo um sequência de caracteres que não pode ser revertida para a string original.

Symmetric Encryption - (Normalmente apenas referido como 'criptografia') -. o ato de tomar uma corda e produzindo uma sequência de caracteres que pode ser descriptografado ao string original através do uso da mesma chave de criptografia que encriptado it

Tabela do arco-íris - uma tabela de pesquisa que contém todas as variações de caracteres hash em um algoritmo específico hashing.

Sal - uma seqüência aleatória conhecido anexado para a cadeia original antes de ser hash.

Para o .NET Framework, Bcrypt ainda não tem um verified implementação de referência. Isto é importante porque não há nenhuma maneira de saber se há falhas graves em uma implementação existente. Você pode obter uma implementação de bcrypt for .NET aqui . Eu não sei o suficiente sobre criptografia para dizer se é uma boa ou má aplicação. A criptografia é um campo muito profundo. Não tente construir o seu próprio algoritmo de criptografia . Seriamente.

Se você estiver indo para implementar sua própria senha de segurança (suspiro), então você precisa fazer várias coisas:

1. Use a relativamente seguro algoritmo de hash .
2. Salt cada senha antes de ser hash.
3. Use a sal única e longa para cada senha e armazenar o sal com a senha.
4. Exigir senhas fortes .

Infelizmente, mesmo se você fizer tudo isso, um hacker determinado ainda pode potencialmente descobrir as senhas, seria apenas levá-lo muito tempo. Esse é o seu principal inimigo:. Tempo

O bcrypt algoritmo funciona porque leva de cinco ordens de magnitude mais tempo para hash de uma senha do que MD5 ; (E ainda muito mais do que AES ou SHA-512). Isso força o hacker que gastar muito mais tempo para criar uma tabela de arco-íris para procurar suas senhas, tornando muito menos provável que suas senhas estará em perigo de ser cortado.

Se você está salga e hash de suas senhas, e cada sal é diferente, em seguida, um hacker em potencial teria que criar uma tabela de arco-íris para cada variação de sal , só para ter uma tabela de arco-íris por um salgado + hash de senha. Isso significa que se você tem 1 milhão de usuários, um hacker tem de gerar 1 milhão de tabelas do arco-íris. Se você estiver usando o mesmo sal para todos os usuários, em seguida, o hacker só tem de gerar a tabela 1 do arco-íris para hackear seu sistema com sucesso.

Se você não está salgando suas senhas, então tudo o que um atacante tem que fazer é puxar para cima uma tabela do arco-íris existente para cada implementação lá fora (AES, SHA-512, MD5) e apenas ver se um corresponde ao hash. Este já foi feito , um atacante não precisa calcular-se estas tabelas do arco-íris .

Mesmo com tudo isso, você tem que estar usando boas práticas de segurança Se eles podem usar com sucesso um outro vetor de ataque (XSS, SQL Injection, CSRF, et al ) em seu site, uma boa segurança senha não importa que soa como uma declaração polêmica, mas pensar nisso.: Se eu conseguir todas as informações o usuário através de um ataque de injeção SQL, ou eu posso obter seus usuários para me dar os seus cookies através de XSS, então não importa o quão boa a sua senha de segurança é .

Outros recursos:

1. Jeff Atwood: .NET Encryption Simplificado (ótimo para uma visão geral de hashing)
2. Jeff Atwood: Eu só logado como você
3. Jeff Atwood: Você provavelmente está armazenando senhas incorretamente
4. Jeff Atwood: velocidade Hashing

Nota: Por favor, recomendar outros bons recursos. Eu já deve ter lido uma dúzia de artigos por dezenas de autores, mas poucos escrita tão claramente sobre o assunto como Jeff faz. Por favor edição em artigos como você encontrá-los.

Answer 2

Você não deve usar bcrypt em .NET. Você deve usar PBKDF2 como é com o construído na implementação .NET framework. É o único disponível livremente implementação criptograficamente verificada em .NET juntamente com sendo o algoritmo recomendado pelo NIST .

StackId usado anteriormente bcrypt e se mudou para PBKDF2 por isso mesmo:

Para os curiosos, estamos hash senhas com PBKDF2. código relavent é aqui ( http://code.google.com/p/ stackid / fonte / browse / OpenIdProvider / Current.cs # 1135 ), Através de algumas camadas de engano. Em uma iteração mais cedo, nós foram usando bcrypt; mas mudou-se para PBKDF2 como ele está embutido no .NET quadro, enquanto bcrypt nos obrigaria a verificar uma implementação (Sem pequena empresa).

Kevin Montrose, 27 de maio de 2011

(link atualizado no GitHub)

Editar: O significado de verified em termos de criptografia parece não ser facilmente compreendido, um meio de implementação verificados tem sido cryptographically comprovadas para ser implementado sem erros. O custo deste pode facilmente chegar a US $ 20.000 ou superior. Lembro-me isso quando eu estava fazendo uma pesquisa sobre OpenSSL e ler onde eles afirmaram que não tenham concluído todo o processo de verificação, mas se você precisar totalmente verificado que você pode apontar para o caminho certo para ele e custos mencionados associados. Certas exigências do governo incluem mandatos para algoritmos de criptografia verificadas.

As implementações bcrypt em .NET não foram verificadas. Usando uma implementação de criptografia não verificado que você não pode estar absolutamente certo de que não há qualquer falhas maliciosos intencionais nele como permitir que um backdoor no que é criptografada ou implementação não intencional falhas que resultam em dados cryptographically inseguros.

2014 edit: Para qualquer um que questionava a imperatividade de usar algorithims cryptopgraphical verificados olhar para a devastação que foi operada pelo heartbleed corte explorada em OpenSSL. Esse é o custo de usar uma implementação não verificado. É seguro .... até você descobrir que qualquer pessoa pode apenas ler todo o conteúdo da memória de seu servidor.

O autor da alteração que introduziu heartbleed, Robin Seggelmann, afirmou que ele "perdeu a validação de uma variável que contém um comprimento" e negou qualquer intenção de apresentar uma aplicação incorrecta. Após a divulgação do heartbleed, Seggelmann sugeriu focando o segundo aspecto, afirmando que OpenSSL não é revisto por pessoas suficientes.

Esta é a definição de uma implementação não verificado. Até mesmo o menor defeito pode resultar em paralisando toda a segurança.

2015 edit: Removido linguagem baseada recomendação e substituído com absolutos. Incorporado comentário Kevin Montrose original para a posteridade.