OTP SMS 전송과 사기

일회용 비밀번호가 유출되는 지점, 전송 결과 수신 확인(DLR)으로 알 수 있는 것과 알 수 없는 것, 그리고 OTP 흐름을 정상적으로 유지하는 통제 장치와 지표를 설명합니다.

practitioner · 3 분 분량 · 레슨 5 / 8

일회용 비밀번호는 입력되는 순간 해당 번호를 통제하고 있음을 증명합니다. 신원을 증명하지는 않으며, 전송 결과 수신 확인도 사람이 코드를 읽었다는 사실을 증명하지 않습니다. 확인 절차가 유효한지는 전송, 가로채기, 번호 재활용, 그리고 입력 양식 자체에 따라 결정됩니다.

주요 정보

  • OTP는 신원이 아니라 그 순간 해당 번호를 통제하고 있음을 증명합니다.
  • 전송 결과 수신 확인은 네트워크 상태를 알려 줄 뿐, 사람이 코드를 읽었다는 사실을 알려 주지 않습니다.
  • 번호 재활용, SIM 스왑, 착신 전환, 피싱이 코드가 유출되는 주요 경로입니다.
  • 요청 횟수 제한, 발신자 등록, 번호 확인은 악용을 줄여 주지만, 어느 것도 신원을 증명하지 않습니다.

OTP가 증명하는 것

OTP는 한 가지 질문에 답합니다. 지금 이 사용자가 이 번호로 메시지를 받을 수 있는가? 이는 세션을 사용자가 통제하는 무언가와 연결하므로 계정 복구와 로그인에 유용합니다. 그러나 신분증은 아닙니다. 번호는 재활용되거나, 새 SIM으로 옮겨지거나, 착신 전환되거나, 같은 가구의 다른 사람이 읽을 수 있습니다.

이 차이는 설계 단계에서 중요합니다. 가치가 낮은 작업이라면 OTP가 적절한 수준입니다. 송금, 비밀번호 변경, 수취인 추가 같은 작업이라면 코드에 두 번째 확인을 더하십시오. 지연 처리, 기존 세션에서의 확인, 알려진 채널로의 회신 전화, 수동 검토 등이 해당됩니다. 코드는 하나의 요소일 뿐, 판단의 전부가 아닙니다.

전송 경로와 코드가 유출될 수 있는 지점

  1. 애플리케이션
  2. SMPP 게이트웨이
  3. SMSC
  4. HLR / HSS
  5. MSC / MME
  6. 단말
  7. 전달 확인
코드를 전달하는 같은 경로가 코드를 엿보거나, 지연시키거나, 잘못된 단말로 보낼 수 있는 지점도 만듭니다. 출처: 3GPP TS 23.040: SMS 아키텍처
텍스트 설명

애플리케이션이 코드를 게이트웨이에 제출하면, 메시지 센터가 가입자를 조회하고, 가입자를 담당하는 교환기가 단말로 전달합니다. 전송 결과 수신 확인은 같은 경로를 따라 돌아옵니다. 코드는 애플리케이션, 단말, 번호 자체, 또는 코드를 받는 사람을 통해 유출될 수 있습니다. 네트워크 경로는 전송을 설명할 뿐, 코드를 공유하는 사람을 설명하지는 않습니다.

OTP가 유출되는 지점

SIM 스왑은 번호를 새 카드로 옮깁니다. 공격자가 매장이나 고객 지원 창구에 자신이 소유자라고 믿게 만들면, 다음 코드는 새 SIM으로 갑니다. 번호 재활용은 공격자 없이도 같은 결과를 낳습니다. 통신사가 휴면 번호를 다른 사람에게 재할당하면, 새 소유자가 이전 계정으로 보낸 코드를 받습니다. 두 경우 모두 번호가 최근에 번호이동되었거나 재할당되었는지 확인해야 하는 이유입니다.

착신 전환과 음성사서함 텍스트 변환은 메시지를 다른 수신함으로 보냅니다. 피싱은 입력 양식을 복제해 코드를 직접 수집하므로 네트워크에서는 공격이 보이지 않습니다. 네트워크 경로상의 가로채기는 드물고 애플리케이션이 통제할 수 없는 영역입니다. 현실적인 대응은 더 긴 코드가 아니라 두 번째 인증 요소입니다. 정의는 OTP 용어집 항목을 참고하십시오.

