Passkey는 소비자 심리를 전혀 이해하지 못한 엔지니어들이 만들었다

• X 프로덕트 헤드인 Nikita Bier는 Passkey의 개념과 저장 위치가 사용자에게 명확히 전달되지 않아, 앱 로그인 때 정체를 알 수 없는 “마법의 가루”를 요구받는 경험이 됐다고 비판함
• 휴대폰/브라우저/운영체제/생체 정보 중 무엇이 Passkey인지 알기 어려우며, 사용자가 보안상 장점을 판단할 수 있을 만큼 명확한 설명도 부족하다는 것
• Passkey를 옹호하는 쪽은 입력하는 단어 대신 휴대폰이나 노트북처럼 소유한 장치를 열쇠로 사용하는 방식이며, 훔치기 쉬운 비밀번호보다 안전하다고 설명함
• 반대 의견은 유일한 Passkey 장치를 잃으면 계정 접근도 잃을 수 있고, 불완전한 구현과 복구 경험 때문에 계정 잠금 위험이 커진다고 지적함
• 일부는 비용 절감과 대형 플랫폼의 생태계 종속을 도입 동기로 의심한 반면, 비밀번호 자체가 근본적으로 취약하므로 불편함만으로 대안을 거부해서는 안 된다는 반론도 나옴

---

사용자가 이해하지 못하는 인증 방식

• 한 기술 기업 운영자는 비밀번호를 저장하는 방법을 겨우 익힌 사용자에게 Google이 Passkey를 제시하지만, 그것이 지문/얼굴 인식/숫자 데이터 중 무엇인지조차 알기 어렵다고 표현함
• Nikita Bier는 Passkey가 소비자 심리를 이해하지 못하는 보안 엔지니어들에 의해 만들어졌다고 비판함
  • 사용자들이 Passkey의 정체를 이해하지 못해 장점을 평가하거나 반박하기도 어려웠다고 봄
  • 결과적으로 앱이 로그인을 위해 어디에 있는지 모르는 인증 수단을 요구하는 상황이 됐다고 표현함
  • Passkey가 휴대폰/브라우저/운영체제/사용자의 신체 중 어디에 있는지도 불명확하게 느껴진다고 지적함

“입력하는 단어” 대신 “가지고 있는 열쇠”

• Passkey를 옹호한 댓글은 이를 비밀번호처럼 입력하는 단어가 아니라 사용자가 소유한 열쇠로 설명함
  • 대부분은 휴대폰을 열쇠로 사용하지만 노트북이나 다른 장치도 사용할 수 있음
  • 단어는 훔치기 쉽지만 열쇠는 상대적으로 훔치기 어렵다는 차이가 핵심임
• 편의성이나 생체 인증에 초점을 맞춘 설명은 오히려 개념을 혼란스럽게 만들며, 소유 기반 인증이라는 본질과는 관계가 적다는 의견임

장치 분실과 계정 복구 문제

• 비판 의견은 유일하게 작동하는 Passkey 장치를 잃으면 계정 접근도 함께 잃을 수 있다고 우려함
• 비밀번호는 기억하거나 별도로 보관할 수 있고 2FA 앱은 여러 장치에 설치할 수 있지만, Passkey는 올바르게 사용할 때의 견고함과 열쇠를 잃을 가능성을 동시에 키운다는 주장임
• 다른 댓글도 Passkey 구현을 실패로 평가하며 다음 문제를 제기함
  • 사용자 경험이 좋지 않고 사용하기 어려움
  • 계정에서 잠겨 나올 가능성이 큼
  • 플랫폼 사업자가 도입을 밀어붙이는 이유로 비용 절감과 생태계 종속을 의심함

대형 플랫폼 종속 논란

• Tim Sweeney는 Passkey를 사용자를 대형 기술 플랫폼에 묶어두는 계획이라고 평가함
• Passkey가 휴대폰/브라우저/운영체제 계정과 결합되는 경험 때문에, 사용자는 인증 수단의 위치와 관리 주체를 직접 통제하기 어렵다고 느낄 수 있다는 반응이 이어짐

비밀번호보다 나은 대안이라는 반론

