bcrypt는 c#에 사용할 좋은 해싱 알고리즘입니까? 어디에서 찾을 수 있습니까? [닫은

Question

비밀번호를 해싱 할 때 많은 프로그래머가 BCrypt 알고리즘을 사용하는 것이 좋습니다.

C#로 프로그래밍 중이며 BCRYPT에 대한 좋은 구현을 아는 사람이 궁금합니다. 나는 찾았다 이 페이지, 그러나 나는 그것이 가짜인지 아닌지는 정말로 모른다.

암호 해싱 체계를 선택할 때 무엇을 알아야합니까? Bcrypt는 '좋은'구현입니까?

Answer 1

첫째, 중요한 용어 :

해싱 - 문자열을 취하고 원래 문자열로 되돌릴 수없는 일련의 문자를 생성하는 행위.

대칭 암호화 - (보통 '암호화'라고 함) - 문자열을 취하고 일련의 문자를 생성하는 행위 ~할 수 있다 암호화 된 동일한 암호화 키를 사용하여 원래 문자열로 해독해야합니다.

무지개 테이블 - 특정 해싱 알고리즘에 해시 된 문자의 모든 변형이 포함 된 조회 테이블.

소금 - 해시되기 전에 알려진 임의의 문자열이 원래 문자열에 추가되었습니다.

.NET 프레임 워크의 경우 BCrypt는 아직 확인 참조 구현. 기존 구현에 심각한 결함이 있는지 알 수있는 방법이 없기 때문에 이것은 중요합니다. 구현을 얻을 수 있습니다 .NET 용 BCrypt는 여기를 참조하십시오. 암호화에 대해 충분히 잘 모르겠습니다. 암호화는 매우 깊은 분야입니다. 자신의 암호화 알고리즘을 구축하려고 시도하지 마십시오. 진지하게.

자신의 암호 보안 (한숨)을 구현하려면 몇 가지 작업을 수행해야합니다.

1. a 비교적 안전한 해시 알고리즘.
2. 해시하기 전에 각 비밀번호를 소금하십시오.
3. a 각 비밀번호에 대해 독특하고 긴 소금, 소금을 비밀번호로 보관하십시오.
4. 강력한 비밀번호가 필요합니다.

불행히도, 당신 이이 모든 일을하더라도, 결정된 해커는 여전히 비밀번호를 알아낼 수있을뿐만 아니라 그에게 오랜 시간이 걸릴 것입니다. 그것이 당신의 최고 적입니다 : 시간.

그만큼 bcrypt 알고리즘은 걸리기 때문에 작동합니다 다섯 MD5보다 암호를 해시하는 데 더 긴 순서; (그리고 여전히 AES 또는 SHA-512보다 훨씬 길다). 해커는 비밀번호를 조회하기 위해 무지개 테이블을 만들기 위해 더 많은 시간을 보내도록하여 암호가 해킹 당할 가능성이 훨씬 낮습니다.

비밀번호를 소금과 해시하면 각 소금이 다르면 그러면 잠재적 해커는 소금의 각 변형에 대해 무지개 테이블을 만들어야합니다., 단 하나의 소금에 절인+해시 암호를위한 무지개 테이블을 가지고 있습니다. 즉, 백만 명의 사용자가 있다면 해커는 백만 명의 무지개 테이블을 생성해야합니다. 모든 사용자에게 동일한 소금을 사용하는 경우 해커는 시스템을 성공적으로 해킹하기 위해 무지개 테이블 1 개만 생성하면됩니다.

비밀번호를 소금받지 않는다면 공격자가해야 할 모든 것이 모든 구현에 대한 기존 레인보우 테이블 (AES, SHA-512, MD5)을 풀고 해시와 일치하는지 확인하는 것입니다. 이것 이미 완료되었습니다, 공격자 이 무지개 테이블 자체를 계산할 필요는 없습니다.

이 모든 것만으로도 좋은 보안 관행을 사용해야합니다. 다른 공격 벡터 (XSS, SQL Injection, CSRF, ET. 알.) 귀하의 사이트에서 우수한 비밀번호 보안은 중요하지 않습니다. 그것은 논란의 여지가있는 진술처럼 들리지만 그것에 대해 생각하십시오. 그렇다면 비밀번호 보안이 얼마나 좋은지는 중요하지 않습니다..

