[Develop] 전화번호 인증 정책 논의

[psychology50]

(UI가 현재 정책과 조금 다름)

🟡 As-is

• 인증 코드 전송을 요청하면, 인증번호 받기 버튼이 비활성화 되면서 타이머(ttl = 5min)가 동작합니다.
• 타이머가 끝날 때까지 사용자는 인증번호 재전송을 수행할 수 없습니다.
• 이는 너무 잦은 요청을 방지하기 위함입니다. (저거 다 돈임)

🤔 문제점

• 전화번호를 잘못 입력했더라도 5분이 지나기 전까지 재전송 요청을 하지 못합니다.
• 최근에 이런 방식을 사용하는 서비스를 사용해봤는데 굉장히 불편하다는 것을 느꼈습니다.
• 하지만 그냥 풀어주면 악의적으로 수십 번 인증 번호 요청을 눌렀을 때 방지할 수 있는 방법이 없습니다. (다 돈이라니까요)

✒️ 현재 생각 중인 방법

1. ip를 확인하면서 10초에 5번 이상 보내는 사용자를 5분 동안 차단하는 방법.
   • 구현하는데 시간이 제법 소요될 수 있음. (개발 비용 높음)
   • 만약 와이파이로 연결해서 요청하다가, 데이터로 바꿔서 요청한다면? 여기까지 막는 게 이상한 건가?
2. 약간의 제약을 걸어서 무한대로 풀어주는 방법
   • 인증번호 받기 버튼을 누르면 재전송으로 전환
   • 단, 이전에 전송한 휴대폰 번호와 일치하는 경우에는 인증 시간이 만료되기 전까지 재전송에 실패
   • 마찬가지로 전화 번호를 바꾸면서 무한대로 요청이 가능함.

📢 천하제일 아이디어 대회

제가 떠올리지 못한 더 나은 해결책이 있는지 논의해보고자 합니다.
어떻게 하면 현재의 문제점을 개선할 수 있을까요?

[jinlee1703]

1. 애자일하게 사용자를 받아보기 전까지는 이 이슈에 대해 고려하지 않도록 한다.

재서님이 제시해주신 의견대로 무자비하게 '인증번호 재전송'을 하는 케이스의 경우 매우 심각한 비용을 초래할 수 있습니다. 하지만 이는 생각보다 급한 이슈는 아닐 수 있다고 생각합니다.

• 아직 우리 서비스가 배포되지 않았다는 점
• 10,000,000개 당 0.5$인 점

위 두 가지 사항을 고려하여 어플리케이션을 배포하기 직전, 혹은 배포 후에 고려해봐도 괜찮은 이슈일 수 있다고 생각합니다.

2. iOS 앱 자체에서 횟수를 카운트(앱을 종료했가 실행해도 카운트 유지가 가능한지?)하여 API를 통해 사용자 IP를 수집하여 차단하도록 한다.

• 같은 번호 N번까지 제한
• 전체 요청(다른 번호) M번까지 제한

1번 이슈의 경우에는 결국 근본적인 해결책은 되지 않는다고 생각합니다. 하지만 재서님의 2가지 방법에 대해서 사소한 문제점을 생각해봤습니다.

1. ip를 확인하면서 10초에 5번 이상 보내는 사용자를 5분 동안 차단하는 방법

• 이 경우 주기를 조금 느리게 가져가면 우회할 수 있는 방법일 수 있음

2. 약간의 제약을 걸어서 무한대로 풀어주는 방법

• 예전에 제가 회원가입을 시도할 때 아주 간혹 문자가 오지 않는 문제(이유는 지금도 모름)가 있었습니다. 문자를 찾지 못하거나 하는 이유로 같은 번호로 다시 수신하고 싶은 사용자의 경우에는 재서님의 2번 방법에 대한 아쉬움을 느낄 수 있다고 생각합니다.

[jinlee1703]

