패스키는 함정이 아닙니다

AI 요약

Scott Helme는 최근 Hacker News에서 관심을 얻은 "Passkeys are a trap. Do not use them." 글이 패스키의 attestation 기능을 과장했다고 반박합니다. 원글은 웹사이트가 패스키를 만든 소프트웨어와 운영체제를 확인하고, 승인된 환경에서만 로그인을 허용할 수 있다고 우려합니다. Helme는 이런 시나리오가 현재 소비자용 패스키의 작동 방식과 다르다고 설명합니다.

동기화 패스키에는 attestation이 없습니다

대부분의 사용자는 iCloud Keychain, Google Password Manager, 1Password, Bitwarden 같은 서비스에 동기화되는 패스키를 씁니다. Helme에 따르면 이런 패스키는 웹사이트에 attestation 정보를 보내지 않습니다. 사이트가 attestation을 요청해도 응답은 비어 있습니다. 소비자용 웹사이트가 attestation이 있는 패스키만 받기로 바꾸면 대다수 이용자를 즉시 차단하게 됩니다. 그는 소비자 사이트에 attestation을 요청하지 말라는 지침이 수년간 이어졌다고 덧붙입니다.

attestation이 제공하는 정보도 원글의 설명과 다르다고 지적합니다. WebAuthn attestation은 AAGUID와 제조사 인증서 체인을 바탕으로 인증기의 제조사와 모델을 알립니다. 운영체제, 브라우저, 확장 프로그램, 기기의 루팅·탈옥 여부, 펌웨어 버전은 알려주지 않습니다.

YubiKey와 TOTP의 보안 특성

원글은 attestation을 피하려는 사용자에게 YubiKey 같은 하드웨어 보안 키를 권하지만, Helme는 YubiKey가 attestation을 제공하는 인증기라고 짚습니다. 각 키에는 Yubico가 발급한 attestation 인증서가 있으며, enterprise attestation은 조직이 승인된 하드웨어 키만 허용할 때 쓰입니다. 따라서 attestation이 우려라면 YubiKey 권고는 그 우려를 피하는 방법이 되지 않는다는 설명입니다. Helme는 YubiKey 자체는 여전히 권할 만한 제품이라고 덧붙입니다.

TOTP는 비밀번호만 쓸 때보다 안전하지만 피싱에 취약합니다. 사용자가 가짜 사이트에 코드를 입력하면 Evilginx 같은 피싱 도구가 비밀번호와 코드를 실시간으로 실제 사이트에 전달하고 세션을 탈취할 수 있습니다. 패스키는 생성된 도메인에 묶여 있어 브라우저가 비슷한 주소의 가짜 사이트에 인증 정보를 내주지 않습니다. Helme는 피싱에 저항하는 인증 수단을 피싱 가능한 TOTP로 바꾸는 선택은 좋지 않다고 주장합니다.

Helme의 권고

사이트에서 패스키를 제공하면 계속 사용하고, 신뢰하는 비밀번호·패스키 관리자에 보관하라고 권합니다. 자격 증명을 옮기고 싶다면 이동 기능을 지원하는 관리자를 선택하라고 합니다. 소비자 로그인을 attestation으로 제한하는 일이 실제로 생기면 반대 목소리를 내야 하지만, Helme는 현재 그런 일이 벌어지지 않았고 주요 제공업체도 이를 지원하지 않는다고 설명합니다. 패스키를 피하면 당장의 attestation 위험을 막는 대신 피싱에 노출될 수 있다는 주장입니다.

Hacker News 반응

• @mik1998 — 그러니까 지금 솥이 차가우니 아래에서 불이 타오르는 건 무시하고 솥 안으로 뛰어들라는 말이군요.
  • @deltoidmaximus — 이 이슈 트래커들을 읽어보시길 권합니다. KeepassXC 관리자는 relying party가 이 구현을 차단할 가능성이 있다고 썼습니다. 패스키 제공자를 식별하는 attestation이 없다며 보안 인증의 필요성을 내세우는 업계 발표에 KeepassXC가 등장할 거라는 얘기도 들었습니다. attestation을 우려하는 사람에게 막연한 먼 미래의 위협이라고만 말하는데, 실제 계획입니다.
