암호가 해시 값으로 저장된 암호 검색

암호가 해시 값으로 저장되어 있으면 사용자가 자신의 암호를 전자 메일로 보내도록 요청할 수 있습니까?암호가 해시 값으로 저장된 암호 검색

해시 값을 적절한 정보 (일반 정보 : &)로 일반 텍스트 값으로 변환 할 수있는 방법이 있습니까?

사용자가 두 사이트에 저장된 암호 해시 값이 같은 경우 두 사이트의 암호가 동일합니까?

출처

2009-06-18 Matt

비밀번호의 해시 만 저장하는 경우에는 아니요. 어쨌든, 제대로 소금에 절인 암호 해시 만 저장하면됩니다.

암호 재설정 메커니즘이 적절한 대안입니다.

출처

2009-06-18 16:09:53 Yoopergeek

+1 소금의 사용을 생각 나게하기 위해 ... –

소금의 올바른 사용에 대한 내 대답을 참조하십시오 ... 소금을 저장하는 것은 그것을 사용하는 목적을 무 찌릅니다. – jrista

+11

소금의 목적은 조회 테이블을 무효화하는 것이므로 가능한 많은 수의 암호를 해시하고 해시 값을 찾는 것은 불가능합니다. 그것은 소금을 비밀로 유지하는 것에 의존하지 않습니다. 또한, 당신이 그것을 저장하지 않으면 어떻게 도대체 비밀 번호를 확인? –

간단히 말해서, 아니오. 대부분의 해싱 알고리즘을 사용하면 동일한 출력으로 여러 개의 입력을 가질 수 있습니다. 비밀번호 재설정 옵션을 제공하는 것이 더 좋습니다.

출처

2009-06-18 16:08:43

해시 된 암호는 일반적으로 검색 할 수 없습니다 (해시 함수에 따라 다르지만 보안 해시를 검색 할 수 없음). 두 사이트에서 동일한 해시를 사용하는 경우 동일한 암호를 사용할 수 있습니다.이 암호는 사이트에서 사용하는 해시 소금에 따라 다릅니다. 어떤 방법이든 사용할 수 있습니다.

암호가 해시 시스템에 안전하게 저장되어있는 경우 공급자 암호를 잊어 버린 경우 암호를 재설정해야합니다.

출처

2009-06-18 16:09:03 marr75

해싱 알고리즘에는 여러 가지 유형이 있습니다. 일부는 다른 것보다 안전합니다. MD5는 대중적이긴하지만 안전하지 못합니다. SHA 계열은 더 안전한 알고리즘 세트입니다.

정의상 해시는 일방적 인 함수입니다. 되돌릴 수는 없습니다. 일반 텍스트 암호를 복구하는 간단한 방법이 있다면

http://en.wikipedia.org/wiki/Sha-1

출처

2009-06-18 16:11:02

일반 SHA-1/2는 좋지 않은 아이디어입니다. 해싱 속도를 늦추려면 소금과 무언가가 필요합니다. PBKDF2, bcrypt, scrypt가 표준 선택 사항입니다. – CodesInChaos

동의, 나는 일반적으로 요즘에만 bcrypt를 사용하지만 질문은 실제로 불가능한 해시를 역전시키는 것에 관한 것이 었습니다. (알려진 해시의 조회 테이블을 사용하는 것은 해시를 역전하는 것과 동일하지 않습니다.) –

는,로 시작하는 암호를 해싱 아무 소용이 없을 것이다. 이 시점에서 base64 또는 ROT13을 사용할 수도 있습니다. (그렇게하지 마십시오!)

다른 언급 된 것처럼 다른 암호 복구 방법을 사용하십시오. 클리어 텍스트 암호에 대한 액세스 권한을 가진 좋은 이유는 없습니다.

두 사이트의 해시가 같은 경우 사용자는 둘 다 동일한 암호를 사용하는 것이 가장 가능성이 큽니다. 그러나 100 % 보장되지는 않지만 해시 충돌이있을 수 있지만 그럴 가능성은 거의 없습니다.

