← 메인으로

📩 전자금융 보안 모의해킹 · 고정·유추가능 인증코드 (SMS/ARS)

Target: 본인확인 인증코드
평가기준: 위험도 5 WEB-SER 고정된 인증정보 이용 방지
💡 쉽게 말하면
문자 인증번호가 매번 000000으로 똑같다면, 한 번 본 사람이 남의 인증도 통과합니다. 매번 예측 불가한 난수로 만들어야 합니다.
🔓 공격 시뮬레이션 (Red Team)
🛡️ 대응 방안 (Blue Team)
SMS 인증코드 확인🔒 Secured Channel
SMS/ARS 인증코드가 매번 동일하거나 규칙적이면, 한 번 관측한 값으로 타인의 본인확인을 예측·우회할 수 있습니다.
⚡ 고정 인증코드 예측
관측한 코드(000000 고정) 재사용
OFF
🖥️ 금융 시스템 처리 로그
[SYSTEM] Core Banking Channel ready.
[INFO] 거래 요청 대기 중...
⚖️ 컴플라이언스 위반 분석
공격 실행 후 분석 결과가 표시됩니다.
[심각] 전자금융 보안 기준 위반 감지
  • 평가기준 고정된 인증정보 이용 방지 / 유추 가능한 인증정보(위험도 5)
  • 적절하지 않은 난수 값 사용(보안기능)
  • 반복 인증시도 제한 기능 부재
🛡️ 대응 코드/설정 실습

인증코드는 암호학적 난수(가변)로 생성하고, 유효시간·시도횟수 제한을 적용해야 합니다.

📚 금융보안원 평가기준 / 조치 가이드

1. 점검 항목

이용자 인증 > 고정된 인증정보 이용 방지

2. 위험 분석

  • 고정·규칙적 코드로 타인 본인확인 우회
  • 무차별 대입으로 인증코드 추측

3. 조치 방법

  • SecureRandom 등 안전한 난수로 매번 생성
  • 코드 유효시간 및 시도횟수 제한
  • 주민번호·전화번호 등 유추 가능 정보 사용 금지
🏗️ 현대 금융 IT 환경에서의 변형
SMS 대체레이트리밋Redis

어디가 달라졌나

SMS 인증코드는 SIM 스와핑·문자 가로채기에 취약해 국제적으로 권고 등급이 낮아졌습니다(NIST SP 800-63B 는 SMS 를 “restricted” 로 분류). 국내는 본인확인 제도상 SMS 의존이 크지만, 앱 푸시·패스키를 1순위로 두고 SMS 는 대체 수단으로 내리는 것이 현재 방향입니다.

현대 스택에서의 조치

  • 코드는 서버에서 CSPRNG 로 생성하고 절대 클라이언트로 내려보내지 않습니다(응답 본문·로그·에러 메시지 포함).
  • 시도 횟수 제한(예: 5회 후 무효화)과 발급 레이트리밋을 분산 저장소로 구현합니다 — 파드마다 세면 의미가 없습니다.
  • 코드 검증은 상수 시간 비교로. 문자열 equals 는 타이밍 정보를 흘립니다.
# 발급·검증 모두 서버 상태로 (TTL + 시도 횟수)
key = f"authcode:{user_id}"
code = secrets.randbelow(1_000_000)            # CSPRNG
redis.hset(key, mapping={"code": hash(code), "tries": 0})
redis.expire(key, 180)                          # 3분
# 검증 시 tries 증가, 5회 초과면 삭제 후 재발급 요구
놓치기 쉬운 곳 — APM·로그 수집기가 요청 본문을 통째로 저장하면 인증코드가 로그에 남습니다. Datadog·Sentry 등에 마스킹 규칙을 넣었는지 확인하세요.