▲

Passkey는 여전히 문제가 있다

 (fy.blackhats.net.au)
3P by GN⁺ 19시간전 | ★ favorite | 댓글 4개
  • 2025년 현재도 패스키(Passkey) 는 보안성과 편의성 논의 속에서 여전히 사용자 경험과 벤더 종속성 문제를 안고 있음
  • 새로 도입된 FIDO Credential Exchange는 공급자 간 이동을 가능하게 하지만, 플랫폼 간 마찰과 단편화 문제는 여전함
  • Apple, Google, Microsoft 등 플랫폼 관리자의 백업 불가·잠금 위험이 지속되며, 사용자 선택을 제한하는 UI 설계가 문제로 지적됨
  • 패스키 개념의 난해함과 서비스의 오해를 부르는 커뮤니케이션이 일반 사용자 신뢰를 떨어뜨림
  • 핵심 계정 보호를 위해 자체 제어 가능한 Credential Manager와 Yubikey 같은 하드웨어 키 사용이 중요함

TL;DR 요약

  • 패스키에는 여전히 결함이 존재하며, 사용자는 이를 이해하고 자신의 조건에 맞게 활용해야 함
    • 플랫폼 제공자(Apple, Google, Microsoft)의 Credential Manager만 사용하는 것은 백업 불가 및 잠금 위험이 있음
    • Bitwarden, Vaultwarden 등 백업 가능한 Credential Manager 사용 권장
    • FIDO Credential Exchange를 통해 외부 Credential Manager로 정기 동기화 필요
    • 이메일 등 중요 계정은 Yubikey를 패스키 저장소로 사용하고, 강력한 비밀번호 + TOTP를 보조 수단으로 유지
    • Credential Manager 접근 불가 시 복구 경로를 사전에 점검해야 함

지난 1년간의 변화

  • 주요 변화는 FIDO Credential Exchange 사양 도입임
    • 이를 통해 패스키 제공자 간 자격 증명 이동이 가능해졌음
  • 그러나 플랫폼 간 마찰과 생태계 단절은 여전히 존재
    • 서로 다른 기기 간 패스키가 단편화될 수 있으며, 사용자는 이를 인식하지 못할 가능성 있음
    • Apple 기기의 패스키는 비Apple 기기로 동기화 불가, 반면 Google·Microsoft는 일부 가능
    • Apple 사용자는 더 강한 종속성을 느낄 수 있음

패스키 개념의 난해함

  • 비밀번호는 “내가 아는 것”, SMS 2FA는 “내가 받을 수 있는 것”으로 직관적 이해 가능
  • 반면 패스키는 눈에 보이지 않는 인증 요소로, 사용자가 직접 확인하거나 인쇄할 수 없음
  • Credential Manager를 신뢰하는 과정이 필요하지만, 패스키는 그 신뢰 단계를 건너뛰게 함
  • 보안 전문가조차 패스키의 작동 원리를 혼동할 정도로 이해 장벽이 높음

‘사고 리더십’과 사용자 교육 문제

  • 일부 업계 인사는 “패스워드 관리 학습은 산업의 실패”라고 주장하지만,
    실제로는 패스키도 Credential Manager 이해가 필수
  • 패스워드·TOTP를 선호하는 사용자는 오만해서가 아니라 사용성 문제 때문일 수 있음
  • 패스키가 사용자 교육 없이도 작동한다는 믿음은 현실과 동떨어진 인식임
  • 사용자가 충분히 이해한 뒤에도 패스키 대신 다른 방식을 택한다면, 패스키가 그 사용자에게 실패한 것임

여전한 벤더 종속성

  • FIDO Credential Exchange가 존재해도, 실제 사용 과정의 마찰과 UI 유도 설계가 전환 비용을 높임
  • Apple의 패스키 생성 모달은 기본적으로 Apple Keychain 사용을 유도,
    다른 옵션(보안키, Android 등)은 ‘Other Options’ 에 숨겨져 있음
  • 사용자의 선택이 기억되지 않으며, 매번 기본값으로 되돌아감
  • Google Chrome도 유사한 구조를 가지며, 플랫폼 생태계에 머물도록 유도
  • 이는 단순한 저장 위치 문제가 아니라, 사용자 경험 전반의 종속성으로 이어짐

클라우드 키체인 데이터 손실

  • Apple Keychain에서 패스키가 사라지거나, Android 기기에서 생성·사용 불가 사례 지속
  • 일부 사례에서는 기기 초기화로도 복구 불가, 사용자 계정 접근이 완전히 차단됨
  • 이러한 문제는 패스키 신뢰도 하락으로 이어짐

벤더에 의한 계정 잠금

  • Apple 계정 잠금 사례에서 모든 패스키가 복구 불가 상태로 소멸
  • Google, Microsoft에서도 유사 사례 존재
  • 단일 계정 조치로 모든 자격 증명이 파괴될 위험이 있음

