CAPTCHA를 프라이빗 액세스 토큰으로 대체하기

♪ ♪

안녕하세요 저는 Tommy Pauly입니다 저는 여러분의 앱과 웹사이트가 애플과 산업 전반의 사기 방지 업체와 협력하여 CAPTCHA 사용을 줄이는 방법을 공유하려고 합니다 오늘 다룰 주제는 Private Access Tokens와 이것을 사기 방지의 강력한 도구로 사용하는 법 여러분이 운영하는 서버에 Private Access Tokens를 지원하는 법을 다루고 앱에서 사용하는 법도 살펴보죠

Private Access Tokens를 소개하기 위해 처음부터 CAPTCHA를 사용하는 이유를 설명할게요 웹 사이트에 새 계정으로 가입하거나 기존 계정으로 로그인할 때 이런 형태의 CAPTCHA를 보셨을 겁니다 때로는 CAPTCHA에서 버튼만 누르면 되지만 작성하기 어려운 것도 있죠

이런 것 때문에 방해받기 싫으실 겁니다 저는 싫어하죠 이런 경험이 존재하는 이유는 사기 활동을 방지하기 위해서입니다

운영하는 서버가 사기 활동으로 가득하기 싫겠죠 계정을 생성하고 제품을 구매하는 일부 시도는 진짜 사용자에 의한 겁니다 하지만 공격자나 봇으로 인한 다른 시도도 있죠 안타깝게도 사기를 방지하는 일반적 도구인 CAPTCHA 등의 방식은 사용자가 앱이나 웹 사이트를 이용하기 어렵게 합니다 좋은 경험과 사기 방지의 균형을 찾는 건 아주 힘든 일이죠

CAPTCHA로 인해 사용자 경험이 느려지거나 복잡해집니다 공격을 막는 시도로 인해 귀중한 고객을 잃을 수도 있죠

CAPTCHA는 개인정보 보호 위험도 있습니다 클라이언트를 신뢰할 수 있는지 판단하고 간편한 CAPTCHA를 사용하기 위해 서버는 클라이언트의 IP 주소를 이용하여 클라이언트를 추적하거나 핑거프린팅하죠 이런 식의 추적은 Safari, Mail의 개인 정보 보호 및 iCloud 비공개 릴레이의 개인정보 보호 방침과 어긋납니다

CAPTCHA는 접근성에도 큰 문제를 초래하죠 봇의 접근을 막으려다가 장애나 언어 장벽이 있는 진짜 인간까지 막습니다 더 좋은 방법이 있죠 여러분의 웹 사이트를 처음 이용하는 사용자라도 Safari와 같은 브라우저나 앱을 통해 로딩하면 봇이 흉내 낼 수 없는 동작을 수행하게 됩니다 일단 iPhone, iPad, Mac을 가지고 있어야 하고 기기의 잠금을 풀기 위해 비밀번호나 Touch ID, Face ID를 사용해야 하죠 또한 Apple ID로 기기에 로그인되어 있습니다 그리고 코드 서명된 앱을 실행했죠

이 정보는 서버에서 클라이언트를 신뢰하게 하고 CAPTCHA에 의존하지 않고 사기를 방지할 수 있습니다 또한 클라이언트를 추적하여 개인 정보를 침해하지 않죠 Private Access Tokens는 서버가 자동으로 클라이언트를 신뢰할 수 있게 하고 iOS 16과 macOS Ventura에 처음 도입됩니다 토큰의 원리를 설명하기 전에 사용하는 장면을 보여 드리죠 정말 좋아하실 거예요 전 파이낸셜 타임스 웹사이트에서 기사를 읽으려고 합니다 시나몬 번을 정말 좋아하죠 같은 사이트를 2개의 휴대 전화에 띄웠습니다 하나는 iOS 15가 설치돼 있고 다른 건 iOS 16을 설치돼 있죠 iOS 16은 Private Access Tokens를 지원합니다 iOS 15 폰부터 시작하죠 먼저 '로그인'을 클릭하고 계정과 비밀번호를 입력합니다 그런데 CAPTCHA가 나오는군요 기사를 읽기 전에 글자를 입력해야 합니다

이제 같은 과정을 iOS 16에서 해 보죠 Private Access Tokens를 지원합니다 바로 접속할 수 있죠 이렇게 하면 많은 사람이 많은 시간을 절약하고 고객들도 신뢰를 고맙게 생각할 겁니다 Private Access Tokens는 서버가 CAPTCHA를 피하도록 IETF Privacy Pass 작업 그룹에서 표준화 중인 기술을 사용하죠 Apple은 산업계와 함께 표준화 작업 중입니다

이 절차를 활용하면 서버가 토큰을 요청할 때 새로운 HTTP 인증 메서드인 PrivateToken을 사용하죠 이 토큰은 RSA 블라인드 서명을 사용하여 클라이언트가 증명 확인을 통과했다는 사실을 암호학적으로 서명합니다 이 서명은 링크할 수 없어 토큰을 받는 서버가 토큰의 유효성만 확인할 수 있고 클라이언트 정체를 알아내거나 장기간에 걸쳐 인지할 수 없죠 이 절차의 원리를 설명하겠습니다

먼저, iOS나 macOS 클라이언트가 HTTP로 서버에 접속하면 서버가 PrivateToken 인증 방식을 이용한 과제를 전송하죠 과제는 서버가 신뢰하는 토큰 발급 기관을 상세합니다

클라이언트가 토큰을 받아야 할 때 iCloud 검증자에 연락하여 토큰 요청을 보내죠 이 토큰 요청은 블라인드 되어 서버 과제와 연결될 수 없습니다 검증자가 기기 증명을 시행할 때 기기의 Secure Enclave에 저장된 인증서를 활용하고 계정이 정상임을 인증합니다

