12
해시되기 전에 소금을 추가하지 않은 해시 암호 데이터베이스가 있습니다. 새 암호에 소금을 추가하고 싶습니다. 분명히 나는 기존의 것들을 다시 해쉬 할 수 없다.기존 암호 해시에 소금을 어떻게 추가 하시겠습니까?
어떻게 새로운 해시 시스템으로 마이그레이션하겠습니까?
A
답변
31
물론 가능합니다. 기존 해시에 소금을 추가하고 다시 해시하면됩니다. 물론 이것은 미래의 로그인이 동일한 프로세스를 거쳐야한다는 것을 의미합니다. 두 개의 해시 함수가 호출되어야하지만 합법적 인 패턴이 많아서 어쨌든이 작업을 수행하므로 생각만큼 나쁜 냄새가 나지 않습니다.
비밀번호를 소금에 담는 것은 무지개 표를 방어하기위한 것입니다. 이 경우 소금은 비밀 일 필요는 없습니다.
http://en.wikipedia.org/wiki/Rainbow_tables#Defense_against_rainbow_tables
당신은 실제로 당신이 사용하는 것과 같은 정확한 방법입니다 기사
hash = MD5 (MD5 (password) . salt)
에서 볼 수 있습니다. (다른 해시 함수를 제외하고.)
+0
+1 - 내가 생각했던 것보다 더 좋아. –
+0
흥미로운 아이디어. 보안 문제를 해결하지 않는다고 확신합니까? 특히이 방법으로 두 번째 해시 뒤에 문자열을 얻는 사람은 이전 단계 (예 : 일정한 길이와 같은)에 대한 정보가 많아서 소금을 찾는 데 도움이 될 수 있습니다. –
+3
소금은 비밀이 아닙니다. 실제로 각 사용자와 함께 일반 텍스트로 저장해야합니다. –
2
당신은 사용자가 이전 (더 소금)이없는 여부를 표시하는 플래그 또는 새로운 (소금) 해쉬로 구성된 열을 추가 할 수 있습니다.
로그인 할 때 모든 사용자가 비밀번호를 변경하도록하는 것이 좋습니다. 이렇게하면 결국 해당 열을 제거 할 수 있습니다.
+0
또는 열을 hash_type (nosalt, md5, sha1, sha512)으로 지정하십시오. 만약 그것이 'nosalt'라면, 다른 것들이 있다면 소금 칼럼이있어 행에 다른 곳에 저장되어 있습니다 - MD5가 이미 약하게 보이므로 적절한 해시 함수를 사용하면됩니다). –
14
빠른 수정으로 데이터베이스에 소금 열을 만들 수 있으며 사용자가 이전 해시와 정확하게 일치 할 때 소금으로 입력 한 암호를 사용하여 새 해시를 만들 수 있습니다.
+0
우우, 그거 좋은 생각 같아. –
+0
이것도 내 접근 방식 일 것이다. 리팩토링은 과거의 코드를 확실히 확장하고 실제로는 데이터베이스 레벨에서 수행 될 수 있습니다. –
+0
+1, 우수한 체계. – nik
0
some ways here이 도움이 될 수 있습니다.
기존 해시에 추가하는 상수 패턴은 쓸모가 없다는 것을 기억하십시오 (해당 링크의 속임수 중 하나가 그런 것을 제안하는 것입니다). 소금을 분리하는 데 사용할 수있는 식별 가능한 패턴이 없어야합니다.
물론 가장 좋은 방법은 소금에 절인 해시 테이블로 마이그레이션하는 것입니다.
0
새 필드를 만들려면 true/false 유형 (또는 해당 DBMS에있는 값)으로 "salted"라는 데이터베이스가 있어야합니다. 기존 해시 값을 모두 false로 설정하십시오. 새롭고 소금에 절인 해시가 추가 될 때마다 "소금에 절인"필드를 true로 설정하십시오.
그런 다음 두 가지 유형의 해시를 코드에서 다르게 처리해야합니다.
이것은 특정 해결책보다 일반적인 해결책이지만 문제를 해결해야합니다.
0
해시 내부에 소금을 저장하는 경우 해시 길이를 확인하여 소금이 포함되어 있는지 확인해야합니다. 소금이 없으면 암호를 해시합니다. 소금이 있으면 암호 + 소금을 해시합니다.
데이터베이스에 부울 열이 없어야합니다.
0
내가 소금을 저장하는 가장 좋은 방법은 방금 만든 암호 해시 + 소금에 소금 값을 포함시키는 것입니다. 나는 해쉬의 시작 부분이나 끝 부분에 솔트 문자열을 추가하지 않는다. 문자 그대로 해시에 소금을 삽입한다.
+0
소금을 사용하는 방법이 아닙니까? 내가 너를 오해하지 않았 음을 확신하기 위해, 해쉬 (salt + password)를 의미합니까? – Gary
1
나는 여러 해싱 기술과 관련된 비슷한 문제를 다뤘다. 데이터베이스에서 해시 메소드 유형을 인코딩하는 방식 (예 : '알파', '베타', '감마', '델타')을 사용했습니다. 현재의 모든 해시를 적절한 수준으로 표시했습니다. 사용자가 로그인하면서 암호를 확인하고 업데이트 된 방법을 사용하여 암호를 다시 해시했습니다. 우리의 암호는 90 일 후에 만료되므로 이전 방법을 사용하는 모든 암호를 재설정 할 수있을 때까지 3 개월 동안 만 기다려야했습니다.
실제로 암호를 해싱하고 있습니까? 아니면 더 복잡한 것이 있습니까? 코딩 오류로 인해 비슷한 보트를 사용하고 있지만 원래 코드는 "1"+ loginname + ""+ 비밀번호를 효과적으로 해시합니다. 이는 레인 보우 테이블을 실행 불가능하게 만들 정도로 복잡합니다 (특히 loginname은 사용자 정의가 아니기 때문에) 선택된). –
비밀번호를 곧바로 해싱했습니다. 이미 소금을 넣은 것 같습니다. 당신의 방법은 소금과 함께, 로그인 이름을 추가하기 때문에 동일한 암호가 동일한 해시를 가지지 않기 때문에 좋아 보인다. –