• 일부는 Passkey를 장치와 생체 인증 또는 비밀번호를 결합한 방식으로 이해하며, 공격자가 두 요소를 모두 확보할 가능성이 낮아진다고 봄
• 반론은 비밀번호가 근본적으로 망가진 보안 모델이며 사용자들도 이를 제대로 사용한 적이 거의 없다고 강조함
• 새로운 방식이 어렵다는 이유로 쉬운 문제에만 머무르는 태도는 바람직하지 않으며, 비판만 하기보다 더 나은 인증 모델을 제시해야 한다는 의견임

[xguru]

음, X의 프로덕트 헤드 Nikita Bier는 원래 말을 좀 세게 하기로 유명합니다. Elon Musk와 비슷한 듯하면서도 결은 좀 다르고요.

새로 오픈한 BeeBS는 Passkey를 지원합니다. 저는 편하다고 생각하는 편이에요.

다만 Passkey만으로 가입하고 동기화나 다른 복구 수단이 없다면, 기기를 잃어버렸을 때 계정에 접근하지 못할 수 있습니다. 그래서 BeeBS는 먼저 이메일 매직링크로 가입한 뒤 Passkey를 등록하도록 했습니다.

이 두 가지를 조합하면 사용자 비밀번호를 서버에 전혀 저장하지 않아도 되고, 기기를 바꾸거나 잃어버리더라도 이메일로 다시 로그인해 새로운 Passkey를 등록할 수 있습니다.

[howudoin]

"passkey는 좋다. 대안 없는 비판을 하지마라!!"라고,
근데 정작 passkey가 기존 방식에 대한 대안의 위치이고, 제대로 된 대안을 제시하고 있지 못하면서 좋다고 우기는 중

[null468]

패스키를 편하게 쓰려면, 모든 플랫폼을 관통하는 단 하나의 패스워드 관리앱을 써야함....
그게 아니면, 내가 어디서 어떻게 패스키를 생성했는지도 모르고, 브라우저가 패스키 요청을 엉뚱한 주체에 묻고있는걸 인지하기도 힘듬. 그러다 보니 자주 쓰는 몇개 플랫폼 외에는 불편해서 패스키 안씀.
지금보니 패스워드 관리 앱 팔아먹으려고 만드는 기능같음.

[GN⁺]

Hacker News 의견들

• 26년간 기술 업계에서 일했고 공개키·개인키 원리도 이해하지만, 여러 기기와 브라우저에서 패스키를 어떻게 써야 로그인에 지장이 없는지는 모르겠음
  iPad, iPhone, Windows 데스크톱, MacBook Pro에서 Brave·Firefox·Safari와 LastPass를 쓰는데, 휴대폰 Safari에서 우연히 패스키를 만들면 다른 기기에서도 로그인할 수 있는지, 패스키를 동기화하거나 기기별로 추가할 수 있는지, 사이트마다 몇 개까지 허용하는지 불분명함
  사이트와 앱마다 정책이 다를 수도 있어 당분간은 기기를 잃거나 남의 기기를 쓰더라도 복구 가능한 LastPass와 비밀번호를 계속 쓰려 함
  배우자와 Pandora·Amazon Prime 계정을 공유하는 경우 각자 패스키를 만들 수 있는지, 그렇지 않다면 배우자에게 접근 권한을 어떻게 줄지도 의문임

  • 좋은 발상이 공급업체·비밀번호 관리자·브라우저의 주도권 경쟁으로 망가졌다고 봄
    엔지니어인 나도 패스키 UI가 전혀 명확하지 않으며, 모두가 사용자의 패스키를 독점 관리하려 하면서도 그 사실은 숨긴 채 “대신 처리해 주겠다”고만 함
    비기술직 지인들은 패스키를 써야 하는지와 사용법을 극도로 혼란스러워하고, 나조차 제대로 답하기 어려움
  • 패스키는 본질적으로 비밀번호 관리자가 필요한 비밀번호라고 생각하면 훨씬 단순함
    잃어버리면 “비밀번호 찾기” 이메일 같은 기존 복구 절차로 재설정하며, 보통은 비밀번호 관리자에 저장돼 다른 기기로 동기화되므로 잃지 않게 됨
    다만 복사·붙여넣기를 허용하지 않고 반드시 비밀번호 관리자를 통해 제시하게 해 피싱 상대에게 잘못 전달할 가능성을 막음
    주요 관리자는 사용자가 읽거나 백업할 수 있는 파일로 내보내기도 지원하지 않고, 관리자 간 전송에는 각자의 까다로운 앱 간 이전 절차를 요구해 종속 효과를 반기는 듯함
    비밀번호 관리자 자체에 로그인할 때만은 외부 수단인 비밀번호나 YubiKey가 필요함
    https://danfabulich.medium.com/passkeys-are-just-passwords-t...
    LastPass는 2022년에 이어 지난달에도 모든 비밀번호를 유출했으니 이제 떠날 때이며, 가장 비슷한 대안은 여러 심각한 침해를 겪지 않은 1Password임
  • 실제로는 사용자가 모든 기기에 패스키를 제대로 갖추지 못할 것을 사이트 운영자도 알기 때문에, 패스키만 강제하는 곳은 아직 못 봤고 비밀번호나 최악의 경우 이메일 매직 링크로 로그인할 수 있음
    하지만 이 대체 로그인 수단은 피싱 제거라는 패스키의 핵심 목표를 무력화하므로 언제까지 유지될지 모르겠음
    패스키로 로그인한 뒤 다시 TOTP 2단계 인증이나 이메일 확인을 요구하는 사이트도 있어, 사용자 편의라는 핵심 이점까지 사라짐
  • 바로 이런 의문에 명확한 답이 없어 패스키를 피하고 있으며, 중요한 계정의 접근 권한을 잃고 싶지 않음
  • 기기를 잃었을 때가 특히 걱정됨
    비밀번호는 종이에 적어 물리적으로 안전한 곳에 보관할 수 있지만, 패스키와 2단계 인증은 복구가 악몽이고 실용적인 복구 수단을 두면 보안성이 사라짐

