본문으로 건너뛰기
>_ITDITD웹 보안 플랫폼

용어 사전

솔트란? 비밀번호 해시에 더하는 사용자별 '양념'

솔트는 비밀번호를 해싱하기 전에 더하는, 사용자마다 다른 무작위 값입니다. 필요한 이유(같은 비밀번호도 사람마다 다르게 저장되어 레인보우 테이블과 대량 재사용 크래킹을 무력화), 페퍼와의 차이, 흔한 오해를 방어 관점에서, 공격 절차 없이 설명합니다.

게시 2026-06-27 업데이트 2026-06-27 2분 읽기

"솔트"는 비밀번호 해싱을 이야기하는 순간 등장합니다. 요리의 소금처럼 해시에 한 꼬집 더하면 안전성의 그림이 극적으로 달라집니다. 동작 원리와 핵심을 설명합니다(공격 절차 없음).

왜 "양념"이 효과가 있는가

솔트가 없으면 같은 비밀번호를 가진 사용자들은 같은 저장 해시를 갖습니다. 그것은 공격자에게 두 가지 지름길을 줍니다. 미리 계산된 조회 테이블(레인보우 테이블)이 곧장 들어맞고, "한 계정을 깨면 같은 비밀번호를 가진 모두에게 재사용"됩니다. 흔히 쓰이는 비밀번호일수록 이 효과는 더 커서, 데이터베이스 안에서 같은 해시가 줄지어 보이는 것만으로도 어느 계정들이 약한 비밀번호를 공유하는지 한눈에 드러납니다 — 공격자는 그 한 줄만 깨면 됩니다.

솔트를 더하면 같은 "password123" 도 사용자마다 완전히 다른 값으로 저장됩니다. 그래서 데이터베이스가 통째로 유출되더라도, 공격자는 미리 만들어 둔 테이블을 쓸 수 없고 사용자 한 명 한 명을 따로 깨야 합니다 — 비용이 수만 배로 불어납니다.

솔트 없음: "password123" → 모두 같은 해시 (테이블이 즉시 들어맞음)
↓ 사용자별 솔트 추가
Alice: salt_a + password123 → hash X
Bob: salt_b + password123 → hash Y (≠ X)
같은 비밀번호, 다른 솔트 → 모두에게 다른 저장 값. 미리 계산된 테이블이 통하지 않게 된다.

흔한 오해 vs 진실

오해

  • 솔트는 비밀로 유지해야 한다
  • 모든 사용자에게 하나의 공유 솔트를 써도 된다
  • 솔트가 약한 비밀번호도 안전하게 만든다

진실

  • 솔트는 공개해도 된다 (해시와 함께 저장)
  • 사용자마다(이상적으로는 비밀번호마다) 다른 무작위 값
  • 솔트는 "사전 계산과 재사용 크래킹"을 방어하고, 무차별 대입은 느린 해시가 처리한다

본 사이트의 견해: 솔트는 페퍼가 아니다

솔트와 자주 혼동되는 것이 페퍼입니다. 전체에 두루 더하는 비밀 값으로, 데이터베이스가 아닌 다른 곳(앱 설정이나 키 관리자)에 보관합니다. 솔트(공개, 사용자별)와 페퍼(비밀, 전역)는 역할이 다르며, 어느 쪽도 다른 쪽을 대체하지 않습니다. 다만 실무에서 첫 번째 우선순위는 bcrypt/Argon2 를 통해 솔트 + 느린 해시를 올바르게 쓰는 것입니다. 즉, 솔트를 직접 만들어 붙이거나 페퍼를 어떻게 보관할지 고민하기 전에, 검증된 해시 함수를 표준 설정 그대로 채택하는 것만으로 이 영역의 가장 큰 위험은 이미 거의 사라집니다.

다음으로 읽기

FAQ

Q솔트는 비밀로 유지해야 하나요?
A

아닙니다. 솔트는 '비밀 키'가 아니며, 해시 옆에 저장해도 괜찮습니다. 그 목적은 비밀 유지가 아니라, 같은 비밀번호도 사용자마다 다르게 저장되게 해 사전 계산(레인보우 테이블)과 대량 재사용 크래킹을 무력화하는 것입니다. 비밀로 유지하는 것은 다른 개념인 '페퍼'입니다(아래 참고).

Q모든 사용자에게 같은 솔트를 재사용해도 되나요?
A

안 됩니다. 솔트는 사용자마다(이상적으로는 비밀번호마다) 다른 무작위 값이어야 합니다. 공유 솔트를 쓰면 같은 비밀번호를 가진 사용자들이 동일한 해시로 저장되어, 공격자가 한 번의 무차별 대입으로 여러 계정을 깰 수 있습니다. 매번 암호학적 난수 생성기로 새로 생성하세요.

Q솔트를 직접 구현해야 하나요?
A

대개는 아닙니다. bcrypt, Argon2, scrypt 같은 전용 해시는 솔트를 자동으로 생성하고 저장합니다(흔히 해시 문자열 안에 내장). 솔트를 직접 손으로 더하기보다 이 표준 구현에 기대세요 — 더 안전하고 믿을 만합니다.