사실 저도 1번만 적으려다가, 결국 근본적인 해결이 되는 문제는 아니다보니 2번을 작성하게 되었습니다 ㅎㅎ

[psychology50]

2-2 의견에서 제가 생각지도 못한 문제가 있더라구요.
아마 이번 answer는 가장 괜찮은 정책을 빠르게 서칭해오는 사람의 것이 되지 않을까 싶네요.

[psychology50]

이렇게 제한을 거는 이유를 좀 더 고민해보았는데, 인증코드 발급 요청을 관대하게 풀어주는 경우 단순히 서비스를 공격하기 위함이 아니라 특정 전화번호 사용자를 공격하는 방법도 가능해집니다. (그것도 저희 서비스를 사용해서)
예를 들어, 제가 진우님의 전화번호를 입력해서 10,000,000번 인증 코드를 요청하는 상황을 가정하겠습니다.
그러면 공격자인 저의 정보는 노출되지 않고, 서비스의 과금 청구도 그리 심각하진 않지만, 저희 서비스 이름으로 특정 전화번호 소유자에게 스팸 폭탄을 날릴 수 있게 됩니다.

[jinlee1703]

1. 같은 번호로는 N번까지 제한 - Server에서 체크
2. 전체 요청(다른 번호 포함) M번까지 제한 - Server에서 체크
3. 1, 2 과정에서 추가적인 요청이 발생할 경우 - Server에서 체크한 횟수 초과 시 접근 제한(X일 동안)

• 현재는 Bastion host에서 NGINX에서 특정 IP 접속 제한을 하는 것을 생각하고 있습니다.

재서님 말씀대로 앱에서 요청하는 것이 아닌 API 요청을 통한 반복적인 요청의 경우에는 1, 2단계에서 iOS 앱를 통해 체크를 할 경우 막을 수 없다는 생각을 하게 되었습니다. 결국 인증코드 발급 요청 자체도 Server에 요청을 보내는 것이기 때문에, iOS와 WAS에서 두 번 작업하는 것보다 나을 수도 있겠다는 생각을 하게 되었습니다.

[asn6878]

진우님이 새로 작성해주신 서버에서 두단계의 검증을 거치는 방법이 저희가 해볼수 있는 방법중에는 최선이라고 생각합니다!

AWS-SNS에는 서비스 사용금액의 한도설정이 가능합니다.
그리하여, 한도금액을 안전한 예상범위에 두고, 트래픽을 모니터링 하며 직접 늘려주면, 만약 저희가 놓친 취약점으로 인해, 정말 순수 악의적인 의도의 공격에 당한다 하더라도 최악의 상황은 방지할 수 있지 않을까? 라는 생각입니다.

다만, 이방법은 운영인원들이 주기적으로 트래픽 발생량(회원가입 수)와 실제 SMS 발송량을 확인하며, 한도금액을 늘려주어야 한다는 불편함이 있긴 합니다.

[psychology50]

처음에는 순수하게 요금 폭탄 이슈를 고려하여 생성한 Discussions이지만, 그래봐야 한도가 100$이니까 폭탄에도 한계가 있어요.
그 정도면 (조금 비싼) 바보 비용으로 분담해서 경험삼아 넘어갈 수 있는 문제입니다.

하지만 지금은 최악의 상황이 바뀌었어요.
요금 폭탄이 문제가 아니라 사용자 뿐만 아니라 불특정 다수에게 서비스 신뢰성이 깨질 우려가 있습니다.
그래서 해당 논의의 중요성을 처음보다 높게 생각하고 있구요.

한도 범위는 지금으로도 충분할 거고, 이용자수가 급증하더라도 초기 유입을 제외하면 문자 전송 요청이 비례적으로 증가하진 않을 겁니다.

[psychology50]

iOS와 WAS 두 번 모두 검증하는 것이 번거롭고 개발 비용이 큰 게 사실입니다.

