7P by neo 7달전 | favorite | 댓글 3개

Passkeys에 대한 꿈이 깨진 이유

  • 2019년 저자는 Rust를 위한 Webauthn 라이브러리 개발을 시작함
  • 당시에는 이 기술이 암호를 대체할 수 있을 것이라는 낙관론이 있었음
    • 2단계 인증, 암호 없는 인증, 사용자 이름 없는 인증 등을 지원할 수 있을 것으로 기대됨
  • 저자가 개발한 라이브러리는 업계에 큰 영향을 미쳤음

경고 신호

  • 크롬이 시장을 장악하고 있어서, 크롬이 지원하지 않으면 표준에서 제외되는 문제가 있음
    • Authenticator Selection Extension이 대표적인 예시
  • 미국에서 열리는 대면 회의에서 주요 결정이 이뤄지는 것도 문제
    • 국제적인 참여자들이 배제되는 상황

하락세

  • 2022년 Apple이 Passkeys를 발표함
    • 초기에는 잘 설계된 것처럼 보였으나, 이후 리더의 발표로 인해 Passkey가 Resident Key로 정의됨
    • 이는 저장 공간이 작은 보안 키를 배제하는 결과를 가져옴
  • 이후 Passkey는 사용자를 플랫폼에 가두는 수단으로 변질됨

악화되는 상황

  • Chrome과 Safari는 보안 키 대신 caBLE 사용을 강요함
    • 사용성이 매우 떨어지는 방식
  • Android는 Passkey 지원 웹사이트에서 보안 키 사용을 막음
    • 개발자 예제는 구글 Passkey만 사용하도록 유도
  • 사용자들이 Passkey 사용에 많은 어려움을 겪고 있음
    • 버그, 복잡한 과정, 키 유실 등의 문제 발생
  • Apple Keychain에서 Passkey가 삭제되는 일이 빈번히 발생

전망

  • 저자는 Passkey가 일반 소비자에게는 실패할 것으로 예상함
    • 기업의 이익 추구로 인해 사용자 경험이 훼손됨
  • 심지어 저자의 파트너는 암호 방식이 Passkey보다 낫다고 말함
  • 기업에서는 여전히 보안 키가 필요하지만, 사용성 문제는 남아있음
  • 저자는 webauthn-rs 프로젝트는 계속 유지할 예정이지만, Passkey 대신 다른 방안을 모색 중

GN⁺의 의견

  • Passkey가 보안 키를 배제하고 플랫폼 종속성을 심화시키는 방향으로 흘러가는 것은 우려스러운 지점임. 사용자의 선택권을 제한하는 것은 바람직하지 않아 보임.
  • 기술을 발전시키면서도 사용성을 개선하는 것이 필요해 보임. 지나치게 복잡해지거나 제한적이 되어서는 안될 것 같음.
  • 소수 기업의 영향력이 커지면서 표준화 과정에서 문제가 발생하는 것도 해결이 시급해 보임. 보다 개방적이고 투명한 의사결정 구조가 마련되어야 할 듯함.
  • 대안으로 제시된 디바이스 인증서나 스마트카드 방식은 흥미로워 보임. 기존 Passkey의 한계를 극복하면서도 사용성을 개선할 수 있는 방안이 될 수 있을 것 같음.
  • 아직은 과도기적 단계인 만큼 앞으로도 지속적인 기술 발전과 사용자 피드백 수렴이 이뤄져야 할 것으로 보임. 다양한 이해관계자가 협력하여 보다 나은 인증 체계를 만들어가기를 기대함.

MICROSOFT INTERNET EXPLORER
ACTIVE-X

