패스키는 함정인가 — 피싱 저항과 통제권 사이의 다이얼

패스키에 대한 불안은 프로토콜의 결함인가, 아니면 그 프로토콜을 올려 놓은 플랫폼에 대한 불신인가?

도입

한국 시간 10월 12일 새벽, 해커뉴스 1면에 「Passkeys are a trap」라는 제목의 글이 올라와 1144점을 받았다. 원문은 Substack 블로그 Non-Functional에 10월 10일 자로 실린 「Passkeys are a trap. Do not use them.」이고, 글머리에 대상 독자를 「웹의 비기술적 시민」이라고 못 박아 두었다. 결론은 간단하다. 패스키를 거부하고, 비밀번호보다 나은 보안이 필요하면 TOTP를 쓰라는 것이다.

이 논쟁은 갑자기 나온 것이 아니다. 3주 남짓 전인 9월 18일에는 워릭 대학 컴퓨터과학 학생 Ethan Hawksley의 「I don’t like passkeys」가 853점을 받았다. 두 글은 결론이 비슷해 보이지만 근거가 전혀 다르다. Hawksley는 계정 잠김과 복구, 기기 분실, 이식성이라는 「지금 일어나는 일」을 말했다. Non-Functional의 글은 원격 증명(remote attestation)이라는 「앞으로 켜질 수 있는 스위치」를 말한다.

해커뉴스의 반응은 크게 갈렸다. 원문의 문제의식에 공감하는 쪽과, 피싱이라는 단어가 거의 등장하지 않는 패스키 비판은 핵심을 빠뜨렸다는 쪽이다. 이 글은 두 진영의 주장을 사실 관계와 해석으로 나눠 정리하고, 논쟁이 사실은 서로 다른 층위, 즉 WebAuthn이라는 프로토콜과 Apple·Google의 동기화 구현을 섞어 말하고 있다는 점을 짚어 본다.

「숨은 다이얼」 주장의 구조

원문의 논리는 단계적으로 쌓인다. 먼저 저자는 비밀번호가 불안하다는 데 동의한다. SolarWinds 서버가 solarwinds123이라는 비밀번호를 썼다는 사례, 하와이 비상관리국 사진 배경의 포스트잇에 비밀번호가 찍혀 있었던 사례를 든다. 그다음 TOTP를 칭찬한다. RFC 6238이라는 공개 표준이 있어 특정 앱에 묶이지 않고, 노트북이든 90년대 게임보이든 시간을 셀 수 있는 장치면 코드를 만들 수 있으며, 시드(seed)를 어디에 보관할지도 사용자가 정한다는 것이다.

이어서 저자는 「패스키」라는 이름 아래 실은 여러 종류의 자격 증명이 묶여 있다고 주장한다. 복사 가능/불가, 이전 가능/불가, 하드웨어 기반/소프트웨어 기반, 사용자 존재 확인 여부, 사용자 검증 여부, 증명(attested) 여부. 그는 사양이 「표준이라기보다 부품 카탈로그처럼 읽힌다」고 쓰고, FIDO Alliance가 이 모든 것을 같은 이름으로 부른 것은 사용자가 세부를 들여다보지 않게 하려는 의도라고 본다.

핵심은 마지막 항목이다. WebAuthn에는 인증기 데이터 플래그(authenticator data flags)가 있어 사이트가 UP(사용자 존재), UV(사용자 검증), BE(백업 가능) 등을 알 수 있다. 소프트웨어는 이 플래그를 거짓으로 보고할 수 있지만, 원격 증명이 붙은 패스키는 위조할 수 없다. 저자의 시나리오는 이렇다. 지금은 대부분의 사이트가 증명을 요구하지 않지만, 사용자 대다수가 영향을 받지 않는다고 판단되는 시점에 사이트가 스위치를 올리면, LineageOS 같은 커스텀 OS나 직접 만든 패스키 관리자를 쓰는 사람은 로그인할 수 없게 된다. 저자는 여기서 더 나아가 정보기관과 빅테크가 「승인되지 않은 소프트웨어의 실행을 막는 데」 패스키를 쓸 수 있다고 쓴다. Chrome에서 uBlock Origin 지원이 제거된 일을 예로 들며, 원격 증명이 있으면 그런 정책을 따르지 않는 다른 브라우저까지 막을 수 있다고 주장한다.