여기서부턴 그냥 순수하게 제 고민이예요. 😄
Server는 반드시 악의적인 공격에 대비해야 하는 것이 맞지만, Client에서는 그럼 검증이 불필요한가?
이는 Optional한 문제라고 생각합니다.

일단 Server에 요청을 보내봐야지 Client는 전송이 가능한지 아닌지 판단을 할 수 있게 되니, 그만큼 Server의 부담이 커질 수도 있겠죠.
그렇다고 Client에서도 검증을 수행해버리면, 정책이 수정될 때마다 양쪽 다 바꿔줘야 한다는 문제도 생길 수 있어서 이 또한 문제가 될 수 있을 거 같아요. (특히 iOS는 여러 버전의 앱이 존재할 수 있는데, Client에서도 검증을 하도록 하는 게 맞는가?)

여튼 논제에서 벗어난 이야기를 했는데, 지금은 진우님께서 내주신 의견이 가장 합리적이라고 판단이 됩니다.

[BangDori]

저는 진우님 2번 의견에서 살짝 수정한 방법입니다!

전화번호 인증 정책

기기마다 고유의 ID를 가지고 있고, Swift에서는 이를 얻어올 수 있는 것으로 알고 있습니다. 이에, 다음과 같은 규칙을 회원가입을 진행하는 device에 적용하는 것이 좋을 것 같습니다.

• 동일한 번호는 1일 최대 N회 제한
• 동일한 Device ID는 1일 최대 M회 제한

(추가) 인증번호 받기 버튼을 누르면 재전송으로 전환 및 전화번호 입력창 비활성화

전화번호 인증 정책과는 관련없는 개인적인 의견입니다!

인증번호 받기 버튼을 클릭하면 전화번호 입력창을 비활성화하는 것도 괜찮은 것 같습니다.

장점

• 개발 비용이 크게 감소한다.

단점

• 번호를 잘못 입력하였을 경우, 다시 메인 페이지로 이동한 후 회원가입 페이지로 이동하여야한다.

결론

개발 비용이 크게 감소한다는 장점이 있지만, 사용자 경험을 저하시킬 수 있다는 단점이 있습니다. 하지만 조금 더 생각을 해보면 단점이 단점이 아닐 수도 있다는 생각이 듭니다.

1. (대부분의 경우) 서비스 이용을 위한 정상적인 회원가입은 기기당 단 1회만 진행된다.
2. 전화번호 인증이 회원가입의 첫 번째 단계이기 때문에, 잘못된 번호를 입력하더라도 다시 회원가입 페이지로 이동하는데 큰 무리가 없다.

그렇기에 전화번호 인증 번호를 전송할 시, 전화번호 입력창을 비활성화 하는 방법에 대해 제안합니다.

[psychology50]

iOS에서만 보안을 고려한다는 건 굉장히 위험한 발상입니다.
전화번호 인증 요청 API는 외부로 노출되는 API이며, 마음만 먹는다면 어느 형식의 요청 포맷과 URL로 전송했을 때 인증 코드 발급이 가능한 지를 알아내는 것은 매우 쉬운 일이기 때문입니다.
(심지어 저희 코드는 모두 public으로 올려놨으니)

따라서 iOS 뿐만 아니라 Server(아마 Proxy에서 처리하겠죠)에서도 대응해야 하는 것이 마땅합니다.

[psychology50]

기기마다 고유 ID를 갖는 것은 아마 이 내용을 의미하는 것 같습니다.
그런데 Server의 입장에서는 이게 정말로 iOS 앱을 통해 생성된 UUID인지, 그냥 임의로 생성한 문자열 값인지 판독할 방법이 존재하지 않습니다.

이는 Server가 요청 제한을 걸기 위해 클라이언트에 의존하기 때문에 발생합니다.
충분히 조작 가능한 정보이며 그렇기 때문에 다른 기업에서도 ip 주소와 전송할 전화번호를 모두 검증한다고 보고 있습니다.