• 오히려 패스키는 많은 일반 소비자에게 훌륭하며, 인증을 이해하고 자체 비밀번호 관리 체계를 가진 엔지니어들이 더 혼란스러워하는 듯함
  Apple 생태계 사용자는 이미 요청받으면 Touch ID나 Face ID를 쓰는 데 익숙함
  Amazon에서 패스키를 설정한 뒤 Mac과 iPhone에서 아무 마찰 없이 로그인할 수 있게 됐음
  일반 사용자에게 패스키는 비밀번호 관리자에서 복잡한 암호를 찾아 붙여넣는 과정을 대체하는 게 아니라, 모든 사이트에서 공유하던 같은 비밀번호를 직접 입력하는 행동을 대체함

  • 비밀번호 관리자는 어떤 기기에서든 서비스별 자격 증명을 안전하고 분산된 방식으로 쓸 수 있게 해줌
    패스키는 특정 기기에 종속돼 다른 기기를 쓰는 순간 불편해지며, 사용자가 소유·통제하는 자격 증명이라기보다 모든 것에 연결된 하나의 암호처럼 보임
    일부 상황에서는 더 안전하겠지만, 이미 더 나은 해결책이 있는 문제에 대한 열등한 대안에 가까움
  • 어머니가 링크 만료, 새 휴대폰 교체 등으로 로그인 도움을 요청하는 순간 내가 지원할 방법이 없어짐
    아무것도 모르는 사용자에게 강요되는 끔찍한 개념임
  • “Netflix 비밀번호 보내줄래?” 같은 평범한 상호작용에서 이미 계정 공유가 무너짐
  • Windows에서는 두 기기 모두 Bluetooth를 켜고 QR 코드를 스캔해야 하며, Linux에서는 Chrome과 아마 Bluetooth까지 필요함
  • macOS와 Android에서는 대체로 간단했지만 Windows 패스키는 싫음
    YubiKey나 비밀번호보다 PIN 사용을 계속 밀어붙임

