Google 계정, 패스키가 기본 로그인 옵션으로 활성화됨

 (blog.google)
2P by GN⁺ | ★ favorite | 댓글 1개
  • Google은 개인용 Google Account에서 패스키를 기본 옵션으로 제공해 비밀번호 없는 로그인 전환을 더 쉽게 만듦
  • 다음 로그인부터 패스키 생성·사용 프롬프트가 표시되며, 계정 설정의 “Skip password when possible” 옵션이 켜진 상태로 보임
  • 패스키는 기기 잠금 해제에 쓰는 지문, 얼굴 스캔, PIN으로 로그인하며, Google은 비밀번호보다 40% 빠르고 암호화 방식 때문에 더 안전하다고 봄
  • 비밀번호 로그인은 당분간 유지되며, 원하지 않는 사용자는 “Skip password when possible”을 꺼서 패스키 사용을 거부할 수 있음
  • YouTube, Search, Maps에서 이미 패스키가 쓰이고 있고 Uber·eBay도 지원 중이며, WhatsApp 호환성도 곧 제공될 예정임

개인용 Google Account의 로그인 기본값 변화

  • Google은 올해 초 패스키 지원을 출시한 뒤 사용자 반응이 긍정적이었다고 봄
  • 이제 개인용 Google Account 전반에서 패스키가 기본 로그인 옵션으로 제공됨
  • 다음 계정 로그인 때 패스키를 만들고 사용하는 프롬프트가 표시됨
  • Google Account 설정에는 “Skip password when possible” 옵션이 켜진 상태로 보임

패스키 사용 방식과 보안 특성

  • 패스키는 계정 로그인 시 기기 잠금 해제와 같은 지문, 얼굴 스캔, PIN을 사용함
  • Google 기준으로 패스키 로그인은 비밀번호보다 40% 빠름
  • 암호화 방식에 의존해 더 안전하며, 피싱 저항성도 갖춤
  • 사용자는 비밀번호의 숫자와 특수문자를 기억해야 하는 부담을 줄일 수 있음

비밀번호와 사용자 선택권은 유지됨

  • Google은 새로운 기술이 자리 잡는 데 시간이 걸린다고 보고, 비밀번호가 한동안 계속 남아 있을 수 있다고 봄
  • 사용자는 여전히 비밀번호로 로그인할 수 있음
  • 패스키를 원하지 않는 사용자는 “Skip password when possible” 옵션을 끄면 됨

Google 밖으로 확산되는 패스키 지원

  • 패스키 출시 이후 사용자는 YouTube, Search, Maps 같은 Google 앱에서 패스키를 사용해 왔음
  • Google은 업계 전반에서 패스키 도입이 늘어나는 흐름을 긍정적으로 보고 있음
  • Uber와 eBay는 플랫폼 로그인에서 비밀번호를 쓰지 않는 선택지를 제공함
  • WhatsApp 호환성도 곧 제공될 예정임