• @blackcatsec — 비밀번호 관리자 이야기는 쉽지 않습니다. 여러 서비스를 함께 쓰던 직장에서 관리자를 쓰자는 제안을 거절했는데, 6개월 뒤 그 서비스들이 해킹당했습니다. 개인 비밀번호는 iPhone의 관리자에 넣지만 다른 비밀번호는 데이터베이스를 보조 수단으로 두고 암호학적으로 생성해 왔습니다. 그 방식은 패스키에는 해당하지 않습니다.
  • @blackcatsec — 비밀번호 관리자가 해킹당할 위험과 웹사이트마다 비밀번호를 재사용하는 위험은 공격 표면이 다릅니다. 둘 중 하나를 감수해야 한다면 일반적으로는 비밀번호 관리자를 권하겠습니다. 대다수 사람에게 위험을 낮추는 선택입니다.
• @verdverm — 생체 인증이 가장 걱정됩니다. 미국에서는 기기 잠금을 풀 때 생체 정보를 제공하라고 정부가 강제할 수 있지만 PIN이나 비밀번호는 다르다고 봅니다. 관련 법이 바뀔 때까지 비밀번호와 휴대전화와 분리된 하드웨어 키를 쓰겠습니다.
  • @psanford — 패스키가 생체 인증을 요구하지는 않습니다. Android의 동기화 패스키는 생체 인증을 꺼두면 화면 잠금 PIN으로 작동합니다. 비밀번호 관리자에 저장한 패스키와 생체 기능이 없는 하드웨어 키도 마찬가지입니다.
• @bonzog — 패스키가 혼란스럽습니다. 설정할 때 기기에 따라 Google, Samsung, iCloud, Windows의 관리자로 저장될 수 있습니다. 다른 플랫폼에서 같은 사이트에 접속하면 어떻게 되나요? 회사 컴퓨터가 잠겨 있거나 Bluetooth를 지원하지 않으면요? TOTP는 원하는 관리자에서 QR 코드를 읽고 숫자를 입력하면 끝납니다. 패스키가 왜 더 나은가요?
  • @gumby271 — 이게 바로 "패스키는 함정"이라는 주장 같습니다. 한 업체에 묶이면 쉽고 매끄럽지만 여러 업체를 섞어 쓰면 비밀번호와 관리자보다 훨씬 불편합니다.
• @mixdup — "함정" 글에 대한 완벽한 반박입니다. 패스키에 문제가 있나요? 물론 있습니다. 대부분 사용성 문제이고 개선 중입니다. 제 경험으로는 iOS와 macOS에서 사이트가 제공하는 패스키를 바로 등록합니다. 올바른 사이트에 접속했는지 걱정하지 않아도 되고, 다른 기기에서 로그인하는 기능도 편리합니다.
• @calgoo — 패스키의 큰 문제 중 하나는 Apple 같은 한 제공자에 묶인다는 점입니다. 이제 비밀번호를 풀 때 Apple 기기를 써야 합니다. 서비스 간 이동이 쉬워지면 더 기꺼이 쓰겠지만, KeePass 같은 로컬 앱으로 내보낼 수 있을 때까지는 준비가 안 됐다고 봅니다.
  • @watermelon0 — iOS 기기에서는 Apple Passwords와 Bitwarden을 포함해 지원하는 비밀번호 관리자 사이에서 패스키를 가져오고 내보낼 수 있습니다. 제 경험으로는 양방향 이동이 문제없이 됐습니다.
• @ForHackernews — "소비자 웹사이트가 attestation된 패스키만 받으면 거의 모든 사용자를 차단한다"고요? 어느 웹사이트든, 아니면 전부가 그렇게 할 수 있습니다. 내년부터 Gmail 로그인에는 Google Authenticator와 Google Chrome 패스키만 허용한다고 하면 어떻게 될까요?
  • @mixdup — Google은 모바일 기기 시장의 절반을 차단할 일을 하지 않을 겁니다. iOS는 패스키 attestation을 하지 않습니다.
• @varenc — 패스키는 피싱을 완벽하게 막습니다. 다른 도메인으로 패스키를 보낼 수 없기 때문입니다. 어디에 저장되는지 혼란스럽다는 지적에는 동의합니다. 여러 플랫폼에서 쓸 수 있는 비밀번호 관리자에 저장하는 방법이 있습니다.
• @aeternum — 무작위로 만든 강한 비밀번호와 비밀번호 관리자는 실용적인 면에서 패스키만큼 좋고, 사용자가 통제권도 가집니다. 노트북과 휴대전화 사이에 복사하거나 가족에게 전달할 수도 있습니다. 무작위 비밀번호와 관리자가 제공하지 못하는 사용자 이점은 무엇인가요?
  • @amluto — 상당한 수준의 피싱 방어를 제공합니다. 서버 메모리를 일시적으로 읽는 공격에도 취약하지 않습니다.

원문: Scott Helme / 번역·요약: Trawling