# Passkey는 여전히 문제가 있다

> Clean Markdown view of GeekNews topic #25173. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=25173](https://news.hada.io/topic?id=25173)
- GeekNews Markdown: [https://news.hada.io/topic/25173.md](https://news.hada.io/topic/25173.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2025-12-19T08:33:16+09:00
- Updated: 2025-12-19T08:33:16+09:00
- Original source: [fy.blackhats.net.au](https://fy.blackhats.net.au/blog/2025-12-17-yep-passkeys-still-have-problems/)
- Points: 7
- Comments: 4

## Summary

패스키는 비밀번호 없는 인증의 미래로 제시되었지만, 여전히 **사용자 경험과 벤더 종속성**이라는 구조적 한계를 벗어나지 못하고 있습니다. 새로 도입된 **FIDO Credential Exchange**가 자격 증명 이동을 가능하게 했으나, 플랫폼 간 단절과 UI 설계의 유도적 구조로 인해 사용자의 선택권은 제한된 상태입니다. 계정 보호를 위해서는 **자체 제어 가능한 Credential Manager**와 **Yubikey 같은 하드웨어 키**를 병행해, 플랫폼 잠금이나 데이터 손실에 대비하는 접근이 필요합니다.

## Topic Body

- 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)** 확보임

## Comments



### Comment 48019

- Author: roxie
- Created: 2025-12-19T21:44:10+09:00
- Points: 1

저는 패스키 좋아요,,

### Comment 48004

- Author: yeobi222
- Created: 2025-12-19T16:06:35+09:00
- Points: 1

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

### Comment 47999

- Author: koxel
- Created: 2025-12-19T13:02:17+09:00
- Points: 1

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

### Comment 47976

- Author: neo
- Created: 2025-12-19T08:33:16+09:00
- Points: 1

###### [Hacker News 의견들](https://news.ycombinator.com/item?id=46301585) 
- 작성자가 여전히 **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 이슈](https://github.com/keepassxreboot/keepassxc/issues/10407)
  - 나는 그 이슈의 댓글 작성자임. **암호화된 백업**을 기본으로 요구하는 것은 내보내기를 막는 게 아니라 오히려 사용자가 키를 직접 통제하게 하는 것임

- 서비스 제공자가 passkey 저장 방식(하드웨어/소프트웨어)을 강제하거나, **Touch ID 같은 MFA**를 강제하는 한 나는 여전히 **비밀번호 + TOTP** 조합을 선호함
  - (1)은 이미 불가능함. 서비스가 passkey 저장 방식을 강제할 수 없음  
  - (2)는 **MFA가 아니라 생체 확인(liveness check)** 에 가까움. 단순히 사람이 직접 로그인 중임을 증명하는 절차임
  - 비상 상황에서는 수동 입력 방식의 백업이 필요함. 결국 비밀번호와 비슷한 형태로 돌아감

- “**벤더가 사용자를 잠글 수 있다**”는 점 때문에 passkey를 절대 쓰지 않음. 특히 사용자가 사망했을 때 상속인이 접근할 수 없는 문제가 큼
  - 관련 사례가 있음: [Apple ID 복구 실패 사례](https://hey.paris/posts/appleid/), [HN 토론](https://news.ycombinator.com/item?id=46252114)
  - 일부 password manager는 **오프라인 루트 신뢰 체계**를 제공함. 예를 들어 1Password의 [Emergency Kit](https://support.1password.com/emergency-kit/)은 인쇄된 복구 코드를 통해 상속자나 가족이 접근 가능함
  - 비밀번호와 passkey 중 어느 쪽이든 **벤더의 정책**이 동일하다면 접근 제한은 같음
  - 이런 계약을 **법적 신탁(trust)** 형태로 전환할 수 있다면 좋겠지만, 기업들이 싫어할 것임
  - passkey 등록을 강요하는 **다크 패턴 UI**가 너무 짜증남. 회사 계정으로만 쓰는데도 계속 등록하라고 뜸. 이미 SSO와 2FA를 쓰고 있는데 왜 또 passkey를 요구하는지 이해 불가임

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

- **Password + TOTP** 조합이 여전히 가장 실용적임. 기기 간 이동도 Bitwarden 로그인만 하면 됨. 반면 passkey는 **기기 분실 시 복구 절차**가 불분명함. iPhone에서 설정한 passkey가 Linux 데스크톱에서도 작동하는 이유조차 명확하지 않음. 단일 플랫폼 사용자에게만 유리함
  - 기기를 여러 개 등록했거나 동기화했다면 복구 가능하지만, 그렇지 않으면 계정 복구 절차 외에는 방법이 없음. 결국 **비밀번호보다 나을 게 없음**

- 결국 passkey는 **과도하게 복잡한 설계**임. 락인을 수용하면 일부 문제는 줄지만 새로운 제약이 생김. **TOTP가 현실적인 대안**임
  - TOTP는 귀찮지만 **사용자 통제권**이 있음. 그래서 직접 만든 [LazyOTP 크롬 확장](https://chromewebstore.google.com/detail/lazyotp/eoihmklnjkngifajbdlfhhajdcdpmplb)으로 단일 인증으로 쓸 수 있게 함

- passkey는 **대부분의 일반 사용자에게는 훌륭한 솔루션**임. 복잡한 비밀번호 관리나 재사용 문제를 없애고, 로그인 절차도 단순함.  
  기술적으로 이해하는 입장에서도 **빠르고 매끄러운 로그인 경험**이 훨씬 낫다고 느낌
  - 하지만 기기를 잃거나 고장 내면 모든 계정 접근이 막힘. **종이 비밀번호**는 그런 문제가 없음
  - passkey의 가장 큰 장점은 **피싱 방어력**임. 잘못된 도메인에 자격 증명을 제출할 수 없음
  - 다만 PC와 휴대폰 간 **비밀키 동기화 과정**이 불분명함. 결국 Apple 생태계에 완전히 묶이는 구조 같음
  - 실제로 여러 플랫폼 간 완벽히 매끄럽게 작동하는 구현은 아직 본 적 없음

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