이 문서는 프롬프트(푸시) 기반 2단계 인증이 어떻게 공격당하는지, 각 공격의 특성, 그리고 실무에서 즉시 적용 가능한 방어 조치를 정리합니다. 보안 담당자, 개발자, 일반 사용자 모두 실무로 옮길 수 있는 체크리스트와 사고 대응 절차를 포함합니다.
왜 이 문서가 필요한가
프롬프트 기반 2단계 인증은 사용 편의성과 보안성의 균형을 제공하지만, 편의성 때문에 새로운 공격 벡터가 등장했습니다. 공격자는 인간 심리(혼란·피로·사회공학)와 기기 권한 남용(오버레이·자동 승인)을 결합해 인증을 우회합니다. 이 가이드는 공격 유형별 설명과 단계별 방어법을 제공합니다.
공격 유형별 분석과 방어
1. MFA 피로(MFA Fatigue) 공격
설명: 공격자가 탈취한 비밀번호로 반복적으로 푸시 인증 요청을 보내 사용자가 짜증나서 승인하게 만드는 기법입니다. 사용자 혼란을 노립니다.
위험 신호:
- 짧은 시간에 연속으로 인증 요청이 도착
- 사용자가 로그인 시도한 기억이 없음
권장 대응:
- 절대 모르는 승인 요청을 수락하지 마세요.
- 즉시 비밀번호를 변경하고, 이미 사용한 비밀번호와 동일한지 확인하세요.
- 가능하면 계정에 2FA 기기(인증기 앱 또는 하드웨어 키)를 등록하세요.
운영 대책(서비스 제공자):
- 푸시 승인에 ‘로그인 시 표시되는 번호’ 등 로그인 페이지와 월등히 연동된 일회성 번호 표시 기능 제공
- 알림 빈도 제한(rate limiting)과 자동 차단 정책 도입
2. 사회공학(소셜 엔지니어링)을 통한 승인 요청
설명: 공격자가 전화나 메시지로 자신을 회사 담당자·지원팀 등으로 속여 사용자가 푸시 승인을 하도록 유도합니다. 대부분 공격자는 비밀번호를 이미 알고 있습니다.
위험 신호:
- 회사 직원이라 주장하면서 즉시 승인을 요구
- 비밀번호, TOTP 코드, 또는 승인 수락을 요청
권장 대응:
- 공식 담당자는 절대 비밀번호·TOTP·푸시 승인 수락을 요청하지 않습니다.
- 수신한 요청의 내용을 반드시 확인(로그인 위치·디바이스 정보 등)
- 계정 접근 시 담당자 확인 절차(콜백 번호 확인 등) 도입
3. SMS 폴백(SMS-Fallback) 악용
설명: 계정에서 푸시가 실패하면 SMS로 폴백 인증을 제공하는 경우가 있습니다. SMS는 번호 재활용, SIM 스와핑, 스푸핑에 취약합니다. 공격자는 폴백을 이용해 SMS로 인증을 받습니다.
권장 대응:
- 가능하면 SMS 인증을 비활성화하거나 번호 제거
- 필수라면 보조 전화번호 사용 금지 정책과 전화번호 변경 알림 활성화
- 보안 담당자는 전화번호 변경에 추가 확인 절차(콜백, 신분 확인)를 요구
4. 감염된 기기의 자동 승인
설명: 악성앱이 장치 관리자 권한이나 접근성 권한을 얻으면 화면을 읽고 터치 시뮬레이션으로 승인할 수 있습니다. 이 경우 사용자는 승인 과정을 전혀 인지하지 못할 수 있습니다.
권장 대응:
- 디바이스 운영체제·앱은 정식 스토어에서만 설치
- 접근성·관리자 권한을 불필요한 앱에 부여하지 않음
- 정기적인 악성코드 검사와 OS/앱 업데이트
- 회사 정책으로 기기 관리(MDM) 및 앱 허용 목록(whitelist) 운영
5. 가짜 오버레이(페이크 오버레이) 공격
설명: 악성코드는 합법적인 승인 화면 위에 가짜 UI를 덧씌워 사용자가 무의식적으로 승인하도록 유도합니다. 가짜 창은 배터리 최적화, 업데이트 요청 등 허용하기 쉬운 문구로 속입니다.
권장 대응:
- 의심스러운 시스템 권한 요청에 주의(특히 오버레이 권한)
- 알 수 없는 앱의 오버레이 권한을 즉시 철회
- 기기 재부팅 후 권한 변경 로그 확인
대체 인증 방식과 권장 성숙도
- 패스키(passkeys): 운영체제·브라우저 수준에서 공개키 기반 인증을 제공. 사용자 경험이 좋고 피싱·소셜공학 저항력이 높음.
- 하드웨어 보안키(예: FIDO2): 물리적 소유 기반으로 가장 높은 수준의 보호를 제공.
- 다중요소 결합(예: 패스키 + 디바이스 바인딩): 위험이 높은 계정에는 복수 요소 요구.
성숙도 단계(간단한 가이드):
- 초기: 푸시 2FA 도입, 사용자 교육
- 중간: SMS 폴백 제거, MDM 도입, 오버레이 권한 제어
- 고급: 하드웨어 키 또는 패스키 전환, SSO + 강제 MFA 정책
역할별 체크리스트
사용자(엔드유저):
- 모르는 푸시 요청은 절대 승인하지 않음
- 인증 기기는 최신 상태 유지, 불필요 앱 제거
- 비밀번호 관리자 사용, 고유하고 강한 비밀번호 설정
관리자·IT팀:
- SMS 폴백 사용 여부 점검 및 가능 시 비활성화
- 푸시 빈도 제한 및 이상 로그인 탐지 룰 구성
- 사용자 교육 자료와 내부 신고 프로세스 마련
보안팀(SOC):
- 푸시 인증 지연/반복 패턴 모니터링 (MFA 피로 지표)
- 의심 계정 격리 및 비밀번호 강제 재설정 절차
- 악성 앱 유입 경로 분석 및 차단
사고 대응(Incident Runbook) — 사용자가 승인했거나 의심되는 경우
- 즉시 계정 비활성화 또는 강제 로그아웃
- 비밀번호 즉시 변경(가능하면 복구 옵션도 재설정)
- 모든 세션 강제 종료 및 등록된 2FA 기기 제거
- 디바이스 악성코드 검사 및 필요 시 초기화
- 관련 로그 수집(타임스탬프, IP, 기기 정보) 및 보안팀에 제출
- 영향 범위(접근한 리소스) 파악 및 통지
승인 요청 수신 시 행동 흐름(간단 의사결정도)
flowchart TD
A[푸시 인증 요청 수신] --> B{본인 시도인가?}
B -- 예 --> C[로그인 페이지로 이동해 상호 확인]
B -- 아니요/모름 --> D[거부 및 비밀번호 변경]
C --> E{로그인 페이지와 숫자 또는 디바이스가 일치하는가?}
E -- 예 --> F[승인 가능]
E -- 아니요 --> D
D --> G[보안팀에 신고 및 계정 잠금 고려]
F --> H[로그인 완료]구현·테스트 체크리스트 (품질 기준)
- 인증 푸시에 로그인 위치·기기·일회용 숫자 등 정보 포함
- 푸시 수락 전 사용자가 취소할 수 있는 명확한 옵션 제공
- 푸시 실패 시 SMS 폴백 활성화 시 보안 경고 표시
- 자동 승인(스크립트/봇)에 대한 탐지 및 차단 테스트 케이스 포함
간단 SOP(관리자용)
- 신규 계정: 기본적으로 푸시 인증 활성화, SMS 비활성화 권장
- 분실/탈취 신고: 즉시 계정 잠금 → 인증 요소 재설정 → 사용자 신원 확인 후 복구
- 주기 점검: 6개월마다 2FA 등록 현황 및 폴백 설정 감사
개인정보·규제 주의점
- 전화번호는 개인식별정보(PII)로 분류될 수 있으므로 최소한의 보유정책 필요
- 폴백 SMS를 사용하면 번호 이동·재할당 위험을 고려해 신원확인 절차 강화
테스트 사례(예시)
- 공격 시나리오: 연속 푸시 50회 보내기 → 사용자가 자동 승인하는지 확인
- 오버레이 시나리오: 합법적 승인 화면 위에 가짜 UI 띄우기 → 탐지 로그 발생 여부 확인
- 폴백 시나리오: 푸시 실패 시 SMS 수신 후 인증 성공 흐름 테스트
반례와 한계
- 모든 안전 조치를 취해도 사용자가 사회공학에 속아 승인할 수 있음(인적 요소)
- 악성코드가 이미 루트 권한을 가지면 로컬적으로 할 수 있는 방어가 제한될 수 있음
- 패스키와 하드웨어 키는 매우 안전하지만 도입 비용·사용성 이슈가 발생할 수 있음
빠른 권고(요약)
- 모르는 푸시 요청은 절대 승인하지 마세요.
- SMS 폴백을 비활성화하거나 전화번호 사용을 최소화하세요.
- 기기를 항상 업데이트하고 불필요한 권한을 제거하세요.
- 고위험 계정은 하드웨어 키나 패스키로 전환하세요.
FAQ
Q: 푸시 인증이 안전한가요? A: 일반적으로 SMS보다 안전하지만 완벽하지 않습니다. 인간의 실수와 기기 권한 남용으로 인해 우회될 수 있습니다.
Q: 몰래 승인되었는지 어떻게 알 수 있나요? A: 계정의 로그인 내역(위치·기기)과 세션 목록을 확인하세요. 의심스러운 접근이 보이면 즉시 비밀번호 변경과 세션 강제 종료를 하세요.
Q: 기업에서 우선 도입해야 할 것은? A: SMS 폴백 제거, 푸시 인증 정보(기기·위치) 표시, 사용자 교육, MDM 도입 순을 권장합니다.
공식 안내문(예시, 100–200단어)
우리 조직은 사용자 계정 보호를 위해 푸시 기반 2단계 인증을 권장합니다. 푸시 인증은 SMS보다 안전하지만, 피싱·사회공학·기기 악성코드에 취약할 수 있습니다. 승인 요청을 받았을 때 본인이 시도한 로그인이 아니라면 절대 승인하지 말고 보안팀에 즉시 신고하세요. 개인정보 보호와 계정 보안을 위해 SMS 폴백 사용을 제한하고 있으며, 가능한 경우 패스키나 하드웨어 보안키 사용을 권장합니다.
요약(끝맺음)
프롬프트 기반 2단계 인증은 강력한 도구지만, 인간 요소와 기기 보안의 취약성 때문에 보완이 필요합니다. 정책적·기술적·교육적 조치를 결합하면 대부분의 공격을 막을 수 있습니다. 중요한 계정에는 패스키나 하드웨어 보안키 도입을 검토하세요.
