답변:
먼저 중요한 용어 :
해싱 -문자열을 가져 와서 원래 문자열로 되돌릴 수없는 일련의 문자를 생성하는 작업입니다.
대칭 암호화 -(보통 '암호화'라고 함)-문자열을 가져 와서 암호화 한 동일한 암호화 키를 사용하여 원래 문자열로 해독 할 수 있는 일련의 문자를 생성하는작업입니다.
레인보우 테이블 -특정 해싱 알고리즘으로 해시 된 모든 변형 문자를 포함하는 조회 테이블입니다.
소금 -이 해시되기 전에 원래 문자열에 추가 알려진 임의의 문자열.
.NET Framework의 경우 Bcrypt에는 아직 확인 된 참조 구현 이 없습니다 . 기존 구현에 심각한 결함이 있는지 알 수있는 방법이 없기 때문에 중요합니다. 여기서 .NET 용 BCrypt 구현을 얻을 수 있습니다 . 암호화가 좋은 구현인지 나쁜 구현인지에 대해 충분히 알지 못합니다. 암호화는 매우 깊은 분야입니다. 자체 암호화 알고리즘을 구축하려고 시도하지 마십시오 . 진심으로.
자체 비밀번호 보안 (sigh)을 구현하려는 경우 몇 가지 작업을 수행해야합니다.
불행히도,이 모든 작업을 수행하더라도 결정된 해커는 여전히 암호를 알아낼 수 있으므로 시간이 오래 걸립니다. 그것이 당신의 주요 적입니다 : Time .
이 필요하기 때문에 bcrypt 알고리즘이 작동 다섯 개 해시에 이상 크기의 MD5보다 비밀번호를 주문 ; (그리고 여전히 AES 또는 SHA-512보다 훨씬 깁니다). 해커는 레인보우 테이블을 만들어 암호를 조회하는 데 더 많은 시간을 소비하므로 암호가 해킹 당할 위험이 훨씬 적습니다.
암호를 소금에 절이고 해싱하고 각 소금이 다르면 잠재적 해커는 소금의 각 변형에 대해 무지개 테이블을 만들어야합니다 . 단 하나의 소금에 절인 + 해시 암호에 무지개 테이블이 있어야합니다. 즉, 백만 명의 사용자가있는 경우 해커는 백만 개의 레인보우 테이블을 생성해야합니다. 모든 사용자에게 동일한 소금을 사용하는 경우 해커는 시스템을 성공적으로 해킹하기 위해 1 개의 레인보우 테이블 만 생성하면됩니다.
암호를 염두에 두지 않으면 공격자가해야 할 일은 모든 구현 (AES, SHA-512, MD5)에 대해 기존 Rainbow 테이블을 가져와 해시와 일치하는지 확인하는 것입니다. 이 작업 은 이미 완료되었으므로 공격자 가 이러한 레인보우 테이블 자체를 계산할 필요가 없습니다 .
이 모든 경우에도 훌륭한 보안 방법을 사용해야합니다 . 사이트에서 다른 공격 경로 (XSS, SQL 인젝션, CSRF 등 )를 성공적으로 사용할 수 있다면 암호 보안이 중요하지 않습니다. 논란의 여지가있는 말처럼 들리지만 생각해보십시오. SQL 주입 공격을 통해 모든 사용자 정보를 얻을 수 있거나 사용자가 XSS를 통해 쿠키를 제공 할 수 있다면 암호가 아무 문제가되지 않습니다. 보안은 입니다.
기타 자료 :
참고 : 다른 좋은 자료를 추천하십시오. 필자는 수십 명의 저자가 쓴 12 개의 기사를 읽었어야하지만 Jeff가하는 주제에 대해 글을 거의 쓰지 않았습니다. 기사를 찾을 때 수정하십시오.
당신은 사용해서는 안 .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 주석이 포함되어 있습니다.