나는 C # 및 MSSQL에서 일하고 있으며 소금에 절인 해시 된 암호를 저장할 것으로 예상합니다.
nvarchar 열에 저장된 해시를 볼 때 (예 : outp 상자 aspnet 멤버 자격 공급자). 생성 된 Salt 및 Hash 값이 항상 하나 또는 두 개의 등호로 끝나는 이유가 항상 궁금합니다.
암호화 알고리즘을 사용하는 동안 비슷한 것을 보았습니다.이 우연의 일치입니까, 아니면 그 이유가 있습니까?
19
또한 Base64로 인코딩 된 이진 데이터를 NVARCHAR 필드에 저장하는 경우 6 배의 스토리지 낭비가 발생합니다. 하나의 경우 Base64는 ASCII의 하위 절반에 64 자만 포함 할 수 있으므로 절반을 저장하려면 VARCHAR 만 필요합니다. 2의 경우 Base64는 각 데이터 바이트를 1-4 자로 분해합니다. SQL Server는 이미 인코딩의 부풀림없이 해시를 저장할 수있는 VARBINARY 유형을 가지고 있으며 비교에서 데이터 정렬을 신경 쓰지 않습니다 ... :-)
—
jimbobmcgee
@WillieWheeler, 해시는 어떻게 든 저장해야합니다. Base64는 완벽한 저장 매체는 아니지만 본질적으로 아무런 문제가 없습니다. 경우
—
Brian S
hash("my password")배열을 생산 [1,2,3,4,5]하고 나는 데이터베이스에 그 값을 저장해야하는 문자열을 저장하는 것보다 더 나쁜 선택이 거기에 AQIDBAU=사용되는 해시 함수 인 경우 (물론, 이미 문자열을 생산하고, 그 다음 Base64로 그것을 인코딩에 조금 바보 같다. )
@WillieWheeler 당신이 요점을 놓치고 있다고 생각합니다. Brian S가 쓴 것을 다시 읽으십시오-그는 해싱을위한 base64의 속성에 대해 이야기하지 않았습니다. 그는 base64 형식으로 해시 (해시 함수 / 알고리즘으로 생성)를 저장하는 데 아무런 문제가 없다고 말합니다.
—
Andrew Savinykh 2018 년
OP는 해시를 저장하고 등호로 끝납니다. 이것은 그가 해시를 Base64 인코딩과 혼동하고 있음을 시사합니다. 요점은 해시를 base64로 인코딩하는 것이 좋다는 것입니다. 물론 그것은 무엇과 관련이 있습니까?
—
Willie Wheeler
네, 마침내 무슨 일이 일어나고 있는지 깨달았습니다. SSH 공개 및 개인 키 파일을 살펴본 결과 = / == 엔딩이 있음을 알았습니다. 이것은 BrianS 및 zespri describe와 같은 바이트 배열의 base64 인코딩입니다. 고마워
—
Willie Wheeler