보안에서 솔팅이란 무엇인가요? 비밀번호 해싱에 대한 설명

2012년 6월, 한 공격자가 1억 1,700만 건의 링크드인 계정 정보를 러시아 포럼에 유출했습니다. 이 목록은 솔트가 없는 SHA-1 해시 값으로 가득 차 있었습니다. SHA-1은 속도가 매우 빠릅니다. 동일한 비밀번호를 구분하는 솔트가 없으면 같은 해시 값이 수천 번씩 반복됩니다. 보안 연구원들은 약 72시간 만에 파일의 약 90%를 해독했습니다. 이 유출 사건이 2016년 5월 1억 6,700만 건의 계정 정보 유출 데이터 세트의 일부로 다시 알려지면서, 유출된 계정 정보는 수년간 다양한 계정 정보 탈취 공격에 악용되었습니다.

그 유출 사건을 사소한 사건으로 축소시킬 수 있었던 방어책, 즉 저장된 모든 비밀번호에 솔트를 추가하는 방법은 이미 1979년에 존재했습니다. 바로 솔팅(salting)입니다. 새로운 것도 아니고, 비용이 많이 드는 것도 아니고, 특별히 기발한 방법도 아닙니다. 하지만 이 솔팅 하나만으로도 데이터베이스 유출이 국한된 사건으로 끝나지 않고, 5년 동안 모든 사람의 비밀번호 문제가 되는 것을 막을 수 있습니다.

대부분의 최신 암호 저장 실패는 여전히 동일한 근본 원인에서 비롯됩니다. 누군가가 "SHA-256이면 충분하다"고 판단한 것이죠. 이 글에서는 솔팅이 실제로 무엇인지, 어떻게 작동하는지, 어떤 공격을 방지하고 어떤 공격을 방지하지 못하는지, 그리고 OWASP가 2026년 기본값으로 권장하는 것은 무엇인지 살펴봅니다.

보안 및 비밀번호 해싱에서 솔팅이란 무엇인가요?

핵심을 한 문장으로 요약하자면, 솔팅이란 비밀번호를 해시하기 전에 임의의 값을 추가하는 것을 의미합니다. 이 임의 값(솔트)은 계정당 한 번 생성되며, 새 비밀번호 해시와 함께 생성되어 결과 해시 옆에 평문으로 저장되고, 로그인할 때마다 읽어옵니다. 솔트는 암호화 키도 아니고, 비밀 정보도 아니며, 암호화 방식도 아닙니다. 솔팅은 두 사용자가 동일한 비밀번호를 사용하더라도 저장된 해시된 비밀번호를 공유하지 않도록 하는 단 하나의 역할을 하는 공개적인 수정자일 뿐입니다.

해싱 자체는 단방향입니다. SHA-256이나 Argon2id 같은 알고리즘으로 비밀번호를 처리하면 어떤 알고리즘으로도 역추적할 수 없는 고정 길이의 값이 생성됩니다. 하지만 "어떤 알고리즘도" 역추적할 수 없다는 것은 한 가지 쉬운 지름길, 즉 미리 계산된 사전에서 해시 값을 찾는 것을 허용한다는 의미입니다. 솔팅은 이러한 지름길을 차단합니다. 해싱 과정에 솔트를 추가하면 사용자의 비밀번호가 단어 하나하나까지 동일하더라도 각 사용자마다 고유한 해시 값이 생성됩니다. "password"와 "qwerty"처럼 흔히 사용되는 비밀번호는 더 이상 데이터베이스에서 충돌하지 않습니다. 솔팅을 통해 공격자는 한 행의 정보가 유출되더라도 다른 사용자에 대한 정보를 알 수 없습니다.

유용한 솔트와 쓸모없는 솔트를 구분하는 세 가지 규칙이 있습니다. 첫 번째 규칙: 모든 비밀번호에는 사용자가 가입하거나 비밀번호를 재설정할 때 새로 생성되는 고유한 임의 솔트가 할당됩니다. 여러 계정에서 솔트가 추가된 비밀번호를 재사용하는 것은 솔트가 추가되지 않은 비밀번호와 다를 바 없습니다. 대량 공격은 동일한 방식으로 작동하기 때문입니다. 두 번째 규칙: 솔트는 공개될 수 있습니다. 솔트 값만으로는 공격자가 기본 해시 함수에 접근할 수 있는 지름길이 없습니다. 따라서 솔트는 해시 값과 함께 데이터베이스에 저장되며, 이러한 배치는 적절하며 권장됩니다. 세 번째 규칙: 솔트 값은 암호학적으로 안전한 의사 난수 생성기에서 생성되어야 합니다. Linux에서는 `getrandom(2)`를 통해 의사 난수 생성기를 제공합니다. Node.js에서는 이를 `crypto.randomBytes`라고 부릅니다. Python 표준 라이브러리에서는 `secrets.token_bytes`로 래핑합니다. 암호학적으로 안전하지 않은 `Math.random()`은 적합하지 않습니다. 실제 감사 코드에서 필요 이상으로 자주 사용되지만 말입니다.

