비밀번호가 아닌 식별값의 결정적 해시와 로그 익명화 용도를 분명히 나눕니다.
결정적 해시는 같은 입력을 늘 같은 식별자로 바꿔, 로그와 분석 데이터에 식별값이 그대로 남지 않게 합니다. 다만 입력 공간이 작으면 일반 해시는 사전 대입으로 원래 값이 복원됩니다. 그래서 개인 식별값에는 비밀키 기반 가명화와 분명한 보존·교체 정책이 필요합니다.
대소문자, 공백, 표기 차이를 먼저 정규화해 논리적으로 같은 값이 같은 결과를 내게 합니다.
비밀키 기반 HMAC을 써서 원문을 추측하기 어렵게 하고, 서로 다른 데이터 영역끼리 이어 붙이기도 어렵게 합니다.
로그, 분석, 중복 탐지처럼 용도마다 키나 문맥을 따로 써서 식별자끼리 교차 결합되지 않게 합니다.
이메일이나 전화번호 같은 식별값을 원래 값으로 되돌릴 수 없는 가명으로 바꿉니다.
0 / 200바이트 · 입력은 저장되지 않습니다
아래 증명은 글로 된 설명이 아닙니다. 버튼을 누르면 이 서버가 지금 직접 계산합니다.
해시 함수는 규격 문서에 실린 값을 그대로 재현하고, 그 위에 얹은 가명 구성은 고정 키에서 항상 같은 문자열을 냅니다. 가명은 단순한 해시값이 아니라 용도와 키에 묶인 값입니다.
표준 문서에 실린 테스트 벡터를 그대로 넣어 같은 값이 나오는지 확인합니다.
대소문자·공백·표기가 달라도 같은 사람은 같은 가명으로 모입니다. 원문을 저장하지 않고도 같은 사람인지 판단할 수 있습니다.
표준 문서에 실린 테스트 벡터를 그대로 넣어 같은 값이 나오는지 확인합니다.
가명은 키 기반 HMAC이라 원문이 남지 않고, 용도(purpose)가 다르면 같은 사람이라도 값이 달라집니다. 한 시스템의 가명 표를 훔쳐도 다른 용도의 가명과 대조할 수 없습니다.
막아야 할 입력을 실제로 넣고 거부되는지 확인합니다.
규격 원문을 먼저 실었습니다. 사례는 이 분야에서 실제로 보안이 뚫린 일을 다룬 자료입니다.
SHA-256의 원문입니다. 예시 digest가 실려 있습니다.
키를 쓰는 가명화가 단순 해시와 다른 이유를 설명합니다.
재식별 위험과 용도를 나누는 기준을 다룹니다.
다음 단계
로그·분석 영역별로 purpose와 키 보존 기간을 정하고, 키를 교체했을 때 어디까지 연결되는지 검증합니다.