비밀번호를 데이터베이스에 있는 그대로 저장해서는 안 됩니다. 그럼 어떻게 저장할까요? 답은 해싱입니다. 동작 원리와 안전하게 하기 위한 핵심을 설명합니다(공격 절차 없음).
해싱 ≠ 암호화
이 둘은 헷갈리기 쉽지만 목표가 정반대입니다. 암호화는 '키로 되돌릴 수 있어 나중에 다시 읽을 수 있다'이고, **해싱은 '단방향이라 되돌릴 수 없다'**입니다. 비밀번호는 운영자조차 다시 읽을 필요가 없는 정보이므로, 의도적으로 되돌릴 수 없는 해시가 알맞습니다.
암호화 (가역)
평문 ⇄ 암호문. 키로 되돌림. 다시 읽을 데이터에 사용
해싱 (단방향)
비밀번호 → 해시. 되돌릴 수 없음. 비밀번호 저장에 사용
로그인할 때는 '입력된 비밀번호를 같은 방식으로 해싱해 저장된 해시와 일치하는지' 확인합니다. 원본을 복원할 필요는 전혀 없습니다.
왜 '날것의 MD5/SHA-256'으로는 부족한가
MD5와 SHA-256은 빠른 해시입니다. 다른 용도에서는 유용한 성질이지만 비밀번호 저장에는 약점입니다. 공격자가 유출된 해시에 대해 초당 엄청난 수의 추측을 계산할 수 있기 때문입니다.
- 레인보우 테이블: '흔한 비밀번호 → 그 해시'를 대량으로 미리 계산한 표. 날것의 해시라면 조회만으로 일치를 찾아냅니다.
- 무차별 대입: 해시가 빠를수록 단위 시간당 추측이 많아져 깨기 쉬워집니다.
범용 해시와 비밀번호용 해시의 차이
둘 다 '해시'라고 불리지만 만들어진 목적이 다릅니다. 비밀번호 저장에 쓰는 것은 오른쪽 열뿐입니다.
| 범용 해시(MD5, SHA-1, SHA-256) | 비밀번호용 해시(Argon2id, bcrypt, scrypt, PBKDF2) | |
|---|---|---|
| 만든 목적 | 파일 변조 탐지, 서명 등 | 비밀번호 저장 |
| 속도 | 가능한 한 빠르게 | 일부러 느리게(조정 가능) |
| 솔트 | 설계에 포함되지 않음 | 설계에 포함(PBKDF2는 호출 측에서 받음) |
| 비용 조정 | 불가 | cost, 반복 횟수, 메모리. 시간이 지나면 올림 |
| 비밀번호 저장에 | 쓰지 않는다 | 쓴다 |
NIST SP 800-63B-4도 비밀번호를 솔트와 비용 계수를 입력으로 받는 비밀번호 해싱 방식으로 저장하고, 비용은 성능을 해치지 않는 범위에서 가능한 한 높게 설정하며 시간이 지나면 올리라고 요구합니다.
두 가지 안전장치
솔트 추가(사용자마다 다른 값)
해싱하기 전에 사용자마다 다른 무작위 값(솔트)을 섞으세요. 그러면 같은 비밀번호도 사람마다 다르게 저장되어 레인보우 테이블을 무력화하고, 한 번의 크래킹으로 여러 계정에 걸친 재사용 비밀번호까지 깨는 것을 막습니다.
의도적으로 느린 전용 해시 사용
bcrypt / Argon2 / scrypt는 계산을 의도적으로 비싸게(비용 파라미터) 만들 수 있습니다. 정당한 로그인 한 번에서는 아무도 느끼지 못할 정도의 느림이, 공격자의 무차별 대입을 비현실적인 속도로 떨어뜨립니다. 솔트도 이들에 내장되어 있습니다.
실제 사례: 유출 공지에 '해시화'라고 적혀 있을 때
유출 공지에는 비밀번호가 평문이었는지, 해시화되었는지, 암호화되었는지가 적히기도 합니다. 이 사이트에서 다룬 사례를 저장 방식별로 정리했습니다.
| 사례 | 비밀번호에 대해 공개된 내용 | 이용자에게 의미하는 것 |
|---|---|---|
| Takufile-bin(2019년) | 평문으로 저장 | 그대로 읽힐 수 있음. 같은 비밀번호를 쓰는 다른 서비스도 위험 |
| 사쿠라 인터넷(2026년) | 일부 초기 비밀번호가 해시화되지 않았음 | 초기 비밀번호를 계속 쓰는 사람은 지금 바꿔야 함 |
| Gyazo(2026년) | 비밀번호 해시 유출, 방식은 비공개 | 방식에 따라 되돌려질 수 있음. 회사는 비밀번호 변경을 요청 |
공지를 읽을 때 기억할 점은 두 가지입니다.
- '해시화'라는 말만으로는 안전한지 알 수 없습니다. 날것의 MD5와 솔트를 더한 느린 해시는 비밀번호가 복원되는 쉬움이 크게 다릅니다
- 방식이 적혀 있지 않다면 약한 방식이었다고 가정하고 행동하세요. 그 서비스와, 같은 비밀번호를 쓰는 다른 서비스에서 비밀번호를 바꿉니다
자신의 이메일 주소가 과거 유출에 포함되었는지는 비밀번호 유출 확인 방법으로 확인할 수 있습니다.
자신의 사이트와 계정 점검 방법
이용자로서: 비밀번호 재설정 방식을 본다
'비밀번호 찾기'가 원래 비밀번호를 이메일로 보내 준다면, 그 서비스는 평문이나 되돌릴 수 있는 형태로 저장하고 있을 가능성이 높습니다. 그곳에는 다른 곳에서 쓰는 비밀번호를 쓰지 마세요.
이용자로서: 비밀번호의 강도를 확인한다
해싱은 길고 추측하기 어려운 비밀번호일수록 잘 지켜 줍니다. 비밀번호 강도 체커로 대략적인 강도를 확인하고, 보관은 비밀번호 관리자에 맡기세요.
개발자로서: 어떤 함수로 저장하는지 확인한다
코드에서 비밀번호를 저장·검증하는 함수를 찾습니다. PHP의 password_hash(), Django의 내장 인증, bcrypt/Argon2 라이브러리는 비밀번호 전용이라 기본을 충족합니다. md5(), sha1(), sha256을 직접 호출하는 곳은 전환 대상입니다.
개발자로서: 저장된 값과 설정을 확인한다
저장된 해시의 식별 방법, OWASP의 최소 설정, 약한 알고리즘에서 옮기는 방법은 비밀번호를 안전하게 저장하는 법에서 다룹니다.
이 사이트의 관점: 직접 만들지 않는다
'MD5에 솔트만 더하면 충분하다'고 생각하는 것은 흔한 실수입니다. 안전한 비밀번호 저장은 솔트의 생성과 저장, 비용 조정, 타이밍 차이 처리에도 달려 있습니다. 그것을 직접 조립하기보다 언어·프레임워크의 공식 비밀번호 함수에 기대세요(대부분 내부적으로 bcrypt/Argon2를 씁니다). 새 시스템에는 Argon2id를 첫 번째 선택으로 삼으세요.
출처(1차 자료)
- NIST, "SP 800-63B-4 Digital Identity Guidelines: Authentication and Authenticator Management"(2025년 8월) — pages.nist.gov(솔트와 비용 계수를 받는 해싱 방식, 시간에 따른 비용 상향)
- OWASP, "Password Storage Cheat Sheet" — cheatsheetseries.owasp.org(해싱과 암호화의 차이, 권장 알고리즘, 작업 계수)
- RFC 9106, "Argon2 Memory-Hard Function for Password Hashing and Proof-of-Work Applications" — rfc-editor.org
- 각 사례의 출처(회사의 공식 발표)는 이 사이트의 링크된 기사에 실려 있습니다
다음으로 읽기
- 용어집: 솔트란(재사용 공격을 무력화하는 사용자별 무작위 값)
- 학습: 비밀번호를 안전하게 저장하는 법(실전 해싱 + 솔트)
- 기초: 비밀번호를 올바르게 저장하기(평문 금지) / 비밀번호 관리자 고르기
- 사례: Takufile-bin 정보 유출 사건(2019년)(비밀번호 평문 보관의 실제 사례)