도움이 되는 통제 장치

하나의 번호, IP 주소, 단말이 코드를 요청할 수 있는 빈도를 제한하십시오. 유효 시간을 짧게 하고, 코드당 한 번만 사용하게 하며, 코드를 요청한 세션에 묶으십시오. 발신자를 등록하고 내용은 평이하게 유지하십시오. 마케팅처럼 보이는 코드는 필터링될 수 있고, 필터링된 코드는 로그인이 아니라 고객 문의로 이어집니다.

번호를 신뢰하기 전에 확인하십시오. SMS를 받을 수 없는 번호, 최근에 번호이동된 번호, 재설정 이력이 있는 번호에는 두 번째 단계를 적용해야 합니다. 중요한 작업에는 기존 세션이나 두 번째 채널을 요구하십시오. 요청, 제출, 전송 결과 수신 확인, 코드 입력을 별도의 이벤트로 기록하면 전송 문제와 사용자 문제를 구분할 수 있습니다.

코드 자체도 같은 주의를 기울여 설계하십시오. 암호학적 난수원에서 생성하고, 해시를 저장하며, 몇 분 안에 만료시키고, 한 번의 성공적인 사용만 허용하며, 코드별·세션별 시도 횟수를 제한하십시오. 번호의 존재 여부를 드러내지 마십시오. 재시도로 인해 완료되지 않는 계정이 열리지 않도록, 발송 전에 계정 레코드를 생성하십시오.

다섯 가지 지표와 정의

각 지표는 서로 다른 질문에 답합니다. 어느 지표도 신원을 측정하지 않습니다.
지표정의알 수 있는 것
전송률전송 완료 수신 확인 수를 제출된 메시지 수로 나눈 값네트워크가 메시지를 수락했는지 여부. 사람이 읽었는지는 알 수 없음
완료율입력된 코드 수를 전송된 메시지 수로 나눈 값메시지와 입력 양식이 사용자에게 제대로 작동했는지 여부
전송 소요 시간제출부터 전송 결과 수신 확인까지의 중앙값과 95번째 백분위수경로가 느린지, 사용자가 재전송하기 전에 얼마나 기다리는지
재전송률재전송 수를 전송된 메시지 수로 나눈 값사용자가 너무 오래 기다리는지, 잘못 입력하는지, 첫 메시지를 아예 보지 못하는지
차단율위험 규칙으로 거부된 요청 수를 시도 수로 나눈 값규칙이 너무 엄격한지, 너무 느슨한지, 또는 트래픽이 악의적인지

시장, 발신자, 경로별로 추적하십시오. 전 세계 단일 평균은 실패하고 있는 경로를 가립니다.

발송이 아니라 흐름 전체를 측정하십시오

메시지 ID가 반환된 발송이 곧 전달된 코드는 아닙니다. 전달된 코드가 곧 완료된 로그인도 아닙니다. 직접 통제하는 이벤트, 즉 제출, 전송 결과 수신 확인, 코드 입력, 성공으로 퍼널을 구성하십시오. 그다음 서비스 제공사의 데이터와 비교하십시오. 자체 전송률과 서비스 제공사의 전송률 사이에 차이가 있다면, 메시지가 단말에 도달하지 못한 것이 아니라 전송 결과 수신 확인이 처리기에 도달하지 못한 것일 수 있습니다.

지표가 움직이면 흐름을 검토하십시오. 전송률은 안정적인데 완료율이 떨어지면 입력 양식, 코드 만료 시간 또는 발신자를 살펴봐야 합니다. 제출률은 안정적인데 전송률이 떨어지면 경로, 번호 또는 콘텐츠 필터를 살펴봐야 합니다. 재전송이 늘면 전송 소요 시간을 살펴봐야 합니다. 바꾸기 쉬운 단계가 아니라 데이터가 가리키는 단계를 고치십시오.

흐름 전체에 대한 검토 일정을 정하십시오. 번호는 주인이 바뀌고, 경로는 변경되며, 템플릿은 낡습니다. 출시 시점에 잘 작동하던 흐름도 같은 코드와 같은 서비스 제공사를 쓰면서 여섯 달 뒤 조용히 실패할 수 있습니다.