• 사이트에서 처음 패스키 사용을 제안받자 검색해 봤지만, 하던 일을 방해받으며 투자한 5분 안에는 답을 찾지 못했음
  지금까지 본 가장 정확한 정의는 앱에 로그인시키는 마법의 요정 가루임
  비밀번호와 TOTP 토큰은 작동 원리와 내 관리 책임을 알지만, 휴대폰을 잃으면 어떻게 되는지, 기기마다 고유 패스키가 필요한지, 교체 주기와 도난 대응은 어떤지 알 수 없음
  이렇게 형편없이 설명됐다고 느끼는 사람이 나뿐만이 아니라 다행임

  • 몇 달 전에도 패스키에는 홍보와 UX 전면 개편이 필요하다고 썼음
    기술에 익숙한 나도 패스키가 어디에 저장되고 어느 기기에 묶이는지, 휴대폰 Chrome에서 QR 코드를 스캔하면 왜 로그인되는지 이해하지 못함
    어느 날 갑자기 선택지로 생겨 버튼을 누르면 로그인될 뿐이었고, 사용자 교육은 전혀 없었음
    컴퓨터 활용 상위 1%에 가까운 Hacker News 사용자도 이렇다면 평범한 가족이나 부동산 종사자는 이해하지 못하고 스스로 학습하지도 않을 것임
    https://news.ycombinator.com/item?id=46301585#46303892
  • 웹용으로 자동화된 SSH authorized keys라고 생각하면 됨
    키를 파일 대신 YubiKey나 TPM 같은 하드웨어 보안 모듈에 저장하며, 등록할 때 사이트와 비대칭 키 쌍을 만들고 로그인에는 일반적인 질의·응답 방식을 사용함
    가장 큰 진전은 피싱 저항성으로, 가짜 로그인 페이지는 TOTP 코드를 중계할 수 있지만 패스키 질의·응답은 중계할 수 없음
  • 비밀값을 읽을 수도 없는 하드웨어 종속 패스키를 기기별로 여러 개 등록하거나, Bitwarden·iCloud 같은 클라우드 서비스로 개인키를 동기화하는 공유 패스키를 쓸 수 있음

• 20년 넘게 기술 업계에서 일했어도 패스키가 혼란스러움
  컴퓨터 과학상의 키 개념은 이해하지만 기기 간 사용법을 모르며, 물리 키에 묶으면 분실 후 되찾지 못할 가능성이 크게 걱정됨

  • 다시 쉽게 로그인하지 못하거나 공급업체에 종속될까 봐 항상 패스키 추가를 거부함
  • 패스키의 큰 문제는 사이트와 앱마다 구현 방식이 매우 유연하다는 것임
    로그인 페이지에 들어가자마자 요청하기도 하고 사용자명이나 이메일을 먼저 요구하기도 하며, 패스키 하나가 비밀번호와 2차 인증을 모두 대체하거나 비밀번호 뒤의 2차 인증으로만 쓰이기도 함
    비밀번호 없이 패스키와 SMS 같은 별도 인증을 함께 요구하는 곳도 있음
    기기 등록과 동기화 혼란까지 더해져 사용자 경험의 일관성이 크게 부족함
    플랫폼 공급업체 간 연동은 개선할 수 있지만 사이트와 앱마다 작동 방식이 다른 문제는 해결하기 어려워 보임
  • 대부분 구현은 로그인·비밀번호와 함께 제공되는 보조 수단임
    Apple·Google·1Password·KeePass 같은 지원 관리자를 쓰거나, 늘 휴대하는 휴대폰으로 표시된 QR 코드를 스캔하면 되고 YubiKey 같은 전용 장치도 가능함
    Android와 Chrome에서는 Chrome의 비밀번호 관리자나 휴대폰 QR 스캔을 쓰면 됨
    폴란드 정부 앱 mObywatel도 로그인 후 인증서를 내려받고, 이후 QR 코드를 촬영해 PIN이나 생체 인증으로 정부 사이트에 접속하는 비슷한 구조임

