BCrypt는 C #에서 사용하기에 좋은 해싱 알고리즘입니까? 어디서 찾을 수 있습니까? [닫은]


129

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

C #으로 프로그래밍하고 있으며 BCrypt에 대한 훌륭한 구현을 알고 있는지 궁금합니다. 이 페이지를 찾았 지만 실제로 가짜인지 아닌지는 모르겠습니다.

비밀번호 해싱 체계를 선택할 때 알아야 할 사항은 무엇입니까? BCrypt는 '좋은'구현입니까?

답변:


148

먼저 중요한 용어 :

해싱 -문자열을 가져 와서 원래 문자열로 되돌릴 수없는 일련의 문자를 생성하는 작업입니다.

대칭 암호화 -(보통 '암호화'라고 함)-문자열을 가져 와서 암호화 한 동일한 암호화 키를 사용하여 원래 문자열로 해독 할 수 있는 일련의 문자를 생성하는작업입니다.

레인보우 테이블 -특정 해싱 알고리즘으로 해시 된 모든 변형 문자를 포함하는 조회 테이블입니다.

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

.NET Framework의 경우 Bcrypt에는 아직 확인 된 참조 구현 이 없습니다 . 기존 구현에 심각한 결함이 있는지 알 수있는 방법이 없기 때문에 중요합니다. 여기서 .NET 용 BCrypt 구현을 얻을 수 있습니다 . 암호화가 좋은 구현인지 나쁜 구현인지에 대해 충분히 알지 못합니다. 암호화는 매우 깊은 분야입니다. 자체 암호화 알고리즘을 구축하려고 시도하지 마십시오 . 진심으로.

자체 비밀번호 보안 (sigh)을 구현하려는 경우 몇 가지 작업을 수행해야합니다.

  1. 비교적 안전한 해시 알고리즘을 사용하십시오 .
  2. 해시되기 전에 각 암호에 소금을 바르십시오.
  3. 용도 각 암호를 독특하고 긴 소금 과 암호로 소금을 저장합니다.
  4. 강력한 암호가 필요합니다 .

불행히도,이 모든 작업을 수행하더라도 결정된 해커는 여전히 암호를 알아낼 수 있으므로 시간이 오래 걸립니다. 그것이 당신의 주요 적입니다 : Time .

이 필요하기 때문에 bcrypt 알고리즘이 작동 다섯 개 해시에 이상 크기의 MD5보다 비밀번호를 주문 ; (그리고 여전히 AES 또는 SHA-512보다 훨씬 깁니다). 해커는 레인보우 테이블을 만들어 암호를 조회하는 데 더 많은 시간을 소비하므로 암호가 해킹 당할 위험이 훨씬 적습니다.

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

암호를 염두에 두지 않으면 공격자가해야 할 일은 모든 구현 (AES, SHA-512, MD5)에 대해 기존 Rainbow 테이블을 가져와 해시와 일치하는지 확인하는 것입니다. 이 작업 은 이미 완료되었으므로 공격자 가 이러한 레인보우 테이블 자체를 계산할 필요가 없습니다 .

이 모든 경우에도 훌륭한 보안 방법을 사용해야합니다 . 사이트에서 다른 공격 경로 (XSS, SQL 인젝션, CSRF )를 성공적으로 사용할 수 있다면 암호 보안이 중요하지 않습니다. 논란의 여지가있는 말처럼 들리지만 생각해보십시오. SQL 주입 공격을 통해 모든 사용자 정보를 얻을 수 있거나 사용자가 XSS를 통해 쿠키를 제공 할 수 있다면 암호가 아무 문제가되지 않습니다. 보안은 입니다.

기타 자료 :

  1. Jeff Atwood : .NET 암호화 단순화 (해싱 개요에 적합)
  2. Jeff Atwood : 방금 당신으로 로그인했습니다
  3. Jeff Atwood : 암호를 잘못 저장했을 가능성이 있습니다
  4. 제프 애트우드 : 스피드 해싱

참고 : 다른 좋은 자료를 추천하십시오. 필자는 수십 명의 저자가 쓴 12 개의 기사를 읽었어야하지만 Jeff가하는 주제에 대해 글을 거의 쓰지 않았습니다. 기사를 찾을 때 수정하십시오.


아마 당신의 소금 단락에 소금을 무작위로 선택해야한다고 추가하십시오
Jacco

2
@Jacco Good call이 추가되었습니다. 그렇게 중요하지는 않지만. 소금에 대한 로그인 타임 스탬프를 간단히 사용할 수 있습니다. 차이점은 공격자가 각 소금에 대해 레인보우 테이블을 다시 계산해야한다는 것입니다. 그것이 무작위로 선택되는 것이 아니라 어렵게 만드는 것입니다. 무작위로 만들면 다른 난독 화 계층이 추가되지만 공격자가 데이터베이스를 볼 수있게되면 쓸모가 없습니다.
George Stocker

3
실제로는 소금이 비밀 일 필요는 없으며 각 인스턴스마다 고유해야합니다. (전세계에서와 같이) 고유 한 것은 불가능하기 때문에 랜덤이 차선책입니다. 또한 엔트로피가 충분하지 않기 때문에 타임 스탬프는 좋은 소금 이 아닙니다.
Jacco