기타 리소스 :

1. Jeff Atwood : .NET 암호화 단순화 (해싱에 대한 개요에 적합)
2. Jeff Atwood : 방금 당신처럼 로그인했습니다
3. Jeff Atwood : 아마도 암호를 잘못 저장하고있을 것입니다
4. Jeff Atwood : 속도 해싱

메모: 다른 좋은 자원을 추천하십시오. 나는 수십 명의 저자가 12 개의 기사를 읽어야했지만 Jeff와 같이 주제에 대해 명백히 글을 쓰는 사람은 거의 없습니다. 기사를 찾은대로 기사를 편집하십시오.

Answer 2

너 사용해서는 안됩니다 .NET의 bcrypt. 너 사용해야합니다 PBKDF2 내장 .NET Framework 구현과 함께. .NET에서의 유일하게 무료로 제공되는 암호화 적으로 확인 된 구현입니다. NIST가 권장하는 알고리즘.

Stackid는 이전에 bcrypt를 사용하고 바로 그 이유 때문에 PBKDF2로 옮겼습니다.

호기심 많은 사람들을 위해 PBKDF2로 암호를 해싱합니다. RELAVENT 코드는 여기에 있습니다 ( http://code.google.com/p/stackid/source/browse/openidprovider/current.cs#1135), 몇 층의 간접 층을 통해. 초기 반복에서 우리는 bcrypt를 사용하고있었습니다. 그러나 .NET 프레임 워크에 내장되어 PBKDF2로 이동 한 반면 BCrypt는 구현을 확인해야합니다 (소규모 사업은 없음).

Kevin Montrose, 2011 년 5 월 27 일

(Github에서 업데이트 된 링크)

편집하다: 그 의미 확인 암호화 용어에서 쉽게 이해되지 않는 것으로 보이며, 검증 된 구현은 오류없이 암호화 적으로 구현 된 것으로 입증되었음을 의미합니다. 이 비용은 쉽게 $ 20,000 이상에 도달 할 수 있습니다. 나는 OpenSSL에 대한 연구를 할 때 이것을 기억하고 그들이 전체 검증 프로세스를 완료하지 않았다고 언급 한 곳을 읽었지만, 당신이 그것들에 대한 올바른 경로를 지적하고 관련 비용을 언급 할 수 있음을 완전히 확인해야한다면 완전히 확인해야한다면. 특정 정부 요구 사항에는 검증 된 암호화 알고리즘에 대한 명령이 포함됩니다.

.NET의 BCrypt 구현은 확인되지 않았습니다. 검증되지 않은 암호화 구현을 사용하면 암호화 적으로 불안한 데이터를 초래하는 암호화 또는 의도하지 않은 구현 결함으로 백도어를 허용하는 것과 같은 의도적 인 악성 결함이 없다는 것을 절대 확신 할 수 없습니다.

2014 편집 : 검증 된 cryptopgraphical 알고리즘을 사용하는 명령에 의문을 제기 한 사람이라면 누구나 가슴이 아는 핵 OpenSSL에서 악용. 이는 검증되지 않은 구현을 사용하는 비용입니다. 안전합니다 .... 모든 사람이 서버의 전체 메모리 내용을 읽을 수 있다는 것을 알 때까지는 안전합니다.

Robin Seggelmann은 Heartbleed를 소개 한 변경의 저자는 "길이가 포함 된 변수를 검증하는 것을 놓친"그리고 결함이있는 구현을 제출하려는 의도를 거부했다고 말했습니다. Heartbleed의 공개에 이어 Seggelmann은 두 번째 측면에 집중할 것을 제안했으며, OpenSSL은 충분한 사람들이 검토하지 않는다고 진술했습니다.

이것은 검증되지 않은 구현의 정의입니다. 가장 작은 결함조차도 전체 보안을 무너 뜨릴 수 있습니다.

2015 편집 : 추천 기반 언어를 제거하고 절대로 대체했습니다. 후손에 대한 원래 Kevin Montrose 의견.