• 패스키는 입력할 필요가 없는 비밀번호처럼 단순하며, 모든 기기에 1Password를 설치해 쉽게 쓰고 있음
  Android에서도 기본 패스키 제공자로 지정해 기기 간 공유가 가능함
  1Password로 키를 동기화하면 다소 덜 안전할 수 있지만 이전에도 같은 방식으로 비밀번호를 공유했으므로 보안 태세는 달라지지 않았다고 봄
  대신 사용자명과 비밀번호 문자열을 생성·입력·복사할 필요가 없어졌고, 1Password가 사이트와 패스키 요청을 인식해 자동으로 반응함
  계정이 여러 개면 사용할 패스키를 고를 수 있어 대체로 그냥 작동하는 체계이며 비밀번호보다 훨씬 선호함

  • 직장·도서관·친구 컴퓨터에서 휴대폰의 1Password를 보고 비밀번호를 직접 입력하는 흔한 흐름을 패스키는 지원하지 않음
    비밀번호 관리자가 생성한 복잡하고 재사용되지 않는 암호보다 실질적인 보안 이점도 없음
  • “입력할 필요가 없다”는 말은 실제로 원해도 직접 입력할 수 없다는 뜻임
  • 1Password 사용자로서 가능한 곳에서는 패스키를 쓰려 하지만 전혀 “그냥 작동”하지 않음
    Windows의 Firefox는 일부 사이트에서 1Password 대신 Windows 비밀번호 관리자를 호출하며, Android에서도 Chrome과 Firefox의 처리 방식이 다른 듯함
    Microsoft 계정은 패스키가 저장된 기기에 그 계정으로 먼저 로그인해야 해서 흐름이 꼬이고 다른 방식으로 돌아가야 함
    Libby 같은 앱에서 Amazon으로 이동하면 패스키 없는 별도 비밀번호 화면이 뜨므로 비밀번호도 준비해야 함
    잘될 때는 훌륭하지만 결국 1Password와 사용자명·비밀번호 조합이 더 나은 UX로 보임
  • “그냥 작동한다”는 설명은 일반 사용자에게 핵심 의문을 남김
    패스키를 만들면 기존 비밀번호가 지워지는지, 다른 기기에서는 어떻게 로그인하는지, 새 기기에서 만들면 이전 패스키가 바뀌어 첫 기기에서 잠기는지 홍보와 안내만으로는 알 수 없음
  • 브라우저와 연동되는 비밀번호 관리자를 사용하면 말한 장점은 이미 모두 얻을 수 있고, 패스키의 제약과 단점도 피할 수 있음

• 78세 부모님께 물리적 U2F 키를 “집 현관 열쇠처럼 계정에 들어가는 데 필요한 열쇠이니 잃거나 빌려주지 말고, 예비 열쇠도 두자”고 설명했더니 완전히 이해하고 모든 계정에 추가했음
  소비자에게 기회도 주지 않은 채 이런 개념을 이해하기엔 너무 무지하다고 가정했지만, 실제로는 물리적 열쇠 비유만으로 충분했음

  • 모든 계정에 U2F 키를 두 개 이상 연결했는지 편하게 보장할 방법을 찾지 못했음
    두 키를 함께 들고 다니며 모두 등록하면 동시에 잃을 위험이 있고, 하나를 금고에 두면 어느 서비스에 어느 키를 등록했는지 추적하면서 새 서비스가 생길 때마다 예비 키를 꺼내 등록해야 함
    어느 쪽도 만족스럽지 않아 결국 백업 가능한 OTP 앱을 선택함
  • 패스키를 싫어하는 핵심 이유 중 하나는 마찰이 큰 키 관리임
  • 실제 생활에서 권한 위임을 위해 집 열쇠를 제삼자에게 빌려주거나 신뢰할 사람용 복제본을 만드는 것은 정상임
    공급업체는 소비자의 이런 사용 방식을 지원하거나 존재 자체를 인정하지 않으면서, 기업에는 복잡한 구현을 비싸게 판매하려 함
  • 중요한 것에 물리 키를 쓰고 싶지 않음
    물리 키는 잃어버리기 때문에 현관 예비 열쇠를 화분 아래 두게 되며, 항상 들고 다닐 물건만 하나 더 늘어남
  • 오프라인 매장에서는 아직 FIDO 키를 바로 살 수 없음
    휴대폰은 어디서나 구할 수 있지만 할머니에게 “Walmart 전자제품 코너에서 YubiKey를 달라고 하세요”라고 할 수 있을 때까지 문제가 남아 있음
    농촌 배송 기준 Amazon조차 최소 6일이 걸리므로 온라인 주문은 이 상황의 유효한 해결책이 아니며, 분실 키를 즉시 교체하기는 사실상 불가능함