인증 서비스의 오해 유발 커뮤니케이션

  • 일부 서비스는 “패스키가 얼굴·지문 데이터를 전송한다”고 설명
  • 실제로는 생체정보가 기기 밖으로 나가지 않지만,
    일반 사용자는 이를 ‘얼굴/지문이 인터넷으로 전송된다’ 고 오해
  • 이러한 설명은 패스키에 대한 불신과 거부감을 초래
  • 플랫폼 제공자의 UI도 이러한 오해를 해소하지 못함

사용자 선택을 제한하는 인증 서비스

  • 일부 웹사이트는 여전히 단일 패스키만 허용하거나,
    authenticatorAttachment 옵션으로 플랫폼 종속 패스키만 강제
  • 이는 보안키나 비플랫폼 Credential Manager 사용을 차단함
  • 일부 사이트는 로그인 시 사전 동의 없이 자동 패스키 등록을 시도하는 등 비윤리적 행태도 존재

결론 및 권장 사항

  • 대부분의 문제는 플랫폼 제공자 중심의 패스키 관리 구조에서 발생
  • 사용자는 자체 제어 가능한 Credential Manager를 통해
    계정 잠금·데이터 손실 위험을 줄이고 정기 백업을 수행해야 함
  • Yubikey(펌웨어 5.7 이상) 는 최대 150개의 패스키 저장 가능
    • 일부 계정은 소프트웨어 Credential Manager를 대체 가능
  • 이메일 계정은 복구 경로의 핵심이므로,
    하드웨어 키 + 강력한 비밀번호 + TOTP를 병행하고 오프라인 백업 유지 필요
  • Apple·Google 등 플랫폼은 사용자의 선택을 기억하고
    보안키·타 공급자 선택을 UI에서 동등하게 제공해야 함
  • 개발자는 WebAuthn API의 사전 필터링을 피하고,
    사용자에게 명확히 고지 후 패스키 등록을 진행해야 함
  • 핵심 원칙은 사용자 통제권과 동의(consent) 확보임
▲
roxie 6시간전  [-]

저는 패스키 좋아요,,

답변달기
▲
yeobi222 12시간전  [-]

보안체계 구조를 사용자가 이해 못하면 불신만 키울 뿐이죠
사용성 자체가 좋다 하기도 좀 그렇고

답변달기
▲
koxel 15시간전  [-]

구글 비밀번호 관리자 삭제 한번 했다가 다 날아가서 다시 발급 받은 뒤로 bitwarden 으로 옮겼습니다..