"hunter2"를 비밀번호로 선택한 두 사람은 완전히 다른 해시값을 저장해야 합니다. 솔팅이 바로 그 역할을 합니다. 솔팅을 생략하면 데이터베이스에 해시값뿐만 아니라 누가 누구와 어떤 비밀번호를 공유하는지에 대한 소셜 그래프까지 노출됩니다.

비밀번호 솔팅은 어떻게 작동하나요?

이 메커니즘은 네 단계로 나뉘는데, 지난 10년간 발생한 비밀번호 저장 시스템 유출 사고들을 보면 거의 모든 실패는 누군가가 이 단계 중 하나를 건너뛰었기 때문에 발생했음을 알 수 있습니다.

첫 번째 단계는 등록 시점에 실행됩니다. 애플리케이션은 CSPRNG(공통 의사 난수 생성기)에 16바이트에서 32바이트 사이의 난수를 요청합니다. 이것이 솔트(salt)입니다. OWASP의 2025 가이드라인에서는 16바이트(128비트)를 최소값으로 제시하고 있으며, auth0 및 여러 암호 관리자 공급업체는 32바이트를 권장합니다. NIST의 SP 800-63B-4에서는 최소값을 4바이트로 설정했지만, 약 6만 5천 명의 사용자가 생기면 생일 관련 충돌이 발생하기 시작한다고 경고하고 있습니다. 따라서 실제로 4바이트를 사용하는 경우는 거의 없습니다.

두 번째 단계에서는 솔트를 사용자가 선택한 암호와 결합합니다. 가장 일반적인 방법은 문자열 연결이며, 솔트는 암호 문자열 앞이나 뒤에 위치합니다. 일부 시스템에서는 솔트를 HMAC 키로 사용하여 HMAC를 활용하는데, 이는 단순 문자열 연결에서 발생하는 몇 가지 모호한 길이 확장 문제를 해결합니다.

세 번째 단계에서는 결합된 입력값을 암호 해싱 알고리즘(암호학 교과서에서는 키 유도 함수, KDF라고 함)을 통해 처리합니다. 대부분의 팀이 이 단계에서 어려움을 겪는데, 흔히 일반적인 해시 알고리즘을 사용하고 작업이 완료되었다고 생각하기 때문입니다. 일반 SHA-256은 암호를 저장하는 데 적합하지 않습니다. 2026년의 소비자용 GPU는 초당 1,000억 개 이상의 SHA-256 해시를 처리하므로 솔트를 사용하더라도 암호화 해싱에서 추측당 비용은 매우 낮습니다. 솔팅은 레인보우 테이블 공격 벡터를 차단하지만, 그 자체로는 무차별 대입 공격 속도를 늦추지는 못합니다. 여기서는 의도적으로 느리고 메모리 집약적인 함수를 사용하는 것이 좋습니다. OWASP에서는 Argon2id를 기본값으로 권장하며, scrypt와 bcrypt도 사용할 수 있고, FIPS-140 규정 준수를 위해 PBKDF2를 매우 높은 반복 횟수로 사용할 수도 있습니다.

4단계에서는 해시 값과 솔트를 모두 저장합니다. 최신 라이브러리는 저장 형식을 처리하므로 저장된 솔트를 수동으로 관리할 필요가 없습니다. bcrypt의 출력은 `$2b$12$9f4c8a7b...kQR8YZpL9`와 같은 형식입니다. 이 단일 문자열에는 알고리즘 식별자, 비용 요소, 솔트 및 해시 값이 모두 포함됩니다. Argon2id는 이와 유사한 PHC 문자열 형식인 `$argon2id$v=19$m=19456,t=2,p=1$$`를 사용합니다. 이 문자열을 데이터베이스 열에 저장하고 나면 라이브러리가 암호를 안전하게 저장하는 데 필요한 모든 작업을 수행합니다. 즉, 솔트에 대한 난수 생성, 느린 해시 알고리즘을 통한 암호 처리, 그리고 결과를 묶어 검색 가능하게 만드는 작업까지 모두 처리합니다.