• 패스키를 단순하다고 여기는 사람들은 대체로 모든 자격 증명을 독점 클라우드 공급업체에 맡겨 전 기기로 동기화하는 듯함
  자격 증명을 오프라인에 보관하고 직접 동기화·백업하려는 사람에게는 등록·백업·공유 절차가 정확히 어떻게 작동하는지가 중요함
  이는 원격 증명, 연령 확인, CSAM 스캔, 사이드로딩 제한과 함께 결국 Big Tech나 정부가 참여자·콘텐츠·하드웨어·소프트웨어를 검증해야만 인터넷 상호작용을 허용하는 흐름의 일부로 보임
  기술자 중에도 이를 지지하는 사람이 많아 조만간 독점 클라우드 생태계에 들어갈 수밖에 없게 될 듯함

  • 클라우드 패스키를 좋아하지만 예비 YubiKey도 보유하고 있음
    YubiKey 두 개를 마련해 하나는 은행 금고, 하나는 다른 장소에 두고 클라우드를 버릴 수도 있지만 아직 그럴 이유가 크지 않음
    패스키는 비밀번호보다 포기해야 할 것이 없고 오히려 훨씬 다루기 쉬움
    10년간 SSH 개인키를 보안 하드웨어에 보관해 물리 키 휴대에 익숙할 수는 있지만, 전반적으로 더 나은 방식이라고 봄
    비밀번호를 없애는 일은 원격 증명이나 연령 확인과 무관함
    지난 20년간 기억한 비밀번호는 개별 장비나 회사·가정 계정용 두세 개뿐이며, 나머지는 세분된 하드웨어 자격 증명으로 해결해야 함

• 패스키는 자신의 도구를 이해하고 관리하려는 기술자에게 악몽임
  이해할 능력도 의지도 없이 화면이 시키는 버튼만 누르고 누군가의 폐쇄형 생태계 안에서 사는 사용자를 위해 최적화됐음
  그런 용도에서는 잘 작동하지만 생태계를 떠나는 순간 모든 것이 깨지는 막대한 공급업체 종속을 만들며, 어쩌면 그것이 애초의 설계 목표였다고 볼 수도 있음

• HSA 사이트가 지난 로그인 때 패스키 설정을 강제해 업무용 노트북과 회사 비밀번호 관리자에 등록했더니, 이제 개인 컴퓨터에서는 계정에 접근할 수 없게 됐음
  정말 원하던 환상적인 결과임

  • 고객센터에 전화하면 몇 가지 신원 질문만 하고 접근을 허용해 주므로 결국 실질적인 보안성은 없음
  • 패스키 지지자들은 여러 개를 등록할 수 있다고 하지만, 이 상황처럼 항상 가능한 것은 아님
  • HealthEquity HSA에서도 패스키를 강제하고 있음
    아직 고용주 SSO로 로그인할 수 있어 꼭 필요해질 때까지 설정을 미루는 중임
  • “비밀번호 분실” 버튼을 누르면 됨
    패스키는 마법이 아니라 특이한 비밀번호일 뿐이며, 사이트가 복구 버튼을 구현하지 않았다면 패스키보다 사이트 구현의 결함을 보여줌

• 패스키의 문제는 UX가 아님
  Big Tech는 소비자가 범용 컴퓨팅 기기를 소유하는 것을 막고 폐쇄형 생태계로 몰아넣으려 하며, 패스키도 그 이해관계에 맞춰 설계됐음
  자유를 빼앗을 때 늘 그렇듯 명분은 안전이며, 결과적으로 사용자가 기기 소유자가 허락한 작업만 할 수 있는 기업 관리 기기용 운영 모델이 됐음
  열악한 UX는 그 근본 문제에서 파생된 결과임

  • 패스키는 Bitwarden, LastPass, KeePassXC, 물리 키, 여러 소프트웨어 토큰, TPM 저장소에서도 잘 작동함
    특정 패스키만 강제해 유독 나빴던 곳은 지금까지 Nintendo뿐이지만, 그마저 Nintendo가 한 일 중에는 덜 나쁜 축에 속함