검증자는 단위를 제한하거나 클라이언트 기기가 정상 패턴을 따랐는지 확인하거나 침투당했거나 집단의 일부로 사용됐는지 판단합니다

만약 클라이언트를 인증할 수 있으면 검증자가 발급 기관에 새 토큰 발행을 요청하죠

토큰 발급 기관은 요청받을 때 클라이언트에 관해 전혀 모릅니다 하지만 iCloud 검증자를 신뢰하기 때문에 토큰에 서명하죠

클라이언트는 서명된 토큰을 받아 변환하는데 '언블라인딩'이라고 하는 절차를 통해 기존 서버가 인증할 수 있게 합니다

마지막으로 클라이언트가 서명한 토큰을 서버에 보여 주죠 서버는 발급 기관이 토큰을 서명했는지 확인할 수 있지만 토큰을 이용하여 클라이언트를 확인하거나 인지할 수 없습니다 이 기술을 여러분의 서버에 어떻게 활용할 수 있을까요? 서버에 Private Access Tokens를 채택하는 단계는 3개입니다 먼저 토큰 발급 기관을 선택하셔야 하죠 둘째, 서버에서 클라이언트를 인증할 때 HTTP 인증 과제를 전송해야 합니다 셋째, 클라이언트가 전송한 토큰을 인증해야 하죠 여러분이 선택한 토큰 발급 기관은 신뢰할 수 있는 제공자로 여러분이 인증하는 토큰을 서명할 수 있습니다 기존 CAPTCHA 제공자일 수도 있고 웹 호스팅 서비스일 수도 있고 콘텐츠 전송 네트워크라고 하는 CDN일 수도 있죠 iOS 16과 macOS Ventura 베타에서는 먼저 테스트를 시작할 수 있는 2개의 토큰 발급 기관이 있습니다 Fastly와 Cloudflare는 CDN으로 Privacy Pass 표준을 개발 중이고 발급 기관 서비스를 공개했죠 다른 CAPTCHA 제공자나 웹 호스팅 서비스, CDN도 Apple 기기와 호환되는 토큰 발급 기관을 운영할 겁니다 발급 기관 등록은 올해 말 register.apple.com에서 가능하죠

특정 토큰 발급 기관을 이용하는 것이 클라이언트가 접속하는 사이트를 알아보는 방법으로 사용되어 개인 정보 문제가 없도록 하는 게 중요합니다 토큰 발급 기관은 대규모 서비스여야 하며 적어도 수백 대의 서버를 운영해야 하죠

클라이언트가 여러분의 서버에 접속할 때 HTTP 인증 과제를 보내 토큰을 요구할 수 있습니다 PrivateToken 방식을 사용해서 말이죠 이를 할 수 있는 두 가지 선택지가 있습니다 기존 CAPTCHA나 사기 방지 제공자와 협력하여 그들의 스크립트에 과제를 넣어 자동으로 처리되도록 하거나 여러분의 서버에서 직접 과제를 보낼 수도 있죠

웹 사이트의 일부로 이 작업을 하신다면 과제는 주 URL의 서브 도메인인 퍼스트 파티 도메인에서 보내야 합니다 여러분의 사이트에 임베드 된 별도 서드 파티 도메인은 안 되죠

클라이언트가 토큰을 반환하면 발급 기관의 공개 키를 이용하여 유효성을 확인해야 합니다 클라이언트가 토큰을 여러 번 제시하려는 시도의 재전송 공격을 방지하기 위한 확인도 시행하십시오 토큰은 1회만 사용하게 되어 있습니다 이전에 어떤 토큰을 전송했는지 기억하여 재전송 공격을 방지하거나 과제에서 보낸 고윳값으로 토큰에 서명하게 할 수 있죠

여러분의 사이트는 인증 과제에 반응하지 않는 이전 기기에서도 잘 작동해야 합니다 따라서 인증이 메인 페이지 로딩을 막지 않도록 하고 클라이언트를 신뢰하는 선택적 방법으로 사용하십시오 Safari나 WebKit를 통해 접속하는 웹 서버는 자동으로 작동하지만 앱에서 Private Access Tokens를 직접 사용할 수도 있죠 Private Access Tokens는 Apple ID로 로그인된 기기와 iOS 16 또는 macOS Ventura를 요구합니다 Apple ID는 검증 목적으로만 사용하며 토큰을 받는 서버에 공유하지 않죠 WebKit나 URLSession을 사용하면 앱 내부의 토큰으로 HTTP를 이용해 서버에 접근할 수 있습니다 앱을 실행 중일 때 서버에서 과제를 받으면 시스템이 자동으로 인증을 위해 토큰을 전송하죠

만약 URLSession을 이용한다면 Private Access Tokens가 작동하도록 특별한 작업을 할 필요가 없습니다 URLSession은 자동으로 과제에 반응하며 PrivateToken HTTP 인증 방식을 사용하죠 하지만 앱을 전면에서 실행하지 않거나 기기가 Apple ID에 로그인되어 있지 않아 토큰 회수에 오류가 발생하면 여러분의 앱이 토큰 과제를 포함한 401 HTTP 응답을 수신합니다 이를 통해 여러분의 앱이 토큰 과제를 받았는지 알 수 있어 여러분의 유스 케이스에 맞게 오류를 처리할 가능성을 제공하죠 모두에게 나은 앱과 웹 사이트 경험을 위해 Private Access Tokens를 이용하여 CAPTCHA 사용을 피하십시오 여러분의 서버가 토큰을 전송하고 검증할 수 있게 하세요 그리고 여러분의 앱에 URLSession 또는 WebKit를 사용해 Private Access Tokens를 자동으로 지원하십시오 여러분이 만들 CAPTCHA 없는 경험을 기대합니다