핵심 인사이트 (3줄 요약)
- 본질: 비밀번호는 암호화(encryption)보다 단방향 해시(hash)와 솔트(salt)로 저장해야 한다.
- 가치: 솔트는 같은 비밀번호라도 서로 다른 해시를 만들고, 레인보우 테이블 공격을 어렵게 한다.
- 판단: 감리에서는 알고리즘 선택, salt 생성, 반복 횟수, 저장 정책을 모두 확인해야 한다.
Ⅰ. 개요 및 필요성
비밀번호는 복구할 필요가 없으므로 복호화 가능한 암호화가 아니라 해시가 맞다. 이 차이를 모르고 설계하면 보안 사고로 이어진다.
그래서 감리에서는 비밀번호가 "읽을 수 없는 방향"으로 저장되는지 확인해야 한다.
- 📢 섹션 요약 비유: 비밀 메모는 다시 읽을 수 있게 보관하는 게 아니라, 아예 원문을 못 보게 바꾸는 것이다.
Ⅱ. 아키텍처 및 핵심 원리
Password
↓
Salt
↓
Hash Function
↓
Stored Digest
| 구성 요소 | 역할 |
|---|---|
| Salt | 같은 비밀번호의 해시를 다르게 함 |
| Hash | 단방향 변환 |
| Iteration / KDF | 계산 비용 증가 |
비밀번호 저장에서 중요한 것은 복원 가능성이 아니라 검증 가능성이다. 따라서 비교는 원문이 아니라 해시 결과로 해야 한다.
- 📢 섹션 요약 비유: 원래 글을 숨기고, 비교할 수 있는 도장만 남겨 두는 셈이다.
Ⅲ. 비교 및 연결
| 방식 | 특징 | 적합성 |
|---|---|---|
| Encryption | 복호화 가능 | 비밀번호 저장 부적합 |
| Hash + Salt | 단방향 | 권장 |
| Plain Text | 그대로 저장 | 금지 |
| 공격 | 대응 |
|---|---|
| Rainbow Table | Salt |
| Brute Force | 느린 KDF |
| Credential Stuffing | MFA / 정책 |
감리에서는 저장 방식만이 아니라, 해시 알고리즘이 느린 KDF인지, 솔트가 충분히 무작위인지도 확인해야 한다.
- 📢 섹션 요약 비유: 같은 이름표를 쓰면 안 되고, 각자 다른 표식을 붙여야 한다.
Ⅳ. 실무 적용 및 기술사 판단
체크리스트
- 비밀번호를 암호화가 아닌 해시로 저장하는가?
- 사용자마다 고유한 salt를 사용하는가?
- 느린 KDF를 사용하는가?
- 원문 재조회가 필요 없는 구조인가?
- 재설정/검증 정책이 분리되어 있는가?
안티패턴
- 비밀번호를 복호화 가능한 방식으로 저장하는 설계
- 모든 사용자에 같은 salt를 쓰는 설계
- 너무 빠른 해시를 쓰는 설계
- 감리 없이 라이브러리 기본값만 믿는 설계
기술사 관점에서는 "암호화 저장"이라는 표현 자체를 경계해야 한다. 비밀번호는 복호화보다 검증이 중요하기 때문이다.
- 📢 섹션 요약 비유: 열쇠를 다시 여는 게 아니라, 맞는지 확인만 하는 자물쇠다.
Ⅴ. 기대효과 및 결론
올바른 해시와 솔트는 비밀번호 유출 사고의 피해를 크게 줄인다. 그래서 인증 보안의 기본이다.
결론적으로 비밀번호는 암호화가 아니라 단방향 해시와 솔트로 보호해야 한다.
- 📢 섹션 요약 비유: 비밀은 읽을 수 없게 보관하고, 맞는지만 확인하면 된다.
관련 개념 맵
Password
↓
Salt
↓
Hash / KDF
↓
Verification
관련 키워드 및 발전 흐름도
Plain Text
↓
Hash + Salt
↓
KDF
↓
Password Security
어린이를 위한 3줄 비유 설명
비밀번호는 다시 꺼내 읽으면 안 돼요.
대신 특별한 표식을 붙여서 확인만 해요.
이게 해시와 솔트예요.