흥미로운 것은 글의 각주다. 저자는 증명 표시가 AT 플래그에 있다고 했던 초판의 설명이 틀렸다고 정정했고, 사이트가 사용자 패스키의 증명 지원 여부를 사전에 조회할 수 있다는 암시도 틀렸다고 고쳤다. 마지막 추가 각주에서는 패스키가 도메인에 묶여 중간자 공격에 강하다는 점, 즉 패스키의 가장 큰 장점을 「언급하지 않았다」고 스스로 적는다. 그리고 증명 걱정 없이 높은 보안을 원하면 YubiKey 같은 보안 키를 쓰라고 권한다.

반론: 프로토콜의 사실과 플랫폼의 사실

해커뉴스 상위 코멘트 가운데 가장 기술적인 반론은 agwa의 것이다. (직접 인용은 아니고, 코멘트의 요지를 요약) 증명은 자격 증명 등록 시점에만 요구할 수 있고, 로그인 시점에 소급해서 요구할 수는 없다. 브라우저는 사이트가 증명을 요청하면 권한 프롬프트를 띄운다. Apple의 패스키 구현은 증명을 지원하지 않으므로, 대다수 사용자가 증명된 패스키를 쓰게 될 때까지 기다렸다가 스위치를 올린다는 시나리오는 그럴듯하지 않다. 다만 agwa는 증명이 WebAuthn 사양의 「얼룩」이라는 점에는 동의했고, 소비자 사이트가 등록 시 증명을 요구하기 시작하면 강하게 비판받아야 하며 그때는 권고를 재검토해도 된다고 덧붙였다.

lxgr의 코멘트는 원문의 분류 자체를 겨눴다. (직접 인용은 아니고, 코멘트의 요지를 요약) WebAuthn에서 사용자 존재 확인은 항상 참이어야 하므로 「사용자 비존재 패스키」라는 범주는 사양에 없다. 「이전 가능/불가」라는 속성도 WebAuthn이나 FIDO에 존재하지 않고, 비밀번호 관리자 간 이전은 구현의 선택일 뿐 사이트와 무관하다. 하드웨어 기반 여부와 복사 가능 여부는 증명 없이는 사이트가 신뢰할 수 없으니 결국 증명 하나로 환원된다. 그렇게 정리하면 사이트가 실질적으로 강제할 수 있는 것은 사용자 검증 요구 여부, 즉 패스키를 1요소로 쓰느냐 2요소로 쓰느냐 정도라는 것이다. lxgr는 WebAuthn에 사용자에게 적대적인 함정이 생길 여지가 있다는 데는 동의하면서, 비판자들이 「인식론을 끌어올려야 한다」고 썼다.

원문의 각주 6을 보면 저자 자신도 사용자 비존재 패스키를 받아 주는 사이트를 하나도 알지 못한다고 인정한다. lxgr의 지적과 저자의 각주가 같은 방향을 가리키는 셈이다.

피싱 쪽 반론은 더 짧고 단호했다. tgma는 (직접 인용은 아니고, 코멘트의 요지를 요약) 비밀번호와 OTP는 피싱될 수 있고 패스키는 서명이 도메인에 묶여 전달될 수 없으므로 그것만으로 대다수 소비자에게 가치가 있다고 했고, 패스키에 관한 긴 글에 「phish」라는 문자열이 없다면 진지하게 받아들이기 어렵다고 덧붙였다. zamalek은 TOTP의 치명적 결함은 사람이 피싱 사이트에 숫자를 붙여 넣지 않는 데 의존한다는 점이며, 피싱된 TOTP로 얻은 세션이면 몇 초 안에 이체를 여러 건 할 수 있다고 썼다.

한편 원문에 「진실의 핵」이 있다고 본 사람도 있다. oefrha는 조직 내부 시스템에서 비밀번호를 없애고 패스키만 쓰게 한 패스키 옹호자다. (직접 인용은 아니고, 코멘트의 요지를 요약) 그런데 최근 1Password가 userVerification: required를 강제하기 시작하자, TouchID가 없는 데스크톱에서 많은 사이트의 패스키를 쓸 때마다 로그인 비밀번호를 다시 입력해야 하게 됐다고 한다. 그는 이 경험이 표준이 가진 「추가 제약의 잠재력」을 실감하게 했다고 썼다. 조직에서 보안 기준을 강제하기에는 좋지만, B2C 인증 기술로서 그런 제약이 널리 퍼지면 사용자 자유가 크게 훼손될 것이라는 판단이다. 그는 LLM에게 Go로 패스키 인증을 몇 번 짜게 했더니 매번 required를 골랐다는 관찰도 덧붙였다.

