.svg)
AI 솔루션 문의하기
계정 탈취 방어 얼굴 인증은 비밀번호를 잊어버렸거나 기존 휴대전화를 사용할 수 없어 계정 복구·기기 변경을 요청한 사람이 실제 계정 소유자인지 다시 확인하는 데 활용할 수 있습니다. 이 단계에서는 기존 인증수단이 정상 작동하지 않으므로, 평소 로그인과 다른 검증 절차가 필요합니다. 공격자 역시 이 상황을 악용해 자신이 계정 주인이라고 주장하며 복구를 요청할 수 있습니다.
예를 들어 공격자가 이용자의 휴대전화번호를 탈취해 문자 인증번호를 받은 뒤 고객센터에 새 기기 등록을 요청한다고 가정해 보겠습니다. 문자 인증만으로 복구가 완료된다면 실제 이용자는 접속 수단을 잃고 공격자는 계정에 접근할 수 있습니다. 반면 신분증 확인과 얼굴 매칭을 추가하면 복구 요청자와 신분증 명의자의 일치 여부를 별도로 검토할 수 있습니다.
일반 로그인은 이미 등록된 비밀번호, 기기 또는 인증 앱을 사용해 계정 접근 권한을 확인합니다. 계정 복구는 그 수단을 분실하거나 사용할 수 없는 상황에서 새 인증수단을 등록하는 과정입니다. 따라서 로그인에 사용하던 수단 하나가 확인되지 않는다는 이유만으로 복구를 거부할 수도, 문자나 이메일 인증 하나만 통과했다고 자동 승인할 수도 없습니다.
기업은 최초 가입 때 확보한 검증된 고객정보와 복구 요청 시 새로 제출된 정보를 연결할 수 있어야 합니다. 현재 신분증과 현재 얼굴의 일치만으로 과거 계정의 소유권까지 증명되는 것은 아니기 때문입니다.
복구 단계의 공격은 비밀번호를 직접 맞히는 대신 인증수단을 바꾸는 절차를 겨냥합니다. 특히 고객센터가 예외적으로 계정을 열어 주거나, 전화번호·이메일 변경을 승인하는 순간에 권한이 이동할 수 있습니다.
공격자는 고객센터 상담원에게 실제 이용자인 것처럼 연락해 “휴대전화를 잃어버렸다”, “기존 인증 앱이 삭제됐다”는 이유로 인증수단 초기화를 요청할 수 있습니다. 반대로 고객센터 직원을 사칭해 이용자를 가짜 복구 페이지로 유도하고 신분정보나 인증코드를 빼내는 경우도 있습니다.
이때 상담원이 이름, 생년월일, 전화번호처럼 유출될 수 있는 정보만으로 요청자를 확인하면 사칭에 취약해집니다. 복구 절차는 공식 앱·웹사이트에서 시작하도록 안내하고, 상담원에게는 신분증 이미지나 인증코드를 메신저로 전달받아 임의 승인하지 못하도록 권한을 제한해야 합니다. 예외 처리가 필요하다면 별도 검증 및 승인 이력을 남기는 방식이 적절합니다.
SIM 스왑(SIM Swap)은 공격자가 이동통신 서비스의 회선 이전·재발급 과정 등을 악용해 피해자의 전화번호로 오는 문자나 전화를 수신하도록 만드는 수법입니다. 계정 복구가 문자 OTP에 지나치게 의존하면 전화번호가 넘어간 뒤 공격자가 재설정 코드를 받을 수 있습니다.
문자 인증 성공은 해당 번호로 전달된 코드를 확인했다는 의미이지, 원래 계정 소유자라는 사실의 최종 증명이 아닙니다. 전화번호 변경 직후 복구 요청에는 기존 고객정보와의 추가 대조, 별도 승인 또는 중요 거래의 일시 보류를 검토할 수 있습니다.
공격자가 복구 이메일 계정에 먼저 접근한 경우 비밀번호 재설정 링크나 복구 코드를 가로챌 수 있습니다. 더 나아가 복구 이메일 주소 자체를 공격자가 통제하는 주소로 바꾸려 할 수도 있습니다. 따라서 이메일 링크 클릭만으로 등록 기기를 전부 교체하거나 기존 인증수단을 해제하도록 설계하면 위험이 커집니다.
특히 복구 이메일 변경과 기기 변경이 연속으로 발생하거나, 평소와 다른 접속 환경에서 여러 복구 요청이 반복되면 추가 검토 대상으로 분류하는 것이 좋습니다. 변경 전 등록된 연락 수단으로 별도 알림을 보내고, 이미 의심되는 연락처만을 승인 수단으로 사용하지 않는 정책도 필요합니다.
계정 탈취의 전체 공격 유형과 로그인 단계 대응은 기존 콘텐츠인 계정 탈취 공격 대응 전략에서 확인할 수 있습니다. 이 글에서는 공격이 복구 요청으로 이어지는 순간부터 새 기기 등록을 승인하기 전까지의 절차에 집중합니다.
계정 복구 시 신분증 + 얼굴 매칭은 요청자의 신원을 새로 확인하는 수단입니다. 여기에 최초 가입 당시 검증된 정보와의 대조, 접속 위험 검토, 복구 후 알림을 결합해야 새 인증수단을 잘못 발급하는 위험을 줄일 수 있습니다.
고객이 공식 복구 화면에서 계정 식별 정보를 입력하면 시스템은 해당 계정의 기존 인증 상태를 확인합니다. 등록된 기기 사용 가능 여부, 과거 신원확인 이력, 최근 전화번호·이메일 변경, 복구 요청 횟수, 접속 기기와 IP 등을 검토해 추가 확인 수준을 결정합니다. 이때 IP나 위치만으로 공격자를 확정하지는 않습니다.
요청 사유도 구분합니다. 이전 기기가 아직 사용 가능한 단순 기기 교체와, 휴대전화를 분실해 기존 인증수단을 전혀 사용할 수 없는 계정 복구는 같은 절차로 처리하기 어렵습니다. 후자는 공격자가 우회하려는 상황과 구분하기 힘들 수 있어 더 높은 확인 수준이 필요합니다.
복구 요청자가 신분증을 촬영하면 OCR로 이름과 생년월일 등 필요한 정보를 추출하고, 지원되는 신분증의 발급정보를 진위확인 절차로 검증합니다. 별도의 사본판별은 종이 출력물이나 다른 기기 화면을 다시 촬영한 이미지인지 확인하는 데 활용합니다. OCR 결과가 정상이라고 신분증이 진짜라는 뜻은 아니므로 각 결과를 분리해서 판단해야 합니다.
검증된 신원정보는 계정 최초 가입 시 확인한 고객정보와 대조합니다. 두 정보가 맞지 않거나 최초 신원확인 이력이 없는 경우에는 신분증 촬영 결과만으로 기존 계정에 대한 복구를 승인하지 않고, 추가 서류나 수동 심사 등 별도 절차로 전환해야 합니다.
현재 촬영한 얼굴을 신분증 사진과 비교해 동일인 가능성을 판단합니다. 이와 별개로 라이브니스(Liveness)·얼굴 위변조 탐지를 적용해 사진, 재생 영상 등 비정상적인 얼굴 제출을 검사합니다. 얼굴이 동일해 보이는지와 실제 촬영 과정이 신뢰할 만한지는 다른 검사 항목입니다.
사진·영상 위조를 검사하더라도 모든 공격을 완전히 차단한다고 단정할 수는 없습니다. 보안상 중요한 것은 개별 인증 결과가 아니라 복구 요청, 최초 가입 정보, 현재 촬영자의 관계를 함께 검토하는 정책입니다.
고객센터가 복구 요청자의 신원을 육안으로 판단하는 대신, 알체라 eKYC의 신분증 OCR·진위확인·사본판별과 얼굴 매칭·위변조 판별을 복구 화면에 연결할 수 있습니다. 모바일 앱에서는 SDK 기반 촬영 흐름, 서버에서는 API 기반 검증 요청과 결과 처리를 활용하는 구성을 검토할 수 있습니다. 고객사는 반환된 인증 결과를 기존 고객정보와 대조하고 복구 승인·보류 정책에 반영합니다. 계정 소유권 판단, 인증수단 재발급 및 최종 복구 승인은 고객사 시스템의 책임 영역입니다.
본인 재확인에 성공하더라도 바로 모든 접근 권한을 열어 줄 필요는 없습니다. 새 기기 등록, 기존 기기 해제, 중요 거래 재개는 각각 다른 승인 행위이므로 서비스 위험도에 따라 순서를 정해야 합니다.
새 기기로 이전한 뒤에는 분실·탈취된 것으로 판단된 인증수단을 무효화하고, 필요 시 기존 세션을 종료해야 합니다. 다만 정상 이용자가 복구 중인 경우도 있으므로 기존 기기 차단 시점과 대체 수단 제공 방법을 함께 정해야 합니다.
얼굴 매칭 실패가 곧 계정 탈취의 증거는 아닙니다. 카메라 품질, 신분증 훼손, 외모 변화 등으로 정상 이용자에게도 재촬영이나 별도 확인이 필요할 수 있습니다. 반대로 신분증·얼굴 인증을 통과했더라도 기존 계정정보와 모순되는 정황이 있다면 추가 심사로 넘겨야 합니다.
복구 과정에서 주민등록번호·얼굴 이미지 등 개인정보를 다룬다면 수집 항목을 최소화하고 접근 권한, 저장 기간, 암호화, 파기 기준을 설정해야 합니다. 상담원이 이미지를 임의로 내려받아 개인 메신저로 전달하는 방식은 피해야 합니다.
.png)
.svg)
.svg)
