같은 이메일 주소인데 해시값이 다르게 나와서 당황한 적 있으신가요? 아마 공백이나 대소문자 차이 때문일 겁니다.
해시의 민감성
해시 함수는 입력의 모든 비트를 고려합니다. "[email protected]"과 "[email protected] "(끝에 공백)은 완전히 다른 해시값을 만들어냅니다. 해시 생성기에서 직접 테스트해보면 공백 하나의 차이를 확인할 수 있어요.
정규화의 필요성
Gravatar는 이메일 해시를 만들기 전에 반드시 소문자로 변환하고 앞뒤 공백을 제거하라고 안내합니다. 이렇게 입력을 정규화해야 항상 같은 해시값을 얻을 수 있죠.
일반적인 정규화 규칙
1) 앞뒤 공백 제거(trim) 2) 소문자 변환(lowercase) 3) 유니코드 정규화(NFC) 4) 인코딩 통일(UTF-8). 이 순서대로 처리하면 대부분의 문제를 예방할 수 있습니다.
해시와 보안의 관계
해시는 보안에서 중요한 역할을 하지만, 만능이 아닙니다. 해시 생성기로 만든 해시값은 원본 데이터를 숨기는 데는 좋지만, 짧거나 예측 가능한 입력은 무차별 대입으로 찾아낼 수 있습니다. 예를 들어 4자리 PIN을 해시해도 10,000가지 경우의 수만 시도하면 원본을 찾을 수 있죠. 그래서 비밀번호 해싱에는 솔트(salt)를 추가하고, bcrypt처럼 의도적으로 느린 알고리즘을 씁니다.
레인보우 테이블 공격
미리 계산해둔 해시-원본 쌍을 이용한 공격입니다. 솔트를 사용하면 각 사용자마다 다른 해시가 생성되어 이 공격을 무력화할 수 있습니다. 요즘 프레임워크들은 솔트를 자동으로 처리해주지만, 직접 구현할 때는 반드시 솔트를 포함시켜야 합니다.