학습 내용 확인

  1. 사용자가 코드를 친구에게 전달했습니다. 그래도 코드가 신원을 증명합니까?

    아닙니다. 그 순간 해당 번호가 코드를 받을 수 있었다는 사실만 증명합니다. 코드를 가진 사람은 누구나 사용할 수 있습니다.

  2. 전송 결과 수신 확인에는 전송 완료로 표시되었지만 사용자는 코드를 보지 못했습니다. 무엇을 확인해야 합니까?

    단말 상태, 메시지 앱과 스팸 필터, 발신자, 그리고 경로입니다. 전송 완료 수신 확인은 네트워크의 상태이지, 단말 화면에 표시되었다는 뜻이 아닙니다.

  3. 완료율이 전송률보다 유용한 이유는 무엇입니까?

    전송은 네트워크에서 끝납니다. 완료율은 사용자, 코드 만료 시간, 입력 양식까지 포함하며, 대부분의 실패는 바로 여기서 드러납니다.

답은 요청 시 공개됩니다. 채점, 저장, 전송은 하지 않습니다.

자주 묻는 질문

OTP는 2단계 인증과 같은 것입니까?

OTP는 두 번째 인증 요소가 될 수 있습니다. OTP만으로는 하나의 요소, 즉 그 순간 번호를 보유하고 있다는 사실일 뿐입니다.

코드가 길수록 더 안전합니까?

길이는 추측 공격에는 도움이 되지만, SIM 스왑, 착신 전환, 피싱은 막지 못합니다. 중요한 작업에는 두 번째 확인을 추가하십시오.

전송 결과 수신 확인으로 사용자가 코드를 읽었음을 증명할 수 있습니까?

아닙니다. 전송 완료, 만료, 미전송 같은 네트워크 상태를 알려 줄 뿐입니다. 읽거나 입력했는지에 대해서는 아무것도 알려 주지 않습니다.

자동으로 재전송해야 합니까?

타이머가 아니라 사용자의 요청에 따라 재전송하십시오. 자동 재전송은 비용을 몇 배로 늘리고 경로 문제를 가릴 수 있습니다.

무엇을 기록해야 합니까?

요청, 제출과 그 메시지 ID, 전송 결과 수신 확인과 그 상태, 그리고 코드 입력 결과입니다. 각각을 타임스탬프가 있는 별도의 이벤트로 보관하십시오.

수신 확인에는 전송 완료로 나오는데 사용자는 아무것도 받지 못합니다. 사업자를 바꾸기 전에 무엇을 확인해야 합니까?

먼저 귀사 측을 확인하십시오. 전송 결과 수신 확인은 네트워크가 메시지를 수락했다는 의미일 뿐, 단말기에 무엇이 표시되었는지를 알려 주지는 않기 때문입니다. 템플릿을 SMS 콘텐츠 사전 점검으로 확인하고, SMS 세그먼트 계산기로 세그먼트 수를 세고, SMPP 및 DLR 코드 디코더로 제출 코드와 수신 확인 코드를 해석하십시오. 이상이 없다면 트래픽을 옮기기 전에 실패하는 대상 국가를 귀사 단말기로 한 번에 하나씩 테스트하십시오.
  • SMPP와 HTTP로 연결하기

    바인드, 윈도우, 수신 확인을 깨뜨리지 않고 테스트 경로를 운영으로 전환하는 방법: 바인드, 처리량, keep-alive, 인코딩, 콜백, 장애 처리.

  • RFQ 및 RFP 템플릿 팩

    SMS 도매, eSIM 및 데이터, IoT, 중국 연결 요청을 위한 항목 목록과, RFQ로 바로 보낼 수 있는 온라인 체크리스트.

  • 경로 테스트 샘플 보고서

    경로 테스트 보고서의 비식별화된 정적 샘플: 경로 테스트의 확인 항목, 실패를 읽는 방법, 경로 검토를 촉발하는 조건.

실무에 적용하기

트래픽, 대상 국가, 필요한 측정을 알려 주시면 다음 단계를 안내해 드립니다.