이 대목이 중요하다. 원문이 경고한 것은 증명이라는 극단적 스위치였지만, 실제로 사용자가 먼저 부딪힌 것은 사용자 검증이라는 훨씬 평범한 다이얼이었다. 제약은 음모가 아니라 기본값으로 퍼진다.

Hawksley의 질문은 여전히 남아 있다

증명 공포를 걷어내도 9월 18일의 글이 던진 질문은 사라지지 않는다. Hawksley는 패스키가 도메인에 묶여 가짜 로그인 화면에 피싱될 수 없고, 비대칭 키라 서버가 털려도 복원되지 않는다는 점을 먼저 인정한다. 그러고 나서 개인에게 더 큰 위험은 영구적인 계정 잠김, 자동화된 계정 정지, 기기 분실이라고 말한다. 로그인 흐름의 피싱은 사라지지만 계정의 보안은 여전히 가장 약한 복구 수단, 즉 SMS·이메일 링크·보안 질문이 결정한다는 것이다.

그의 구체적인 지적은 이렇다. 하드웨어 키에 들어간 패스키는 설계상 백업할 수 없으므로 키 두세 개를 사서 모든 사이트에 각각 등록해야 한다. 디스커버러블 자격 증명은 키당 25에서 100개 정도의 한도가 있고 최상위 제품도 300개 정도다. 해커뉴스에서 elric도 비밀번호 저장소에 700개 이상의 항목이 있는데 YubiKey 8개를 들고 다녀야 하느냐고 물었다. 동기화 패스키는 Apple 또는 Google 계정에 묶여 있어, 그 계정이 자동화된 시스템에 의해 정지되면 그 위에 올린 모든 제3자 계정의 패스키를 잃는다. FIDO Alliance가 패스키 내보내기와 상호운용성을 개선하고 있지만, Hawksley의 평가로는 아직 제공자마다 경험이 파편화되어 있어 기대기에는 이르다. Bitwarden이나 KeePassXC 같은 제3자 관리자에 저장하면 Android Credential Manager 같은 API가 생겼음에도 네이티브 앱 자동완성이 여전히 들쭉날쭉하다.

여기서 프로토콜과 구현을 나누면 그림이 선명해진다. 피싱 저항은 WebAuthn 프로토콜의 성질이다. 오리진에 묶인 서명이라는 메커니즘이 그것을 보장하고, 어떤 관리자에 저장하든 유지된다. 반면 잠김과 이식성 문제는 대부분 동기화 구현과 계정 복구 정책의 성질이다. 패스키를 어느 클라우드에 두느냐, 그 클라우드가 계정을 정지할 때 무슨 일이 일어나느냐, 다른 관리자로 옮길 수 있느냐는 FIDO 사양이 아니라 Apple, Google, 1Password, Bitwarden이 결정한다. 증명은 이 둘 사이에 걸쳐 있다. 사양에는 있지만, 소비자 패스키의 대부분을 차지하는 동기화 패스키 구현이 사실상 쓰지 않는 기능이다.

원문은 이 세 층위를 하나의 「패스키」로 묶어 공격하면서, 역설적이게도 자신이 FIDO Alliance를 비판한 바로 그 혼동, 같은 이름 아래 다른 것을 섞는 혼동을 되풀이한다. 그리고 증명이 가장 확실하게 붙어 있는 하드웨어 보안 키를 대안으로 권하면서 논리가 꼬인다.

전망과 시사점

이 논쟁에서 실무적으로 건질 것은 세 가지다.

첫째, 증명은 「지금 일어나는 일」이 아니라 「감시해야 할 일」이다. agwa와 lxgr의 설명이 맞다면, 소비자 사이트가 증명을 강제하는 순간 iOS와 Android의 기본 패스키 사용자 대다수가 등록할 수 없게 된다. 그 비용은 크고, 등록 시 브라우저 프롬프트라는 가시적인 신호도 있다. 그러니 합리적인 태도는 패스키를 피하는 것이 아니라, 소비자 서비스의 등록 흐름에서 증명 요청이 나타나는지를 지켜보는 것이다. 원문 저자의 우려가 틀렸다는 뜻은 아니다. 그 우려가 현실화되는 경로가 공개적이고 관찰 가능하다는 뜻이다.