로그인 과정은 동일한 파이프라인을 역순으로 따릅니다. 애플리케이션은 사용자의 솔트와 저장된 해시 값을 조회하고, 제출된 비밀번호를 동일한 솔트를 사용하여 동일한 알고리즘으로 처리한 후, 상수 시간 비교를 통해 결과를 저장된 해시 값과 비교합니다. 상수 시간 비교는 매우 중요합니다. 단순한 `==` 연산자는 일치하는 바이트 수에 대한 정보를 노출시켜 실제 타이밍 공격 취약점을 야기할 수 있습니다. `hmac.compare_digest`, `crypto.timingSafeEqual` 또는 사용하는 프레임워크의 해당 함수를 사용하십시오.

소금 간이 중요한 이유: 무지개 테이블 문제

레인보우 테이블은 솔팅 기법이 개발된 목적에 부합하는 특정 공격 방식입니다. 모든 가능한 비밀번호, 즉 사전 단어, 일반적인 변형, 유출된 목록의 항목 등을 SHA-256 해시값으로 매핑하는 미리 계산된 조회 테이블을 상상해 보세요. 이러한 테이블은 실제로 존재하며, 크래킹 포럼에서 판매되고, 그 규모는 테라바이트에 달합니다. 공격자가 솔팅되지 않은 해시값이 담긴 데이터베이스 덤프를 확보하면, 레인보우 테이블에서 해시값을 찾는 것은 크래킹 작업이 아니라 데이터베이스 쿼리가 됩니다. 2012년 링크드인 해킹 사건이 바로 이런 방식으로 진행되었습니다. 1억 1,700만 개의 솔팅되지 않은 SHA-1 해시값을 레인보우 테이블에 적용하여 약 3일 만에 90%를 해독했습니다.

사용자별 솔트를 추가하면 레인보우 테이블 공격은 더 이상 작동하지 않습니다. 공격자는 각 고유한 솔트 값마다 별도의 사전 계산된 테이블이 필요합니다. 16바이트의 임의 솔트를 사용하는 경우 1억 1,700만 명의 사용자에 대해 1억 1,700만 개의 서로 다른 테이블이 필요하며, 각 테이블의 크기는 여전히 테라바이트에 달합니다. 저장 비용만으로도 이는 실현 불가능합니다. 따라서 이 공격은 위협 모델에서 제외됩니다.

솔트의 역할은 바로 이것입니다. 솔트의 역할은 의도적으로 제한적입니다. 솔팅은 특정 사용자를 대상으로 하는 무차별 대입 공격의 속도를 늦추지 못합니다. 솔팅은 이전 유출 정보를 이용한 자격 증명 스터핑 공격을 막지 못합니다. 솔팅은 비밀번호 자체가 "123456"인 경우에도 도움이 되지 않습니다. 공격자는 뻔한 사전식 조합을 시도하고, 각 추측마다 솔트가 다시 계산되지만, 추측당 비용은 크게 줄어들지 않습니다.

솔팅이 확실하게 완화하는 것은 레인보우 테이블과 동일 데이터베이스 내 사용자 간 비밀번호 재사용 정보 유출입니다. 느린 해싱이 완화하는 것은 추측당 비용입니다. 페퍼링이 완화하는 것은 데이터베이스 내 정보 유출입니다. MFA가 완화하는 것은 자격 증명 스터핑입니다. 솔팅은 보안 스택의 한 계층일 뿐입니다. 비밀번호를 해킹하기 어렵게 하기 위해 솔트를 추가하는 것은 각 비밀번호를 개별적으로 추측하기 어렵게 만드는 것과는 다릅니다. 솔팅의 목표는 모든 사용자에 대해 서로 다른 해시값을 생성하는 것이며, 각 추측에 드는 비용을 높이는 것은 별개의 문제입니다.

해싱 vs 암호화 vs 솔팅

특히 비전문가들이 글을 쓸 때 혼동하기 쉬운 세 가지 용어입니다. 이 용어들은 서로 바꿔 쓸 수 없습니다.

암호화는 나중에 복구하려는 데이터를 보호합니다. 수신자는 암호화 키를 가지고 있으며, 키를 적용한 후 원본 데이터를 읽습니다. 해싱은 단방향입니다. 비밀번호가 해시 값으로 변환되면 어떤 알고리즘으로도 역변환할 수 없습니다. 솔팅은 해시 함수의 입력값에 적용하는 수정자이며, 그 자체로는 의미가 없습니다.

2013년 어도비의 데이터 유출 사건은 경각심을 일깨워주는 사례입니다. 어도비는 1억 5300만 건의 사용자 기록을 3DES ECB 모드로 암호화하여 사이트 전체에 단일 키로 저장했습니다. 이러한 방식은 세 가지 측면에서 실패였습니다. 암호화는 비밀번호 저장에 적합하지 않은 기본 요소입니다. ECB 모드는 동일한 입력이 동일한 출력으로 이어지도록 하여 보안을 취약하게 만듭니다. 데이터베이스 전체에 하나의 키를 재사용한다는 것은 한 번 키를 해독하면 1억 5300만 건의 모든 기록을 해독할 수 있다는 것을 의미했습니다. 슈나이어는 이를 역사상 최악의 비밀번호 유출 사건 중 하나로 꼽았습니다. 모든 계층에서 문제를 해결하기 위해 솔트를 추가한 저속 해싱 방식으로 전환해야 했습니다.

소금 vs 후추: 이중 방어 전략

페퍼는 솔트의 덜 알려진 사촌 격입니다. 개념은 애플리케이션이 처리하는 모든 암호에 적용되는 추가적인 비밀 값인데, 데이터베이스 외부에 저장됩니다. 환경 변수, 키 관리 서비스 항목 또는 HSM에 저장된 키 등이 그 예입니다. 솔트는 해시 값 옆에 평문으로 저장되지만, 페퍼는 그렇지 않습니다.

위협 모델은 데이터베이스만 탈취하는 것입니다. 공격자가 SQL 인젝션, 잘못 구성된 백업 또는 유출된 덤프를 통해 데이터베이스만 탈취하는 경우, 솔트와 해시는 확보했지만 페퍼는 확보하지 못합니다. 페퍼가 없으면 모든 추측 해시에 전역 비밀 수정자가 누락되므로 무차별 대입 공격조차 시작할 수 없습니다.

일반적인 구현 방식은 `argon2id(salt + password + pepper)`를 실행하거나, 좀 더 신중하게는 `HMAC(pepper, password + salt)`를 먼저 계산한 후 그 결과를 Argon2id에 입력하는 것입니다. OWASP는 중요 시스템에 pepper 사용을 권장하지만, pepper를 주기적으로 교체해야 하는 번거로움이 있음을 인정합니다. pepper를 교체하면 다음 로그인 시 모든 사용자의 암호를 다시 해싱해야 하며, 백업 없이 pepper를 분실할 경우 모든 계정에 접근할 수 없게 됩니다. 대부분의 소비자용 애플리케이션은 pepper를 사용하지 않지만, 은행, 정부 기관, 의료 기관과 같은 시스템에서는 일반적으로 사용합니다.

2026년의 최신 비밀번호 해싱

OWASP의 2025년 암호 저장 지침에서는 선호도 순으로 네 가지 알고리즘을 제시합니다. 이 모든 알고리즘에는 솔트가 내장되어 있으며, 사용자가 수동으로 생성할 필요가 없습니다.

Argon2id는 메모리 집약적인 알고리즘으로, 각 추측 단계마다 CPU 사이클뿐만 아니라 일정량의 RAM을 소모합니다. OWASP에서 요구하는 최소 해시당 19MiB의 메모리 용량은 공격자가 맞춤형 ASIC을 구축할 경우 상당한 양의 고속 메모리를 추가로 구축해야 한다는 것을 의미하며, 메모리는 모든 공격 시스템에서 가장 비용이 많이 드는 부분입니다. "id" 변종은 Argon2i(사이드 채널 공격 방지)와 Argon2d(GPU 공격 방지)를 결합하여, 알고리즘의 전반부에는 Argon2i를, 후반부에는 Argon2d를 실행합니다.

scrypt는 Argon2id보다 먼저 개발되었으며 동일한 메모리 집약적 원리를 사용합니다. bcrypt는 더욱 오래되었고 더 간단하지만, 입력 크기에 72바이트라는 엄격한 제한이 있어 긴 암호를 사용하는 애플리케이션에서 문제가 발생할 수 있습니다. 더 긴 입력이 필요한 경우 SHA-256으로 사전 해싱한 후 base64로 인코딩해야 합니다. PBKDF2는 속도는 느리지만 FIPS 규정을 준수하는 선택지입니다. OWASP는 2023년에 SHA-256에 대한 반복 횟수를 310,000회에서 600,000회로 늘렸습니다.

이 목록에 포함되지 않는 것은 일반 SHA-256, 일반 SHA-512, MD5, SHA-1, 그리고 "+ 솔트"로 끝나는 모든 사용자 지정 함수입니다. 속도가 가장 큰 걸림돌입니다. SHA-256은 일반적인 하드웨어에서 빠른 속도를 내도록 설계되었습니다. 이는 비밀번호 저장에 필요한 속도와는 정반대입니다.

실제 감사에서 드러나는 일반적인 소금 첨가 오류

실제 데이터 유출 보고서에서 계속해서 몇 가지 동일한 오류가 지적되고 있습니다.

모든 사용자에게 동일한 솔트를 재사용하는 것은 전체 메커니즘을 무력화시킵니다. 레인보우 테이블 문제가 한 단계 더 추가된 형태로 다시 발생합니다. 사용자 이름을 솔트로 사용하는 것은 더 나쁜데, 사용자 이름은 시스템 간에 반복되고 인기 있는 사용자 이름에 대해서는 레인보우 테이블을 미리 계산할 수 있기 때문입니다. 솔트 길이가 16바이트 미만이면 대규모 사용자 기반에서 충돌이 발생하기 시작합니다. 암호화 방식이 아닌 난수 생성 함수(예: `Math.random()`, `time(0) mod something`, 언어의 기본 난수 생성기)를 사용하여 솔트를 생성하면 예측 가능한 값이 생성되어 솔팅의 이점이 사라집니다.

보다 미묘한 실수는 "보안상의 이유로" 솔트를 다른 서버에 저장하는 것입니다. 솔트는 비밀이 아닙니다. 여러 시스템에 분산 저장하면 운영 복잡성만 증가할 뿐 암호화 강도는 향상되지 않습니다. 솔트는 해시와 같은 행에 저장해야 합니다. 최신 PHC 문자열은 이 작업을 자동으로 처리해 줍니다.

2026년 감사에서 가장 큰 문제는 솔트를 추가한 일반 SHA-256 해싱 방식과 전송 방식입니다. 솔트는 레인보우 테이블 생성을 방지하지만, GPU 팜에서 단일 계정에 대해 초당 100억 번의 추측을 실행하는 공격에는 아무런 효과가 없습니다. 해결책은 두 번째 솔트를 추가하는 것이 아니라, Argon2id와 같은 느린 KDF로 바꾸는 것입니다.

마지막으로, 기존의 솔트가 없는 해시값은 마이그레이션이 필수적입니다. 표준 절차는 다음 로그인 시 기존 해시값을 확인하고, 최신 알고리즘으로 다시 해싱한 후 덮어쓰는 것입니다. 이후 로그인하지 않는 사용자의 경우, 정해진 기간 내에 비밀번호를 강제로 재설정해야 합니다.

소금만으로는 충분하지 않은 이유

솔팅은 방어벽이 아니라 하나의 보호막입니다. 솔팅은 특정 공격, 즉 미리 계산된 테이블을 이용한 공격을 막아낼 뿐, 기본 암호의 강도에 대해서는 아무것도 드러내지 않습니다. 무차별 대입 공격은 여전히 취약한 암호에 효과적이며, 자격 증명 스터핑은 여전히 재사용된 암호에 효과적입니다. 피싱 공격 또한 모든 암호에 대해 여전히 효과적입니다.

2026년의 진정한 비밀번호 보안은 네 가지 방어 체계를 결합한 것입니다. Argon2id는 사용자별 16바이트 솔트를 사용하여 비밀번호 저장을 관리합니다. 선택 사항이지만 민감한 시스템에는 유용한 '페퍼(pepper)'를 추가하여 데이터베이스 자체에서만 발생하는 탈취를 차단합니다. 다중 요소 인증은 자격 증명 스터핑과 대부분의 피싱 공격을 막아줍니다. Have I Been Pwned와 같은 서비스 및 해당 API를 통한 지속적인 침해 모니터링은 사용자의 자격 증명이 유출되는 순간을 포착하여 비밀번호를 재설정하도록 강제합니다.

이러한 방어 체계 중 어느 하나라도 소홀히 하면 공격자는 결국 허점을 찾아냅니다. 솔팅(Salting) 기법이나 그 어떤 방어 수단 하나만으로는 지난 10년간 발생한 모든 침해 사고 사후 분석에서 실패 원인으로 지적된 바로 그 지점입니다.

Jordan Morris

Jordan Morris is an AI expert with over a decade of experience and the author of a widely-read blog focused on artificial intelligence. His content spans a range of topics—from the ethics of machine learning to real-world applications of neural networks in business. Known for his clear writing and deep insights, Jordan has become a trusted voice in the AI community, appealing to both newcomers and seasoned professionals alike.