답변달기
▲
GN⁺ 19시간전  [-]
Hacker News 의견들

  • 작성자가 여전히 passkey에 대해 오해하고 있음. 많은 사람들이 passkey를 잃으면 복구 불가능하다고 생각하지만, 실제로는 비밀번호를 잃은 것과 같음. 대부분의 서비스에서는 이메일이나 SMS로 비밀번호 재설정이 가능함. 다만 Apple, Google, Facebook 같은 계정은 복구 절차가 복잡하므로 백업 코드를 인쇄해 안전하게 보관해야 함. 또한 password manager에 로그인하기 위한 마지막 비밀번호나 YubiKey 같은 외부 수단이 반드시 필요함

    • passkey 도입 전에도 Apple과 Google 계정에서 잠금 문제가 있었는지 궁금함. 현재 passkey는 사용자가 직접 백업하거나 내보낼 수 없고, 보안 엔지니어들이 키 복제 방지에만 집중한 결과 수십억 명이 잠금 위험에 노출됨. 이런 접근은 규제 리스크를 초래할 수 있음
    • passkey의 재설정 가능 여부는 서비스 제공자 구현에 달려 있음. 어떤 곳은 전화로만 복구가 가능하다는 불만도 있었음
    • Apple과 Google 계정은 다른 대부분의 비밀번호와 passkey를 저장하므로, 이 계정을 잃는 건 훨씬 더 심각한 문제임
    • passkey는 기기마다 독립적으로 존재하며, 모든 기기에 설정할 필요는 없음. 다른 기기에서는 단순히 비밀번호로 로그인하면 됨

  • passkey에 대해 두 가지를 개선했으면 함.

    1. 등록된 기기가 하나뿐인데도 UI가 불필요한 선택지를 보여줌
    2. 처음부터 SSH 키처럼 이식성과 유연성을 가졌다면 좋았을 것임. 지금은 벤더 종속이 너무 강함
    • Mac에서는 보안 키 버튼을 먼저 눌러 선택 단계를 건너뛸 수 있음
    • 옵션을 숨기지 말고 회색으로 표시하고 “등록된 키 없음”이라고 안내해야 함. 그래야 사용자가 문제 원인을 파악할 수 있음
    • passkey 시스템은 피싱 불가능을 목표로 설계되어 사용자가 직접 자격 증명을 내보내지 못하게 함. 결국 벤더 락인 구조로 귀결됨. 예를 들어 Safari에서 passkey를 쓰려면 iCloud Keychain이 필수라서 로컬 전용 사용이 불가능함
    • 기술에 익숙하지 않은 사용자를 위해서는 passkey가 좋은 선택일 수 있음. 다만 구조 코드를 종이에 적어 안전하게 보관하도록 도와야 함

  • KeePass 관련 이슈를 보면, 업계가 사용자의 개인 키 내보내기를 막으려는 압박이 커지고 있음. 이런 흐름은 우려스러움
    관련 GitHub 이슈

    • 나는 그 이슈의 댓글 작성자임. 암호화된 백업을 기본으로 요구하는 것은 내보내기를 막는 게 아니라 오히려 사용자가 키를 직접 통제하게 하는 것임

  • 서비스 제공자가 passkey 저장 방식(하드웨어/소프트웨어)을 강제하거나, Touch ID 같은 MFA를 강제하는 한 나는 여전히 비밀번호 + TOTP 조합을 선호함

    • (1)은 이미 불가능함. 서비스가 passkey 저장 방식을 강제할 수 없음
    • (2)는 MFA가 아니라 생체 확인(liveness check) 에 가까움. 단순히 사람이 직접 로그인 중임을 증명하는 절차임
    • 비상 상황에서는 수동 입력 방식의 백업이 필요함. 결국 비밀번호와 비슷한 형태로 돌아감

  • “벤더가 사용자를 잠글 수 있다”는 점 때문에 passkey를 절대 쓰지 않음. 특히 사용자가 사망했을 때 상속인이 접근할 수 없는 문제가 큼

    • 관련 사례가 있음: Apple ID 복구 실패 사례, HN 토론
    • 일부 password manager는 오프라인 루트 신뢰 체계를 제공함. 예를 들어 1Password의 Emergency Kit은 인쇄된 복구 코드를 통해 상속자나 가족이 접근 가능함
    • 비밀번호와 passkey 중 어느 쪽이든 벤더의 정책이 동일하다면 접근 제한은 같음
    • 이런 계약을 법적 신탁(trust) 형태로 전환할 수 있다면 좋겠지만, 기업들이 싫어할 것임
    • passkey 등록을 강요하는 다크 패턴 UI가 너무 짜증남. 회사 계정으로만 쓰는데도 계속 등록하라고 뜸. 이미 SSO와 2FA를 쓰고 있는데 왜 또 passkey를 요구하는지 이해 불가임

  • passkey의 UX가 엉망임. 몇 개가 활성화되어 있는지도 모르겠고, 인증 앱이 passkey를 잊어버리는 경우도 있음. 그냥 혼란스러움

  • Password + TOTP 조합이 여전히 가장 실용적임. 기기 간 이동도 Bitwarden 로그인만 하면 됨. 반면 passkey는 기기 분실 시 복구 절차가 불분명함. iPhone에서 설정한 passkey가 Linux 데스크톱에서도 작동하는 이유조차 명확하지 않음. 단일 플랫폼 사용자에게만 유리함

    • 기기를 여러 개 등록했거나 동기화했다면 복구 가능하지만, 그렇지 않으면 계정 복구 절차 외에는 방법이 없음. 결국 비밀번호보다 나을 게 없음

  • 결국 passkey는 과도하게 복잡한 설계임. 락인을 수용하면 일부 문제는 줄지만 새로운 제약이 생김. TOTP가 현실적인 대안임

    • TOTP는 귀찮지만 사용자 통제권이 있음. 그래서 직접 만든 LazyOTP 크롬 확장으로 단일 인증으로 쓸 수 있게 함

  • passkey는 대부분의 일반 사용자에게는 훌륭한 솔루션임. 복잡한 비밀번호 관리나 재사용 문제를 없애고, 로그인 절차도 단순함.
    기술적으로 이해하는 입장에서도 빠르고 매끄러운 로그인 경험이 훨씬 낫다고 느낌

    • 하지만 기기를 잃거나 고장 내면 모든 계정 접근이 막힘. 종이 비밀번호는 그런 문제가 없음
    • passkey의 가장 큰 장점은 피싱 방어력임. 잘못된 도메인에 자격 증명을 제출할 수 없음
    • 다만 PC와 휴대폰 간 비밀키 동기화 과정이 불분명함. 결국 Apple 생태계에 완전히 묶이는 구조 같음
    • 실제로 여러 플랫폼 간 완벽히 매끄럽게 작동하는 구현은 아직 본 적 없음

  • 나는 미리 비밀번호 관리자와 2FA 체계를 구축했는데, 이제 passkey로 전환하라는 흐름 때문에 그 모든 노력이 무의미해진 느낌임. 미리 대비한 사람일수록 불이익을 받는 기술 환경이 싫음

답변달기