출처

2009-06-18 16:12:45 whatsisname

그리고 둘 중 어느 사이트도 소금을 추가하지 않았을 가능성이 큽니다. –

-1

암호 해시를 저장하는 일반적인 개념은 암호를 안전하게 유지하는 것입니다. 데이터베이스에 대한 액세스 권한이있는 사람도 암호를 설정해야합니다. 신뢰는 절대로 암시 적이 지 않습니다. 해시는 단방향 알고리즘이므로 해시 코드에서 원래 암호를 파생시킬 방법이 없습니다. 일반적으로 사용자가 해시로 저장된 비밀번호를 복구해야하는 경우 비밀번호 힌트를 요청하고 임시 비밀번호로 이메일을 보내거나 비밀번호를 변경할 수있는 임시 링크로 이메일을 보냅니다. 이렇게하면 암호가 일반 텍스트로 저장되지 않으며 신뢰할 수 있다고 생각되는 사람들까지도 안전합니다.

출처

2009-06-18 16:20:11 jrista

"또한 소금을 보관하면 처음부터 염분을 섭취하는 목적을 무 찌르게됩니다."- 이것은 잘못되었습니다. 당신은 소금을 저장해야하며, 그렇지 않으면 해시의 유효성을 검사 할 수 없습니다. 소금을 저장하는 데 보안상의 단점은 없습니다. 조회 공격을 막기 위해서입니다. – frankodwyer

슬레이트를 즉시 버려야한다는 의견에 동의해야합니다. 암호 교환의 예에서 소금은 한 번만 사용되므로 폐기해야합니다. 사용자 인증에서 사용자 별 소금을 사용해야하며 사용할 수 있도록 비밀번호와 함께 저장해야합니다. 예를 들어 사용자 이름으로 비밀번호를 소금으로 처리하면 사용자 당 사전이 필요하기 때문에 미리 계산 된 사전 공격을 방지 할 수 있습니다. – longneck

모든 실용성에서 대부분의 프로그래머는 데이터베이스에 소금을 넣지 않습니다. 왜냐하면 누군가가 데이터베이스에 액세스하고 해시를 가지고 있다면 소금도 갖기 때문입니다. 소금은 종종 앱 코드에 있습니다. 또 다른 아이디어는 사용자가 합류 한 시점을 기준으로 소금을 칠하는 것과 같이 계산 된 소금을 사용하는 것입니다. – marr75

일반적으로 사용되는 해시를 반전 할 수있는 방법이 없습니다. bruteforced (가능한 모든 비밀 번호를 사용하십시오) 또는 단어 목록 (일반적으로 사용되는 암호 목록 사용)을 조합하여 무언가를 가속화 할 수 있지만 매우 느리고 CPU 집약적 인 프로세스입니다.

많은 사이트에서 사용하는 가장 좋은 방법은 사용자 이름과 이메일을 입력하는 "비밀번호 재설정"버튼을 만드는 것이며, 일치하면 무작위 암호를 보내고 로그인 페이지에 대한 링크를 제공합니다 임의의 비밀번호로 로그인하고 비밀번호를 변경할 수 있습니다. 이렇게하려면

출처

2009-06-18 17:25:21 Mentalikryst

당신은 필드의 모델이 있어야합니다

Hashed_password 
Salt

을 그리고 당신은 그런 다음 컨트롤러에서 정의 할 수 있습니다 암호를 (여기에 내가 SHA1를 사용) 해시 방법 사용자를 알아야합니다 :

def self.encrypted_password(password, salt) 
    string_to_hash = password + "wibble" + salt 
    Digest::SHA1.hexdigest(string_to_hash) 
end

다음으로 비교할 수 있습니다

는

user.Hashed_password == encrypted_password(password, user.salt)

사실은 그쪽을 의미 t "password"는 사용자 "user"의 암호입니다

출처

2010-07-05 23:34:37 Fabianf

암호가 해시 값으로 저장된 암호 검색

답변

관련 문제