둘째, 실제 마찰은 덜 극적인 기본값에서 온다. oefrha의 1Password 사례가 보여 주듯 사용자 검증 요구, 플랫폼 관리자로 유도하는 「행복한 경로」, 계정 정지 시의 복구 불가능성 같은 것들이 사용자의 선택지를 조용히 줄인다. 사이트를 만드는 쪽에서는 userVerification을 생각 없이 required로 두지 말고, 패스키를 1요소로 쓸지 2요소로 쓸지를 의식적으로 결정해야 한다. 복구 경로가 SMS 하나뿐이라면 패스키의 피싱 저항은 반쪽짜리가 된다.

셋째, 사용자에게 가장 현실적인 답은 원문과 Hawksley 모두 암시하는 지점, 즉 「내가 고른 관리자」에 있다. 해커뉴스에서 david_shaw는 (직접 인용은 아니고, 코멘트의 요지를 요약) TOTP를 옹호하는 것 자체가 이미 숫자를 만드는 앱에 의존하는 것이므로, 같은 소프트웨어로 패스키를 관리하면 통제권을 유지할 수 있다고 썼다. cyberax는 자체 호스팅한 Vaultwarden 위의 Bitwarden으로 패스키를 내보내고 동기화한다고 했다. skybrian은 패스키를 「애완동물이 아니라 가축」처럼 다뤄, 계정마다 여러 개를 여러 관리자에 두라고 권했다. 이것은 Hawksley가 말한 이식성 문제에 대한 운영상의 답이며, 피싱 저항을 포기하지 않는다.

(10월 15일 추기: 보안 연구자 Scott Helme가 10월 14일 자로 「Passkeys Are Not a Trap」을 공개했고 해커뉴스에서 670점을 받았다. 그는 대부분의 사람이 쓰는 동기화 패스키는 증명문을 주지 않고, 사이트가 요청해도 돌아오는 것은 none이라고 쓴다. 또 WebAuthn 증명은 AAGUID로 식별되는 인증기의 제조사와 모델을 벤더 인증서 체인과 함께 알려 줄 뿐, OS·브라우저·확장 프로그램·루팅 여부·펌웨어 버전에 대해서는 아무것도 말하지 않는다고 반박한다. YubiKey야말로 Yubico 발급 증명 인증서를 달고 나오는 장치이므로, 증명이 걱정이라면 원문의 권고는 오히려 증명 쪽으로 사용자를 민다는 지적도 덧붙였다. TOTP에 대해서는 Evilginx 같은 피싱 키트가 비밀번호와 코드를 실시간으로 중계해 세션을 탈취한다는 점을 들어 「뒤로 가는 걸음」이라고 했다.)

결론

「패스키는 함정인가」라는 질문에 대한 답은 어느 층위를 묻느냐에 따라 달라진다. 프로토콜로서의 WebAuthn은 도메인에 묶인 서명으로 피싱을 구조적으로 막는다. 이것은 TOTP가 줄 수 없는 성질이고, 원문 저자도 마지막 각주에서 인정했다. 증명은 사양에 존재하는 위험한 다이얼이 맞지만, 현재 소비자 패스키의 주류 구현에서는 사실상 꺼져 있고, 켜는 순간이 눈에 보이게 되어 있다.

진짜 함정은 다른 곳에 있다. 패스키를 하나의 플랫폼 계정에 몰아넣고, 그 계정의 복구를 SMS에 맡기고, 내보낼 수 없는 관리자를 기본값으로 받아들이는 것. 이것은 사양의 문제가 아니라 우리가 어떤 구현을 고르느냐의 문제다.

당신의 패스키는 지금 어디에 있는가. 그 관리자가 내일 당신의 계정을 정지한다면, 당신은 어떤 경로로 돌아올 수 있는가. 그 답을 갖고 있다면 패스키는 함정이 아니다. 갖고 있지 않다면, 비밀번호로 돌아가는 것도 답은 아니다.

출처: