패스키가 함정인지는 판단할 만큼 알지 못하지만, 사용자 입장에서는 혼란스러운 체계임. 사이트에서 패스키를 만들라고 할 때 쓰는 기기에 따라 Google 비밀번호 관리자, Samsung 비밀번호 관리자, iCloud Keychain, Windows의 무언가에 저장될 수 있음.
다른 플랫폼에서 접속하면 어떻게 되는지, 잠긴 업무용 PC나 Bluetooth가 없는 기기에서는 어떻게 인증하는지, 한곳으로 모으거나 특정 기기를 잃어버리면 어떻게 해야 하는지 모르겠음.
이걸 알아볼 시간도 인내심도 없음. 내 문제일 수 있지만, TOTP는 원하는 관리자에서 QR 코드를 스캔하고 사이트에 숫자를 입력하면 끝이라 훨씬 간편함. 패스키가 왜 더 나은가?
“패스키는 함정”이라는 글이 이런 사용성의 악몽을 다룰 줄 알았음. 패스키를 연결하면 다른 로그인 수단을 거의 쓸 수 없게 만드는 사이트도 있고, 여러 패스키나 대체 인증 수단을 지원하는지도 제각각임.
발상과 프로토콜은 꽤 탄탄하지만, 여러 기기의 인증 흐름은 다시 “생체정보를 비밀번호로 쓰는” 문제로 돌아감. 패스키 전환을 권유받을 때마다 이 사이트도 구현을 망쳤을까 걱정하게 되며, 지금까지는 약 30% 가 그랬음.
나도 이해하기 어렵고, 서로 충돌하는 정보가 많아서 더 읽는다고 해결될 것 같지 않음. 근본적으로 혼란스럽고 해석이 갈리는 부분이 있다고 봄.
패스키를 쓰다가 계정 접근권을 잃을 가능성이 상당해 보여서 상황이 명확해질 때까지 쓰지 않을 계획임. 이를 밀어붙이는 서비스들의 동기도 신뢰하지 않음.
무작위로 생성한 강력한 비밀번호는 실용적으로 패스키만큼 좋으면서 사용자가 통제권을 유지할 수 있게 함. 노트북과 휴대폰 사이에서 복사하거나 가족·친구에게 전달하는 것도 가능함.
패스키가 강력한 무작위 비밀번호와 비밀번호 관리자 조합에 없는 무엇을 제공하는가?
Windows 데스크톱에서 iCloud 패스키를 설정하기 어려웠음. 대부분 Windows Hello가 먼저 끼어들고, 그렇지 않으면 보통 1Password가 나서서 사용 흐름이 여전히 당혹스러움.
패스키 전용 이전 프로토콜은 있지만, Apple의 비밀번호 관리 기능과 항목별 입력 필드가 너무 단순해서 아쉬움. 그래도 이제 YubiKey를 그만 쓸 때가 된 것 같기는 함.
대부분에게 혼란스러운 체계인 건 맞음. Apple 생태계만 쓰는 사람에게는 꽤 괜찮겠지만, 나머지에게는 그렇지 않음.
걱정하는 건 증명(attestation) 자체가 아니라 향후 이를 통해 강제할 제약임. 첫 글에서도 이 점은 아주 명확했음. 제약 없는 증명이라면 괜찮고, YubiKey가 그런 제약을 피하는 수단일 수 있음. 이 글의 대부분은 타당하지만, 원문의 권고가 오히려 증명으로 유도한다는 반박은 핵심을 빗나감.
소비자용 사이트에는 수년째 증명을 요청하지 말라는 지침이 있었다고 해도, 앞으로 패스키로 사용자가 수정할 수 있는 소프트웨어를 차단할 것이라는 우려는 해소되지 않음. 은행·저작권 콘텐츠·개인정보·결제정보를 다룬다는 이유로 자기 서비스에는 추가 통제가 필요하다고 여길 관리자는 수없이 많음.
이 우려가 실제로 타당해서 반박하지 못하는 건지, 우려의 핵심을 못 읽고 기업에 대한 신뢰를 과대평가하는 건지 모르겠음. 일단 “YubiKey로 인증하면 증명이 되므로 OS와 브라우저의 수정 여부까지 강제하지 못한다”는 뜻으로 읽히는데, 이것이 올바른 이해인지도 확신할 수 없음.
원격 증명은 사용자에게 이롭지 않음. 이를 쓰려면 허용할 기기 제조사를 제한해야 하고, 내 기기가 목록에서 빠질 수 있음.
Google이 승인한 Android 휴대폰은 공격자도 쉽게 구할 수 있으므로, 그런 기기라는 사실을 아는 것만으로 얻는 가치는 없음. 다른 종류의 기기 사용만 막을 뿐임. 키를 HSM에 보관하는 것과도 별개이며, HSM은 원격 증명이나 상대방의 추가 조치 없이도 쓸 수 있음.
오히려 승인된 기기가 내가 쓰려는 기기보다 보안성이 낮을 수 있음. 일반적으로 YubiKey를 HSM으로 쓰는 편이 공격 표면이 훨씬 넓고 인터넷에 상시 연결된 휴대폰보다 낫지만, 허용 목록에는 휴대폰이 들어갈 가능성이 더 큼.
며칠 전 글은 통제가 점차 강화될 위험을 다뤘는데, 오늘 글은 그 가능성을 인정하면서도 지금 패스키가 증명문을 반환하지 않는다는 사실로 반박하려 해서 혼란스러움. 핵심은 모두 패스키에 익숙해진 뒤 증명을 필수로 만들 것이라는 점임. 브라우저 전쟁의 반복처럼 보임. Google은 약 20년에 걸쳐 우위를 확보한 뒤 광고 차단 기능을 점차 무력화하며 사용자의 콘텐츠 통제력을 약화시키기 시작했음.
그렇다고 2026년 인터넷의 인증 절차가 좋은 것도 아님. VPN 차단, 비밀번호 재설정, 재로그인, 이메일 인증과 재전송을 거치느라 로그인에 3분 넘게 쓰는 일이 흔함. 곧 브라우저 사용의 95%를 LLM이 대신해 줄 것 같아 다행임.
이 글은 세부 사실로 큰 흐름을 합리화해 무시하는 전형적인 글임. 지금 패스키가 하드웨어·OS 증명을 요구하지 않는다는 개별 설명은 맞지만, 쉽게 그런 요구를 추가할 수 있고 결국 그렇게 될 것임.
은행은 이미 그렇게 했음. 예전에는 앱이나 Play Protect 사용이 선택사항이었음. Ted 삼촌 말처럼 기술은 선택사항이 아님.
우리 주에서 안전벨트 법을 도입할 때는 다른 위반으로 단속한 경우에만 추가 적용하고, 안전벨트만으로 차를 세우거나 벌금을 부과하지 않겠다고 약속했음. 이제는 경찰이 지켜보고 있으니 벨트를 매지 않으면 벌금을 물린다는 광고를 함.
안전벨트 법 자체가 나쁘다는 뜻은 아님. 통제를 강화할 경로가 있으면, 하지 않겠다고 약속해도 결국 사용하게 된다는 뜻임.
증명이 특정 승인된 인증기를 요구하고, 그 인증기가 OS·소프트웨어·하드웨어 요건을 모두 강제할 수 있다는 쪽에 가까워 보임. 해당 요건이 증명 표준에 포함되지 않아도 가능함.
그건 좋은 일 아닌가? 대부분의 소비자용 웹사이트는 증명을 쓰지 않고, 은행이나 고용주처럼 추가 보안이 필요한 곳은 쓸 수 있음.
비밀번호 인증에도 사진이 있는 신분증 제출을 쉽게 추가할 수 있음.
인증기의 제조사와 모델은 알려주지만 OS·브라우저 등은 알려주지 않는다는 설명에서 내가 놓친 게 있는가? “인증기가 무엇인지 알려주지만, 무엇인지는 알려주지 않는다”는 식으로 들림.
이 글은 사실상 기존 패스키 사용자를 이전시켜야 하므로 아무도 증명을 활성화하지 않을 것이라는 논리에 기대는데, 설득력이 약함. 기존 사용자는 증명 없이 허용하고 신규 사용자에게만 요구하면 됨. 아직 패스키를 지원하지 않는 사이트가 대부분이므로 그 논리는 대다수 사이트에 적용되지도 않음.
마지막의 최대 제공업체 관련 부분도 이상함. 가장 큰 제공업체는 Apple과 Google이고, 내가 알기로 둘 다 증명을 지원함.
인증기의 제조사와 모델만 알려주니 괜찮다는 건 숲을 보지 못하는 설명임. 내가 Netflix나 은행이라면 iOS와 Play Protect가 적용된 Android에서만 작동하는 신뢰하는 인증기에만 신규 등록을 허용하겠음.
바로 다음 문단에 YubiKey도 등록된 인증기라고 적혀 있음. YubiKey는 플랫폼에 종속되지 않음.
신뢰할 수 있는 비밀번호 관리자를 고르는 건 쉽지 않음. 여러 구독 서비스의 비밀번호를 관리자로 관리하는 회사들에서 일했는데, 관리자가 개인 비밀번호도 무료로 넣으라고 할 때마다 해킹될 거라며 거절했고, 6개월 뒤 실제로 해킹당하곤 했음.
iPhone의 비밀번호 관리자는 꽤 안전해 보이고 휴대폰에서 비밀번호를 입력하는 게 너무 불편해서 사용함. 다른 환경에서는 데이터베이스는 보조적으로만 쓰고 암호학적 생성 방식을 활용하는데, 비밀번호에는 잘 맞아도 패스키에는 도움이 되지 않음.
회사 제공 비밀번호 관리자에 개인 비밀번호를 보관한다는 발상부터 황당함. 퇴사하면 어떻게 되는가?
그건 비밀번호 관리자가 잘 해결하는 사이트 간 비밀번호 재사용과는 다른 공격 표면임. 재사용은 피해 범위가 훨씬 커질 수 있음.
관리자 해킹 위험과 재사용 위험 중 골라야 한다면, 대부분에게 비밀번호 관리자를 강하게 권하겠음. 여러 조건을 따져도 대체로 훨씬 나은 선택임.
이 부분에서는 TOTP 기반 2단계·다중요소 인증이 더 안전하다고 봄. 비밀번호를 다른 곳에 보관한다면, TOTP 앱이 모든 비밀키를 서버로 보내더라도 그것만으로 계정에 침입할 수 없음. TOTP 코드만으로는 쓸모가 없으므로 관리자를 신뢰할 필요가 없음.
해킹당한 비밀번호 관리자는 어떤 제품이었는가?
KeePassXC도 이제 패스키를 지원함.
아직 패스키를 쓰지 않는 이유는 기존의 무작위 비밀번호 생성과 자동완성보다 어떤 이점이 있는지 모르기 때문임.
비밀번호 관리자는 어디로 동기화되는지 알고 모든 기기에 설치돼 있음. 반면 패스키 안내는 브라우저에 저장되는지 OS에 저장되는지, 어느 기기로 동기화되는지 늘 혼란스러움. 패스키를 쓰면 무엇을 얻는가?
가장 큰 이점은 피싱 저항성임. TOTP의 가장 큰 문제는 피싱을 막지 못한다는 것임.
패스키를 의무화하면 인증 단계에서 올바른 도메인에 로그인하는지 더 확실하게 보장할 수 있음. 비밀번호 관리자도 이를 돕지만 강제하기는 어려움. 중요한 문서를 열려는데 관리자가 작동하지 않아 비밀번호를 직접 복사했다는 식의 일을 여러 번 접했음.
남이 골라준 클라이언트 OS와 하드웨어에 강제로 종속되는 것을 얻게 됨.
SSH에서 아주 강력한 비밀번호를 쓰는 것과 공개키 인증을 쓰는 것의 차이는 무엇인가?
비밀번호 관리자가 수상한 로그인이라고 경고하는데도 기술에 밝은 사람이 사기 사이트에 비밀번호를 입력하는 걸 봤음. 패스키는 암호학적 구조 덕분에 그런 피싱이 불가능함.
이 글의 모든 논점은 저자가 언급한 HN 스레드를 비롯한 다른 곳에서 이미 충분히 논의됐음. 그 논의에서 드러나는 건 문제가 없다는 게 아니라, 이 반박들이 문제의 핵심을 놓친다는 것임.
패스키에는 장점도 단점도 있고, 장점이 단점을 감수할 만큼 크지 않다고 보는 사람이 많음. 사이트들이 비밀번호를 없애고 패스키만 받게 돼 사용자 처지가 더 나빠질까 우려하는 사람도 많음.