ip 주소도 조작이 가능이야 하겠지만..네이버에서도 인증 요청이 막히면 "장소를 이동하거나 기기를 바꾸어.."라는 방법을 명시한 것보면 거기까지 고려하진 않는 것 같아요.

[psychology50]

추가 제안에서 말씀해주신 것처럼 실제로 요청을 보내면 입력창을 block 시켜버리는 정책을 채택한 곳도 많은 것 같아요!
iOS단에서 개발 비용이 가장 적다는 것에서 이점은 맞지만, 결국 Server에서 보안 정책을 준수해야 하는 것은 변함이 없긴 할 거 같네요..🙄

기획..어렵다..

[BangDori]

고려해야할 부분이 정말 많네요 ㅠ

기획 너무 어렵다람쥐

[heejinnn]

저도 진우님의 2번 의견을 반영했습니다!

1. 제한 우선순위

저는 다른 번호로 M번 요청과 같은 번호 N번 요청 중 더 중점적으로 제한해야하는 건 같은 번호인 경우라고 생각합니다.
카카오톡도 동일한 번호에 대해서만 제한하는 방식이 사용되고 있으며, 다른 번호로의 요청은 같은 번호로 요청하는 것보다 위험요소가 적다고 판단이 들어 동일한 번호에 제한을 우선적으로 적용하는 것이 적절하다고 생각했습니다.

• 같은 번호 N번까지 제한

2. 재전송 기능 관리

현재 문제는 [전화번호를 잘못 입력한 경우 사용자는 만료시간 동안 대기해야한다 -> 제한을 풀어주면 악의적 요청 가능해서 위험 부담이 있다] 입니다.
지니에서 인증번호 요청하는 방법인데 인증번호 요청한 경우 같은 번호라면 재전송을 막고, 다른 번호라면 재전송을 활성화하더라고요

• 같은 번호라면 -> 재전송 비활성화
• 다른 번호라면 -> 재전송 활성화

이렇게 하면 전화번호 잘못 입력한 경우에도 적절하게 대응할 수 있으며 인증번호 만료시간까지 대기할 필요가 없습니다.

정리

결론적으로 동일한 번호에 대한 제한을 우선시하고, 재전송 기능을 적절하게 관리하여 사용자 경험을 향상시키는 것이 좋다고 생각합니다.
정리하면 아래와 같습니다.

• 동일한 번호에 대한 제한만 우선적으로 적용하여 사용자 불편 최소화
• 재전송 기능을 관리하여 잘못된 번호 입력 시에도 적절한 대응 제공

[psychology50]

만약 악의적인 의도를 가진 사용자가 번호를 바꿔가며 여러 전화번호(소유자는 Pennyway 서비스에 전혀 연관 없는 사람)로 문자를 전송한다면, 이 부분에 대해서 방지할 수 있을까요?
동일한 번호 제약이 한 명의 사용자에게 스팸 폭탄을 던지는 것을 방지하기 위함이라면, 같은 ip주소 제약은 불특정 다수에게 스팸을 전송하는 것을 방지하기 위함이라 보고 있습니다.

이에 대한 희진님의 의견이 궁금해요.

[heejinnn]

음 "악의적인 의도를 가진 사용자가 번호를 바꿔가며 여러 전화번호(소유자는 Pennyway 서비스에 전혀 연관 없는 사람)로 문자를 전송한다면," 이 부분에 대해서 저도 우려하고 있지만, 더 중점적으로 고려해야하는 건 동일한 번호에 대한 횟수 제한이 먼저라고 생각했습니다. 불특정 다수에게 스팸을 전송하는 것보다 한명의 사용자에게 스팸을 전송하는 경우가 더 많을 것이라고 판단했었어요. 다만 이건 제 개인적인 생각이어서,,,
다양한 악의적 의도를 고려해야한다는 게 어렵네요 ㅜ

[psychology50]

