AWS API를 호출할 때 복잡한 서명을 만들어야 하는데, 그 과정에서 해시가 어떻게 쓰이는지 살펴볼까요?
AWS Signature Version 4의 구조
1) 요청을 정규화(canonical request) 2) 정규화된 요청을 SHA-256 해시 3) 해시값을 포함한 서명 문자열 생성 4) HMAC-SHA256으로 최종 서명. 해시가 여러 단계에서 사용됩니다.
왜 이렇게 복잡할까
요청의 모든 요소(메서드, 경로, 헤더, 본문)를 서명에 포함시켜서, 어떤 부분도 변조되면 서명 검증이 실패하도록 합니다. 해시 생성기로 요청 본문의 해시를 직접 계산해보면 이 과정을 이해하는 데 도움이 됩니다.
직접 구현할 때
자체 API 서명을 구현할 때도 비슷한 패턴을 쓸 수 있습니다. 핵심은 모든 요소를 포함하고, 순서를 정하고, 일관되게 해시하는 것입니다.
해시와 보안의 관계
해시는 보안에서 중요한 역할을 하지만, 만능이 아닙니다. 해시 생성기로 만든 해시값은 원본 데이터를 숨기는 데는 좋지만, 짧거나 예측 가능한 입력은 무차별 대입으로 찾아낼 수 있습니다. 예를 들어 4자리 PIN을 해시해도 10,000가지 경우의 수만 시도하면 원본을 찾을 수 있죠. 그래서 비밀번호 해싱에는 솔트(salt)를 추가하고, bcrypt처럼 의도적으로 느린 알고리즘을 씁니다.
레인보우 테이블 공격
미리 계산해둔 해시-원본 쌍을 이용한 공격입니다. 솔트를 사용하면 각 사용자마다 다른 해시가 생성되어 이 공격을 무력화할 수 있습니다. 요즘 프레임워크들은 솔트를 자동으로 처리해주지만, 직접 구현할 때는 반드시 솔트를 포함시켜야 합니다.
결론적으로, 해시 함수는 현대 컴퓨팅의 핵심 기술입니다. 보안, 데이터 관리, 성능 최적화 등 다양한 분야에서 활용되며, 올바르게 사용하면 시스템의 신뢰성을 크게 높일 수 있습니다.