회원가입을 할 때 우리는 아무 생각 없이 비밀번호를 입력합니다.
그리고 자연스럽게 “이 비밀번호는 서버에 저장되겠지”라고 생각하죠.
하지만 보안 관점에서 보면, 비밀번호를 그대로 서버에 저장하는 것은 가장 위험한 설계 중 하나입니다.
이 글에서는 왜 비밀번호를 서버에 저장하면 안 되는지 실제로 어떤 문제가 생길 수 있는지 서버는 비밀번호를 어떻게 다뤄야 하는지를 구조적으로 설명합니다.
비밀번호를 서버에 저장한다는 의미
여기서 말하는 “저장”은
비밀번호를 사람이 읽을 수 있는 형태로 보관하는 것을 의미해요.
예를 들어
- 관리자 화면에서 비밀번호를 확인할 수 있거나
- 데이터베이스에 그대로 노출되어 있다면
이미 보안상 심각한 문제랍니다.
서버는 언제든 침해될 수 있습니다
아무리 큰 서비스라도
서버가 100% 안전한 경우는 없습니다.
- 해킹
- 내부 직원의 실수
- 접근 권한 설정 오류
- 백업 파일 유출
이 중 하나만 발생해도
비밀번호가 평문으로 저장되어 있다면 즉시 전체 유출로 이어져요.
비밀번호 유출이 특히 위험한 이유
비밀번호는 단순한 문자열이 아니에요.
사람들은 보통 비밀번호를 여러 서비스에서 재사용합니다.
그래서 한 곳에서 유출되면
- 이메일
- SNS
- 금융 서비스
까지 연쇄적으로 공격당할 수 있어요.
이를 크리덴셜 스터핑 공격이라고 합니다.
서버 관리자가 비밀번호를 알 필요는 없습니다
중요한 사실 하나가 있어요.
👉 서버는 비밀번호를 “확인”만 하면 됩니다.
👉 “알 필요”는 없습니다.
사용자가 입력한 비밀번호가
“맞는지 틀린지만 판단”하면 충분해요.
이 개념이 보안 설계의 핵심입니다.
해시(Hash)라는 해결 방법
그래서 등장한 개념이 해시(Hash)입니다.
- 비밀번호 → 해시 함수 처리
- 결과값은 원래 비밀번호로 되돌릴 수 없음
- 같은 입력은 항상 같은 결과
서버에는 비밀번호가 아니라 해시값만 저장합니다.
암호화와 해시는 다릅니다
많이 헷갈리는 부분이에요.
| 구분 | 암호화 | 해시 |
| 복원 가능 | 가능 | 불가능 |
| 키 존재 | 있음 | 없음 |
| 목적 | 데이터 보호 | 무결성·인증 |
비밀번호는 암호화가 아니라 해시가 정답입니다.
솔트(Salt)를 사용하는 이유
해시만 써도 완벽해 보이지만, 아직 부족해요.
그래서 솔트(Salt)를 추가합니다.
- 비밀번호 + 랜덤 값
- 같은 비밀번호라도 결과가 달라짐
- 무차별 대입 공격 방어 강화
솔트는 각 사용자마다 다르게 적용됩니다.
비밀번호를 저장하면 생기는 현실적인 문제
비밀번호를 평문 저장하면
다음 문제가 실제로 발생합니다.
- 서버 침해 시 즉시 대규모 피해
- 내부자에 의한 정보 악용
- 법적 책임 및 신뢰도 하락
- 서비스 존속 자체가 위험해짐
이건 기술 문제가 아니라
신뢰의 문제입니다.
정리하면
- 비밀번호를 서버에 저장하면 안 됩니다.
- 서버는 비밀번호를 알 필요가 없습니다.
- 해시 + 솔트는 최소한의 보안 설계입니다.
- 한 번의 유출은 연쇄 피해로 이어집니다.
비밀번호를 어떻게 다루느냐는
그 서비스가 사용자를 얼마나 존중하는지를 보여주는 기준이랍니다.