동일한 번호와 불특정 다수의 번호에 대한 방지책은 모두 마련되어야 하는 것이 맞다고 봐요.
물론 불특정 다수에게 스팸 폭탄을 뿌릴 수 있는 문제가 가장 최악의 케이스고, 그렇기에 동일한 번호에 대한 횟수 제한이 좀 더 우선적으로 고려되어야 한다는 말에 이견은 없습니다.

하지만 지금은 여러 공격 루트를 파악하고 방어할 전략을 세우는 단계라, 우선 순위보다는 더 많은 경우의 수를 탐색하는 것에 집중하는 게 좋을 것 같아요!

그리고 희진님 의견 중에 같은 번호는 만료 시간까지 대기시키고, 다른 번호는 재전송 활성화 부분이 재밌는 아이디어 같아요.
아마 iOS에서 방지책은 이 정도가 알맞을 것 같습니다.

[yanni13]

1. 횟수제한을 걸고 인증시간을 줄이자.

약간의 제약을 걸어서 무한대로 풀어주게 되면 말씀하셨던 것처럼 저희 앱을 통해 스팸 및 악용의 문제를 증가시켜 사용자가 앱을 사용하기도 전에 (즉 신뢰를 얻기도 전에) 거부감을 느끼게 될 거 같습니다.

그래서 하루에 보낼 수 있는 인증번호의 횟수를 제한하되, 그에 대한 불편함이 발생한다면, 인증 코드 전송을 요청하면, 인증번호 받기 버튼이 비활성화 되면서 타이머(ttl = 5min)가 동작 하는걸 3분 혹은 2분으로 시간을 줄이게 된다면 사용자가 불편함을 느끼는 부분이 크게 감소할 거 같습니다.

추가로 병준님 의견 중 인증번호 받기 버튼을 누르면 재전송으로 전환 및 전화번호 입력창 비활성화 부분도 같이 적용하게 된다면, 사용자 경험을 저하시킨다는 단점도 개선될 것이며 사용자 응답을 개선하는데 도움이 될 거 같습니다.

[psychology50]

잘 이해가 안 되는 부분이 있어요!

인증 코드 전송을 요청 → 5분동안 인증번호 받기 버튼 비활성화

여기서 인증 번호 만료 시간 자체를 줄이자는 건가요, 아니면 만료는 5분까지인데 비활성화를 막는 시간만 줄이자는 건가요?

[yanni13]

인증번호 만료시간 자체를 줄이자는 의견입니다! 만료시간 자체를 줄이면 그 시간동안 폼 비활성화도 막히니까 사용자 입장에서 불편함이 감소될 거 같습니다

[psychology50]

앗, 그런데 그러면 사용자가 2~3분 내로 인증번호를 입력해야 하는 타임어택이 발생해요.

요청이 가고 문자가 발송되는데 걸리는 지연 시간까지 고려하면 사실상 1분 내로 타이핑.
가능하긴 한데, 오히려 너무 빡빡하진 않을까요?

[yanni13]

다른 앱에서도 보통 지연시간을 3분 내로 두고있는걸로 알고있습니다 ! 약간의 제약을 풀어 인증번호를 받았음에도 재전송을 누를 수 있다던가 하는 기능이 있다면 만료시간을 5분정도 가져도 괜찮겠지만 만약 1일 인증문자를 받을 수 있는 횟수제한을 걸게된다면 저라면 5분동안 ,, 기다리기가 힘들거 같습니다

[psychology50]

아하, 좋은 의견이라 생각합니다!

신얀님께서 내주신 의견은 이번 Discussions과는 다소 상관 없는 이야기이지만, 재전송 정책에 대해서 다른 대안이 될 수 있을 거 같아요.

1. 재전송 버튼 활성화
2. 횟수 제한 내에서 만료시간(2~3min)이 지나야 재전송 요청 허용

두 가지 방법 중 어떤 게 더 나을지에 대해서 또 이야기해볼 필요가 있을 것 같습니다