비밀번호 없는 로그인으로 가는 다음 단계

  • Google은 다른 온라인 계정에서 패스키를 사용할 수 있는 위치를 계속 알릴 예정임
  • 업계가 패스키로 전환하도록 독려해 비밀번호 사용을 줄이고, 결국 드물게 만드는 방향을 추진함
  • Google 계정 보안 관련 정보는 myaccount.google.com/safer에서 확인할 수 있음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 여러 사람이 말했듯이, 기기를 잃어버리면 암호학적 인증을 다시 시작하는 건 매우 어려움
    지난달 아내가 iPhone 유리를 깨뜨려 AppleCare로 수리했는데, Apple은 “유리 수리”가 사실상 내부 부품 교체와 초기화를 포함한다는 사실을 알려주지 않았음
    Apple iPhone 백업에는 eSIM 같은 암호학적 비밀값이 들어가지 않음
    결국 eSIM을 활성화하려면 이메일이 필요하고, 이메일에는 MS Authenticator가 필요하며, MS Authenticator는 SMS 없이는 활성화할 수 없는 루프에 빠짐
    사진이 있는 신분증을 잔뜩 들고 통신사 매장까지 가서 eSIM을 재발급받아야 했고, 비밀번호가 맞는데도 어떤 휴대폰 하드웨어 잠금 때문에 은행 계좌까지 잠김
    해결에 며칠이 걸렸고 여러 기관을 직접 방문해야 했음. 해외여행 중이었다면 완전히 막혔을 것임
    시대가 바뀌었고, 이제 전체 디지털 신원은 휴대폰 안의 스마트카드가 됨. 그 스마트카드는 SIM이든 온보드 TPM 칩이든, 잃어버리면 다른 사람들 입장에서는 죽은 사람이나 다름없음
    Passkey는 이 문제를 훨씬 악화시킴. 물리 SIM이라도 있으면 어떤 휴대폰에서 다른 휴대폰으로 옮길 수 있지만, Passkey는 공급업체 간 이전이 불가능함
    비명을 지르며 도망가야 함. 과장 광고를 믿지 말고, 공급업체들이 이전과 복구 해법을 제대로 내놓을 때까지 기다려야 함

    • “비명을 지르며 도망가라”는 말에 매우 동의함. 내가 통제하지 못하는 하드웨어에 인증을 묶는 것은 미래에 거의 확실한 서비스 거부로 이어질 수 있음
      사람들은 비밀번호를 싫어하지만, 현실적으로 많은 상황과 위협 모델에서는 비밀번호가 최선의 타협임. /dev/random에서 32바이트 이상 뽑아 원하는 방식으로 인코딩하면 이 우주 안에서는 누구도 무차별 대입으로 못 뚫고, 비밀번호 관리자가 재사용 문제도 해결해 줌
      게다가 저장 방식을 내가 통제할 수 있고, 마음이 놓일 만큼 중복 백업을 적용할 수 있다는 장점도 있음
    • 말한 문제들은 다 믿지만, 보통 각 서비스에 여러 Passkey를 추가할 수 있음. iPhone과 저렴한 Android 폰을 둘 다 등록해 중복성을 갖추거나, 1Password에 Passkey를 저장하는 것도 가능함
      iPhone 백업은 iCloud Keychain에 저장된 항목의 백업을 포함하며, 다른 Apple 기기나 복구 키가 있으면 다시 접근할 수 있음. 기기 암호나 복구 키만 있으면 모든 것을 다시 부트스트랩할 수 있음
      eSIM은 통신사 물건이라 특수한데, 그런 것들은 원래도 앞으로도 매장과 전화에 묶여 골치 아픈 편임
    • 여기에 더해, 요즘 많은 웹사이트는 고객 지원에 사람을 두지 않는 것을 자랑처럼 여기고, 계정이 잠겼을 때 복구를 돕지 않음. Google이나 Meta가 그런 식임
    • 뭐든 마찬가지로 백업이 필요함. Passkey를 하나 이상 가져야 함
      나는 거의 3개를 씀. 워크스테이션의 Yubikey, 휴대용 Yubikey, 휴대폰. 이 3개는 이메일용 Google과 휴대폰용 Apple을 모두 다시 시작할 수 있음. 나머지는 1Password에 있고, 이 수단들을 통해 접근 가능함
      최악의 최악의 긴급 상황에서도 이메일은 어떻게든 되찾을 수 있을 것 같음. DNS 제공업체에 신원 확인을 하고 MX 레코드를 바꾸면 다시 일을 처리할 수 있음. 그래도 일상생활에 필수라고까지 보긴 어려움. 접근을 잃으면 엄청 불편하겠지만 사형선고는 아닐 듯함
      SMS와 Signal 연락처는 다른 곳에도 있고, 은행 계좌의 돈은 수표를 써서 쓸 수 있음. 회사 관련 계정은 사무실에 직접 나타나면 들어갈 수 있음
      다만 Passkey는 일반 컴퓨터 사용자에게 너무 복잡할 가능성이 크다고 봄. 안타깝게도 “로그인할 때마다 이메일 링크를 보내줄게” 방식이 가장 사용자 친화적인 비밀번호 없는 인증처럼 보임
      Passkey를 1Password에 넣는 습관도 마음이 편하진 않음. 영원히 묶인다는 걸 아니까. 그래도 서비스가 마음에 들고, 옮기고 싶어질 때는 적어도 다시 만들어야 할 계정 목록은 있음
      가장 두려운 건 휴대폰 암호를 까먹는 상황임. 한 번은 잠에서 깼다가 아주 안 좋은 타이밍에 주의가 흐트러져 6자리 암호가 도저히 기억나지 않았음. 워크스테이션 잠금 해제에도 같은 코드를 씀. 잠깐 다른 데 신경을 돌린 뒤 근육 기억으로 겨우 떠올렸음
      정말 “내가 방금 뇌졸중이라도 온 건가” 싶은 순간이었음. 지금은 그 암호를 1Password에 저장해 두어서, 잠금 해제된 기기가 하나라도 있으면 기억을 되살릴 수 있음. 꽤 오래전 일이고 치매는 아닌 것 같고, 그냥 이상한 일시적 현상이었음
      반면 직장에서 쓰던 최대 1년 수명의 비밀번호들은 전부 완벽히 기억함. 6자리 숫자를 못 떠올리면 별 소용은 없지만
    • 비명을 지르며 도망가기 전에 글을 읽지 않아도 되도록 요약하면, 글에는 아직 비밀번호로 로그인할 수 있고 “가능하면 비밀번호 건너뛰기”를 끄면 Passkey를 거부할 수 있다고 되어 있음
      그러니 곧 비밀번호도 “Killed by Google”에 들어가고, 내 계정도 같이 들어갈 듯함. 나는 로그인된 기기를 하나도 두지 않음
      이제 남아 있는 몇 안 되는 사용처도 옮길 때가 한참 지났음. 피할 수 없는 상황이 왔을 때 회사가 내 업무 계정 Passkey를 재설정할 수 있을지 궁금함

  • 이게 올바른 방향이라고는 보지만, Google이나 iCloud 계정에서 잠겨 나와 실제로 되찾을 방법이 없었던 공포 사례를 너무 많이 봤음
    나만 이렇게 생각하는 건 아닐 것 같은데, 언젠가 아마 내 실수로 Google에서 잠기고 내 디지털 삶이 끝장날 것 같음
    민간 회사가 login.gov 같은 로그인 방식을 제공하면서, 잠겼을 때 USPS처럼 실제 사람과 이야기할 수 있게 해 준다면 기꺼이 돈을 내겠음

    • 특히 일반 사용자와 노년층에게 더 문제이고, Google은 지원이 거의 존재하지 않았던 역사가 있음. 게다가 Passkey 자체도 결함 있는 시스템임
      https://mastodon.laurenweinstein.org/@lauren/111103819626952...
      https://mastodon.laurenweinstein.org/@lauren/111211366080459...
    • 재해 복구가 2단계 인증이나 다중 인증에서 가장 큰 걱정임. PGP 같은 것이 널리 퍼지지 못한 이유 중 하나도 이거라고 봄. 항상 작고 소중한 뭔가를 관리해야 하고, 그것을 못 쓰게 되거나 악의적인 누군가가 쓰게 될 때의 파장이 문제였음
    • “계정에서 잠길 수 있다”는 옛날의 “하드 드라이브는 언젠가 고장 난다”의 최신판임
      if가 아니라 when의 문제임. 데이터를 중요하게 여기는 사람에게는 백업과 철저한 재해 복구 계획이 필수임. 어떤 회사가 내 잘못이 없어도 뭔가를 망칠 것이고, 그건 피할 수 없음
      안타깝게도 잃어버린 계정의 일부 측면에는 좋은 재해 복구 선택지가 없지만, 여러 계정을 두고 단일 장애 지점을 피하면 어느 정도 도움이 됨
    • 비관적 시나리오를 상상하는 건 행동으로 이어질 때 유용함. 이 경우 적절한 행동은 Google 계정 복구 옵션을 알아보고 활용하는 것임
      로그인할 수 있는 독립적인 방법을 여러 개 확보해야 함. 예를 들어 백업 코드를 출력해 중요한 서류와 함께 보관하는 식임
      하지만 이것도 Google 정책 변경 때문에 계정에서 잠기는 상황까지 막아 주진 못하므로, 이상적으로는 Google 계정 없이 버티는 연습도 해 봐야 함
    • 100% 동의함. 비밀번호 없는 미래는 기대되지만, 설명 없는 차단 한 번이면 물리 지갑을 잃는 것과 비슷해짐

  • Lauren Weinstein은 Passkey가 결함 있고, 특히 일반 사용자에게 엄청난 골칫거리가 될 거라며 경고하고 있음
    https://mastodon.laurenweinstein.org/@lauren/111103819626952...
    https://mastodon.laurenweinstein.org/@lauren/111211366080459...

    • 맞음. 나도 몇 년 전부터 비슷한 불만이 있었음
      개인정보 보호와 공급업체 종속 문제를 일단 제외하면, Passkey는 2단계 인증 없이 모든 웹사이트에서 같은 기본 비밀번호를 재사용하는 사람들에게 아주 나쁜 대안은 아님
      하지만 실제로 뭔가를 보호하는 데 의존하기 시작하면 금방 거대한 악몽이 됨. 게다가 이것을 비밀번호+2단계 인증과 동등한 것처럼 취급해서 더 나빠짐
    • 결함이 뭔지는 어디에서 설명함?
      “찾기 쉽다”고 하지만 정작 찾지는 못하는 것 같음
      https://mastodon.laurenweinstein.org/@lauren/111211489395997...
      사용자가 어차피 약한 서비스 비밀번호를 쓸 가능성이 높다면, 왜 약한 기기 암호가 Passkey를 피해야 할 이유가 되는지 모르겠음
    • 뭐가 골칫거리인지 명확하지 않음. 논점이 대부분의 일반 사용자에게 Passkey가 가져올 결과라면, 대다수는 모바일 기기에서 Google 계정에 로그인되어 있음
      그 경우 기기 인증이 뚫리면 어차피 계정도 침해된 것임
      특히 Google은 현재 비밀번호와 Passkey 중 하나만 선택해야 하는 구조가 아님. 기기에 Passkey가 없으면 비밀번호 로그인 흐름으로 돌아갈 수 있음
    • 이 논쟁은 데이터가 없어서 답답함. 어떤 위험이 다른 위험보다 더 나쁜지에 대한 의견만 가득함
      위험과 이점을 비교하려면 사람들이 실제로 얼마나 비밀번호를 재사용하는지, 2단계 인증을 쓰는지, 모든 계정 접근을 휴대폰 화면 잠금에만 의존하는지, 생체 인증을 쓰는지, 계정 복구가 얼마나 필요한지 등을 알아야 함
      그 데이터만이 논쟁을 정리할 수 있고, 각자 자기 상황에 따라 다르게 결론 내릴 수도 있게 해 줌
      Google은 이런 데이터 대부분을 갖고 있음. 자기 주장을 뒷받침하려면 공개해야 함
    • “약한 기기 인증”이라니? 요즘 휴대폰은 다 지문 인식이나 얼굴 인식이 있는 줄 알았음

  • 1Password가 최근 Passkey 지원을 켰는데, 1Password 밖으로 내보낼 방법이 없음을 알고 “놀랐음”
    1PUX 형식 내보내기에도, CSV에도 포함되지 않음
    즉 말 그대로 백업이 불가능함. 1Password가 다운되거나 회사가 문을 닫거나 비슷한 일이 생기면 Passkey는 그냥 사라짐. 복구할 방법이 전혀 없음

    • 현재 Passkey 분야의 큰 업체 중 누구도 Passkey 내보내기나 가져오기를 지원하지 않음. 이를 안전하게 하는 명세가 아직 합의되지 않았고, 누구도 Passkey의 평문 내보내기를 허용하고 싶어 하지 않기 때문임
      이 주제에 대한 최근 1Password Passkey AMA 글 참고:
      https://old.reddit.com/r/1Password/comments/16to6x7/hey_redd...
      1Password가 내려가는 경우에 대해 말하면, 비밀번호와 Passkey는 기기에 동기화될 때 모두 로컬에도 저장됨. 어떤 이유로 1Password에 접근할 수 없어져도 보관함 안의 모든 항목에는 계속 접근할 수 있고, 기기 간 동기화만 못 하게 됨
    • 그게 Passkey의 목적 아닌가? 사용자가 직접 다룰 수 없게 해서 사회공학 공격으로 탈취되지 않게 하는 것임
      Passkey를 기기 간에 옮기기보다는, SSH 키처럼 기기마다 다른 Passkey를 생성하고 관련 서비스에 모두 등록하는 구조라고 봐야 함
      물론 사용자가 공격자의 Passkey를 자기 계정에 추가하도록 속을 수는 있음
    • 어머니에게 바꾸라고 권하면서 대화한 적이 있는데, 어머니는 이메일이 인터넷 제공업체에 묶여 있어서 인터넷 제공업체 변경을 두려워하심
      모바일에서는 이 문제를 몇 년 전에 해결했지만 이메일은 아직도 엉망임. 교훈은 절대 종속되지 말라는 것임
    • 서드파티 자체 호스팅 비밀번호 관리자 중에 실제로 내보내기와 안전한 백업이 가능한 호환 Passkey 구현을 제공하는 게 있나?
    • 1Password의 Passkey 지원은 꽤 공격적인 성장 해킹처럼 느껴짐
      window.credentials 호출을 가로채고, Yubikey 같은 다른 검증 수단과 1Password를 함께 쓰고 싶으면 설정에 들어가 Passkey 기능 전체를 꺼야 함
      Google One Tap 프롬프트를 가로채고 전역으로 비활성화해서 자기 OAuth 프롬프트를 보여주는 방식과도 비슷함. 나는 Chrome 확장만 써서 네이티브 앱 경험이 크게 다른지는 모르겠음

  • 사용자 입장에서는 아직도 이해가 안 됨
    집에 불이 나거나 해서 Google에 로그인되어 있던 모든 기기가 망가지면 어떻게 됨? 어떻게 다시 계정에 로그인함?

    • 바로 처가 쪽 가족에게 그런 일이 있었음. 계단에서 휴대폰을 떨어뜨려 화면이 깨지고 반응하지 않게 됨
      예전 휴대폰을 하나 줘서 SIM은 잘 옮겼지만, Google 계정 로그인을 도저히 못 했음. Google이 계속 “휴대폰을 사용하라”고 집요하게 안내했기 때문임. 노트북도 이메일에서 로그아웃되어 있었음
      다행히 예전 사건 때문에 내가 백업 토큰을 갖고 있어서 해결했음. 다른 사람들은 어떻게 할지 모르겠음
    • Google이 이걸 어떻게 해결했는지는 모르겠지만, 오래된 해법이 있음. 샤미르 비밀 공유임
      키를 M개의 조각으로 나누고, 그중 N개가 있어야 재구성할 수 있게 함. 예를 들어 3/8이면 8개 조각 중 3개만 있으면 키를 복구할 수 있음. 각 조각을 신뢰하는 사람들에게 맡기고, 복구할 때 그중 최소 3명에게서 조각을 받아 키를 되살림
      내가 multipasskey라는 YC 데모에서 구현했을 때는 신뢰하는 연락처를 고르게 하고, 백그라운드에서 키 조각을 그들에게 보냈음. 복구가 필요하면 그들에게 요청하고, 충분한 조각을 받으면 기기 키를 재구성했음. 기기 키가 생기면 원격 서버에서 암호화된 키 백업을 내려받아 새것처럼 복구됨
      2017/2018년에 이 프로젝트를 multipasskey라고 부르며 동작하는 데모로 YC에 지원했지만 거절당했음. 내가 설명을 못했나 보다고 생각함
    • 덧붙이면, 이 글에서 기본적인 비기술 질문에 답하는 FAQ로 연결하지 않은 건 꽤 부실함
      기술자 입장에서는 친구에게 백업 기기를 맡기거나, Apple/Microsoft/비밀번호 관리자 계정에도 Passkey를 저장해야 한다는 뜻이라고 추정함
      하지만 Google이 더 자세히 설명해야 함
    • 실제로 화재를 겪었음. 집주인이 내 휴대폰을 챙겨 준 덕분에 그것만 남고 모든 소유물을 잃었음. 아니었으면 TOTP 앱이 전부 거기에 있어서 완전히 막혔을 것임
      그리고 절대 전화번호를 잃지 말아야 함. 사용자 이름, 비밀번호, 복구 이메일이 있어도 SMS 코드를 받을 수 없어서 Google 계정에 다시 못 들어감
    • Passkey는 새로운 기술이고, 사용자·서비스 제공자·조직 모두 배우고 적응하는 데 시간이 걸릴 것임
      이 과도기에는 기존에 제공하던 수단의 대안으로 Passkey를 제공하는 방식이 권장됨. Google과 많은 서비스 제공자가 그렇게 하고 있음
      다만 지금 제기한 질문은 Passkey가 없어도 모두가 물어야 할 계정 복구 문제임. 비밀번호를 잊거나, 비밀번호 관리자에 접근하지 못하거나, 두 번째 인증 기기를 잃으면 어떻게 로그인할지 계획이 있어야 함. Passkey 도입이 계정 복구 고민을 완전히 없애 주지는 않음
      그래도 Passkey가 계정 복구에 더 나은 특수한 경우가 있음. iCloud Keychain을 쓰는 Apple 기기에서 Google 계정용 Passkey를 만들면 그 Passkey가 iCloud에 동기화됨. 그러면 집이 불타 모든 기기를 잃어도 iCloud 계정에 접근할 수만 있으면 Google 계정과 다른 웹사이트의 Passkey를 되찾을 수 있음
      물론 “Apple iCloud 계정 접근을 잃으면?”이라는 질문은 정당함. 그래서 계정 복구 문제가 완전히 사라지지는 않지만, 많은 경우 Passkey로 상당히 줄어들 수 있음

  • 여기에 심슨의 역설이 있음
    평균적으로는 보안을 높일 수 있음. 대다수 사용자가 비밀번호를 매우 형편없이 쓰기 때문임
    하지만 비밀번호를 안전하게 쓰는 숙련 사용자에게는, 강제된다면 보안이 급격히 떨어지는 것임
    강제 전화번호 2단계 인증도 같은 효과가 있음. Big G의 경우 강제 전화번호 2단계 인증은 보안으로 포장한 반익명성 정책임. 이번 경우에는 생체 정보 확보 시도처럼 보임

    • “강제 전화번호 2단계 인증은 보안으로 포장한 반익명성 정책”이라는 말은 둘 다일 수 있음. 사실 매우 그럴 가능성이 큼
      전화번호는 대부분의 사람이 가진 최고의 장기 신원이고, Google은 수십억 사용자의 계정 복구를 말도 안 되는 규모로 지원해야 함
      많은 사람은 비밀번호와 기기를 잃지만, 전화번호를 잃는 사람은 매우 적음
      따라서 Google이 자기 플랫폼에서 신원을 부여하고 위임하는 데 전화번호를 쓰는 것은 논리적으로 이어짐. 개인정보 보호에는 나쁘지만, 사용자가 직접 관리하지 않아도 되는 제3자 인증 “자격 증명”으로 데이터를 통제하게 해 주므로 보안에는 매우 좋음
    • 숙련 사용자가 비밀번호를 안전하게 쓰는 경우 왜 보안이 급격히 떨어짐? 기기를 도난당하고 PIN이 추측될 수 있어서? 원하면 PIN 대신 긴 비밀번호를 쓸 수 있지 않나?
      그리고 이 부분은 확실치 않으니 아는 사람이 고쳐 주면 좋겠음. 약한 비밀번호, 재사용, 피싱에 면역인 숙련 사용자라고 가정해도 보안상 장점이 하나 있는 것으로 이해함. Google Passkey가 유출되더라도 유출되는 건 공개 키뿐이고, 공개 키로는 로그인할 수 없으니 유출이 거의 쓸모없어짐
    • 생체 정보는 로컬 기기 안의 키 저장소를 잠금 해제하는 데 쓰이고, 그 안에는 개인 키가 들어 있음. 거기서 공개 키를 도출할 수 있고, Passkey의 본질은 웹사이트 로그인을 검증하는 데 쓰는 공개 키/개인 키 쌍임
      Google이 생체 정보를 수집하고 있었다면 이미 그렇게 하고 있었을 것이고, 이 기능과는 무관함
      이 보안 모델의 매우 기본적인 세부사항은 iPhone이 Secure Enclave를 쓰기 시작하던 시절부터 오래전부터 참이었음. 왜 이 사이트에서 사람들이 전혀 이해하지 못하는 것에 대해 그렇게 단호하게 말하는지 모르겠고, 솔직히 놀라움
      Passkey는 서버에 로그인할 때 SSH 비밀번호 대신 SSH 키를 쓰는 것과 도덕적으로 동등한데, 그걸 웹사이트에 적용한 것임. 게다가 객관적으로도 “비밀번호를 안전하게 쓴다”는 생각으로 바꿀 수 없는 단순한 사실이 있음. Passkey는 말 그대로 피싱에 강함
    • Passkey는 Google이나 Apple에 의존하지 않음. 기업과 정부에 필요한 것처럼, 자기 소유의 보관자나 관리자를 둘 수 있음

  • 이걸 벌써 밀어붙이는 게 놀라움. 지난주 기준으로도 구현에 거친 부분이 충분히 남아 있어서 내 Workspace 테넌트에서는 비활성화했음
    가장 짜증나는 두 가지는, Advanced Protection이 아직 Passkey를 지원하지 않아 당분간 U2F를 유지해야 한다는 점과, 계정에 U2F 키가 설정되어 있으면 Google이 먼저 그것을 Passkey로 쓰라고 안내한 뒤 Passkey가 아니니 비밀번호로 로그인하라고 한다는 점임
    결과적으로 피싱 저항 다중 인증을 쓰는 사람은 기기에서 다중 인증 단계를 “기억”하게 하는 기능을 잃음. Google이 항상 비밀번호 전에 U2F 인증 요소를 요구하기 때문임
    이와 별개로, 소규모 고객 몇 곳에 Okta 기반 비밀번호 없는 로그인을 배포하려고 준비하면서 보안 키와 Passkey를 이용한 FIDO2 흐름을 기기 유형과 플랫폼 전반에서 많이 테스트해 왔음. 인증 흐름 자체는 전반적으로 마음에 들지만 주의할 함정이 많음
    정상 경로를 정리하고, 온보딩 자료를 만들고, 업무 연속성 시나리오를 문서화하는 데 꽤 많은 시간을 썼음. 개인 사용 사례는 어떤 면에서 더 어렵고, 단일 IdP가 아니라 각 서비스를 생각해야 함
    여러 환경을 지원해야 한다면 지금 쉬운 길은 1Password나 Passkey를 지원하는 다른 비밀번호 관리자에 투자하는 것임. 가장 일관된 사용자 경험을 제공하고 대부분의 플랫폼에서 작동하지만, Android 14에서는 아직 문제가 있음
    고권한 계정에는 계속 하드웨어 키를 쓸 예정이라 관리자는 FIDO2 키 한 쌍을 받음. 나머지는 Yubikey 하나를 받는데, 기기 접근을 잃거나 신뢰할 수 없는 기기에서 로그인해야 할 때 백업 역할을 함. Android도 여기서 문제임. 14에서도 비밀번호 없는 FIDO2 흐름을 지원하지 않는 것처럼 보임

    • Android가 왜 지원하겠음? Passkey는 Google이 고객을 잠금 효과에 묶어 둘 또 다른 기회를 제공하는데

  • 흥미로운 방향임. 다만 지문이나 얼굴 인식 같은 생체 정보는 사실 “비밀”이 아니라는 점을 짚을 만함
    사용자 인지나 동의 없이 관찰되거나 활용될 수 있고, 여러 면에서 비밀번호보다는 사용자 이름처럼 동작함

    • 비밀번호도 정의상 공유되므로 완전히 비밀은 아님. Passkey는 공개 키 암호화를 쓰고, 모든 면에서 더 안전함
    • 물리적으로 기기에 접근하고 지문이나 얼굴도 있어야 하는 것 아닌가?
    • Passkey는 그 자체로 생체 인증이 아님. 예를 들어 TouchID를 쓴다고 해서 Google이 지문으로 사용자를 인증하는 것이 아님
      지문은 인증에 쓰일 암호학적 키 쌍을 잠금 해제할 뿐임
      나는 Yubico Security Key를 Passkey로 쓰고 있고, 6자리 PIN으로 보호됨. 그 PIN은 기기 로컬에만 있으며, 기기를 물리적으로 가진 사람이 바로 로그인하지 못하게 막는 용도임. PIN을 10번 연속 틀리면 키가 날아감
      PIN을 입력하면 키가 잠금 해제되고, Google 계정에 들어가게 해 주는 것은 바로 그 키임

  • 비밀번호가 있는 대부분의 계정에는 “회사에 신원을 증명하면 재설정해 준다”는 안전장치가 있음. 은행 비밀번호를 기억하지 못하면 은행이 재설정해 주는 경로가 있는 식임
    Google이 통제하는 것들은 문제를 해결하기 위해 연락할 방법이 전혀 없음. 이미 모든 Google 제품에서 문제임
    모든 접근을 Google이 통제하는 문 뒤에 잠그는 건 미래의 악몽을 스스로 준비하는 일임

  • 아직 Bitwarden에 Passkey를 저장할 수 없어서 아쉬움. 그래도 이 페이지 상단 메시지에 따르면 10월에는 들어올 예정인 듯함
    https://bitwarden.com/blog/bitwarden-passkey-management/

답변달기