7
"XSS 나 SQL 인젝션을 성공적으로 사용할 수 있다면 좋은 암호 보안은 중요하지 않습니다."라는 진술에 문제가 있습니다. 반대로 XSS 나 SQL을 통해 사이트를 성공적으로 주입 할 수 있다면 우수한 암호 보안이 더욱 중요합니다. 여기서 핵심은 "심층 방어"입니다. 응용 프로그램의 모든 계층에서 실질적인 보안을 강화해야합니다.
jammycakes 12

2
@jammycakes 절대적으로; 내 요점을 잃어 버렸다 : '이봐, 우리는 암호를 해시하고 소금을 친다.
George Stocker

74

당신은 사용해서는 안 .NET에서 BCrypt을. 당신은 사용해야합니다 내장 .NET 프레임 워크 구현과 같이 PBKDF2을. NIST가 권장 하는 알고리즘 과 함께 .NET에서 유일하게 무료로 사용할 수있는 암호화 검증 된 구현입니다 .

StackId는 이전에 BCrypt를 사용했고 바로이 이유로 PBKDF2로 옮겼습니다.

궁금한 점은 PBKDF2로 비밀번호를 해싱하는 것입니다. 관련 코드는 몇 개의 간접 레이어를 통해 여기에 있습니다 ( http://code.google.com/p/stackid/source/browse/OpenIdProvider/Current.cs#1135 ). 초기 반복에서는 BCrypt를 사용했습니다. 그러나 BCrypt는 구현을 검증해야합니다 (작은 사업자는 아님). PBKDF2는 .NET 프레임 워크에 내장되어 있으므로 PBKDF2로 옮겨졌습니다.

Kevin Montrose, 2011 년 5 월 27 일

(깃 허브에서 업데이트 된 링크)

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

.NET의 bcrypt 구현이 확인되지 않았습니다. 확인되지 않은 암호화 구현을 사용하면 암호화 된 데이터에 백도어를 허용하거나 의도하지 않은 구현 결함으로 인해 의도적으로 악의적 인 결함이 없는지 확실하게 확신 할 수 없습니다.

2014 년 편집 : 검증 된 암호화 알고리즘을 사용해야하는 필요성에 대해 의문을 가진 사람 은 OpenSSL에서 악용 된 하트 블 해킹으로 인한 폐허를 살펴보십시오 . 이는 검증되지 않은 구현을 사용하는 비용입니다. 누구든지 서버의 전체 메모리 내용을 읽을 수 있음을 알 때까지는 안전합니다.

Heartbleed를 도입 한 변경 사항의 저자 인 Robin Seggelmann은 자신이 "길이를 포함하는 변수의 유효성 검사를 놓치다"고 결함이있는 구현을 제출하려는 의도를 거부했다고 밝혔다. Heartbleed의 공개에 이어 Seggelmann은 OpenSSL이 충분한 사람들에 의해 검토되지 않았다고 언급하면서 두 번째 측면에 중점을 둘 것을 제안했습니다.

이것은 검증되지 않은 구현의 정의입니다. 가장 작은 결함이라도 전체 보안을 손상시킬 수 있습니다.

2015 년 편집 : 추천 기반 언어를 제거하고 절대 값으로 대체했습니다. 후손에 대한 원본 Kevin Montrose 주석이 포함되어 있습니다.


25
"[우리는 PBKDF2가 .NET 프레임 워크에 내장되어 있으므로 BCrypt는 구현을 확인해야합니다." 이 의견은 알고리즘 이 더 낫다고 말하는 것은 아니며 SE Dev Team은 내장 PBKDF2 구현 이 외부 라이브러리 (최종적으로 판단 호출)보다 더 신뢰할 수 있다고 간주합니다 .
Piskvor는

3
@ Piskvor 내 답변을 업데이트했습니다. 이것은 SO 팀이 안전하다고 생각하는 것이 아니라 본질적으로 입증 된 안전 또는 희망적으로 안전한 사이의 판단을 요구합니다. 암호에 관한 후자는 용납 할 수 없습니다.
Chris Marisic

6
SO가 모든 bcrypt 해시 비밀번호를 새 해시로 어떻게 마이그레이션했는지 궁금합니다. 새로운 알고리즘을 사용하여 해시하기 위해 원시 비밀번호가 필요하지 않습니까?
Dharmendar Kumar 'DK'1

8
@DK 나는 당신이 그들에게 자신의 암호를 재설정하도록 요구해야한다고 생각하지 않습니다. 다음에 로그인하면 (일반 텍스트 비밀번호를 제공하는) 로그인 할 수 있습니다.
Matt Kocaj

12
이것은 좋지 않은 조언이며 그것이 너무 많은 공언을 가지고 있다는 사실에 놀랐습니다. 관리되는 언어로 BCrypt 구현을 확인하는 것은 C에서 전체 SSL 구현과 같은 것을 확인하는 것보다 훨씬 간단합니다. Heartbleed는 전혀 관련이 없습니다. 해시 동등성 검사에 문제를 일으키는 PHP 유형과 같은 것을 언급하는 것이 좋습니다. 또한 실제적인 의미에서 대부분 적합하지만 PBKDF2는 암호 해싱 알고리즘이 아닌 KDF 인 반면 BCrypt가 더 적합합니다. 어쨌든 요즘 Argon2를 사용하는 것이 훨씬 더 합리적입니다. 잘 테스트 된 C # 라이브러리가 있습니다
다항식
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.