Hacker News 의견
  • Passkeys에 대한 가장 큰 이슈는 그것들을 제공하는 회사들을 신뢰할 수 없다는 것임. 보안상의 이유로 플랫폼에 잠겨있지만 플랫폼 잠금과 구분하기 어려운 경우가 많음. Apple 기기에서 Passkey를 만들면 해당 기기에서 절대 벗어날 수 없으며 이를 변경할 방법이 없음. 이는 피싱으로부터 안전하지만 Apple이 키를 삭제하거나 iPhone을 버리려면 어떻게 해야 할지 모르겠음.

  • Passkeys에 대한 긴 토론에서는 보안의 "알고 있는 것" 부분에 대한 이상한 회피가 보임. 미국에서는 법원과 법 집행기관이 사용자 이름, 지문, 망막 스캔, Face ID 등을 합법적으로 얻을 수 있지만, 뇌에서 무언가를 추출할 권리는 없음. Passkeys는 "알고 있는 것"을 "가지고 있는 것"으로 대체하는 것을 선호하는데, 이는 보안에 악몽임.

  • 반대 의견: Passkeys를 사랑함. Firefox 브라우저와 1Password 매니저를 사용하며, iPhone에서는 1Password + Firefox를 사용함. passkeys.directory를 보고 GitHub, Google, Microsoft 등의 로그인을 Passkeys로 전환함. "Passkey로 로그인"이 아닌 "Touch ID로 로그인" 등의 용어가 혼란스러움. 1Password가 기기 간에 Passkeys를 동기화함. 공용 컴퓨터에서 로그인이 필요하면 불편할 수 있지만 그렇게 자주 하지 않음.

  • Passkeys는 아직 명확한 멘탈 모델이 없어서 피하고 있음. 기존 비밀번호 관리자로 생성된 임의의 비밀번호를 사용 중이라 전환할 필요성을 느끼지 못함. 사용자 이름/이메일 + 비밀번호는 이해하지만 "앱 전용 비밀번호"의 고통을 기억하면 일부 오픈소스/CLI 도구가 Passkeys와 잘 통합되지 않을까 걱정되어 상황이 안정될 때까지 기다리는 게 좋음.

  • Apple Keychain 생태계에 전적으로 투자했으며 여러 Apple 기기를 가지고 있어 Passkeys가 훌륭함. 개발자로서 취약한 SMS 2FA의 한계를 매일 겪고 있음. 사용자들이 쉽게 사회공학적으로 속아 2FA 코드를 넘겨줄 수 있음. Passkeys는 더 안전한 솔루션을 제공해 개발자가 사용자가 CS에 전화해 크게 읽어주는 걸 걱정하지 않아도 됨. SIM 스와핑으로 Passkey가 손상되지 않고, 사기꾼과 Passkey를 공유할 수 없음.

  • 기술자로서 Passkeys가 어떻게 작동하고 더 나은지, 정확히 무엇인지 잘 모르겠음. 보안 기능이 사용자 이름과 비밀번호를 기억하고 안전한 곳에 저장하는 것만큼 간단하지 않으면 작동하지 않음. 장치에 있는 키에 대해 언급되는데 휴대폰과 PC를 모두 사용할 때 어떻게 액세스하는지, 처음에 사용자 이름/비밀번호가 필요한지, 장치에 플러그인해야 하는 키가 필요한지 궁금함.

  • Usernameless는 최적화가 지나친 것 같음. 사용자가 로그인 시 사용자 이름을 사용하는 것이 합리적이고 좋은 일임. 어떤 사용자 이름을 사용하는지 상기시켜 줌. 사용자가 Usernameless Passkey를 사용해 서비스에 액세스하다가 어떤 이유로 Passkey를 잃어버리고 서비스용 사용자 이름도 잊어버려 계정 복구 프로세스를 시작할 수 없는 상황이 발생할 수 있음.

  • Passkeys의 기술적 작동 방식을 모르는 사람들은 다음 구현 가이드를 참고하면 좋음: https://webauthn.guide/ Passkeys에 대한 혐오감이 이해되지 않음. 인증을 위해 공개키 챌린지로 이동하는 것은 웹 보안을 위한 큰 발전임. 각 브라우저/OS는 개인키를 보호하고 백업함. 키를 잃어버려도 "비밀번호 찾기" 흐름을 사용해 인증 자격 증명을 재설정할 수 있음.

  • Passkeys 사용을 고려하려면 다음 요구 사항이 충족되어야 함:

  1. 소프트웨어에서 Passkey를 가질 수 있어야 함(보안 문제가 있더라도)
  2. attestation 기능을 비활성화할 수 있어야 함

Firefox나 Linux의 Chrome에서 WebAuthn 구현이 이러한 요구 사항을 충족하는지는 확인해보지 않았음.

  • 2FA 공간의 발전 상황을 따라가려 노력 중인데 Passkeys가 가장 혼란스러웠음. Passkeys가 차세대 기술이라는 과대광고는 많이 봤지만 실제로 무엇이고 어떻게 작동하는지에 대한 설명은 찾기 어려웠음. 보안키에 저장된 키라는 걸 알고 실망함. 도메인 이름 기반으로 키를 즉석에서 생성하는 아이디어가 마음에 듦. Passkeys의 장점은 웹사이트에서 사용하는 사용자 이름을 기억할 필요가 없다는 것이지만 사소한 장점임.

  • 도메인 이름 기반으로 키를 즉석에서 계산하고 재구성하는 (FIDO2 기반? WebAuthn 기반?) 기술의 공식 이름이 무엇인지 묻는 관련 질문에 대한 답변: https://fy.blackhats.net.au/blog/… 에서 찾았음. 즉석에서 재구성된 키를 "non-resident credential"이라고 함.