요약
패스키를 쓰지 말라는 화제의 글은 틀렸고, 그대로 따르면 오히려 피싱에 더 약해집니다.
보안 연구자 스콧 헬름이 쓴 반박 글입니다. 최근 HN에서 화제가 된 "Passkeys are a trap. Do not use them."이 사실이냐는 질문을 여러 번 받자, 패스키 라이브러리를 직접 만들어 공개한 경험을 바탕으로 답했습니다.
왜 중요한가
- 원래 글을 따라 TOTP와 비밀번호로 돌아가면, 일반 사용자는 피싱을 막아 주는 수단을 스스로 버리게 됩니다.
- 패스키가 승인된 기기만 허용하는 통제 수단이 된다는 우려는 지금 구조로는 근거가 약하며, 그런 조짐이 보일 때 반대해도 늦지 않다고 봤습니다.
핵심 내용
- 대부분이 쓰는 동기화 패스키는 증명(attestation, 인증 장치의 출처를 암호로 확인해 주는 기능) 정보를 보내지 않습니다.
- 증명이 알려 주는 것은 인증 장치의 제조사와 모델뿐이고, 운영체제나 브라우저, 탈옥 여부는 드러나지 않습니다.
- 소비자 사이트가 증명을 요구하면 사용자 대부분이 로그인하지 못하므로, 업계 지침도 오래전부터 요구하지 말라고 권해 왔습니다.
- TOTP(시간마다 바뀌는 인증 코드)는 Evilginx 같은 도구로 실시간 탈취되지만, 패스키는 도메인에 묶여 가짜 사이트에서는 아예 뜨지 않습니다.
- 원래 글이 대안으로 권한 YubiKey도 증명을 지원하므로, 그 조언은 글 자신의 우려와 어긋난다고 지적했습니다.
HN 반응
- 여러 이용자는 진짜 함정은 사용성이라며, 기기마다 저장 위치가 갈리고 구현이 엉성한 사이트가 많아 계정을 잃을까 두렵다고 했습니다.
- 비밀번호 관리자만 잘 써도 보안 이점이 같다는 주장에, 붙여넣기 실수와 자격 증명 유출을 원천적으로 막는 점은 패스키만의 장점이라는 반론이 맞섰습니다.
패스키가 함정인지 아닌지를 따질 만큼 아는 건 없지만, 사용자로서 보기에 혼란스럽고 엉망진창이라는 건 분명히 알겠어요.
웹사이트가 패스키를 설정하라고 하면, 그때 쓰고 있는 기기에 따라 구글 비밀번호 관리자, 삼성 비밀번호 관리자, iCloud 키체인, 아니면 윈도의 뭔지 모를 무언가로 들어가 버려요.
다른 플랫폼에서 같은 사이트에 들어가면 어떻게 되죠? 보안이 빡빡한 회사 컴퓨터라서, 혹은 블루투스가 아예 없어서 기기 간 인증을 못 쓰면요? 정리 좀 하자고 전부 한 플랫폼으로 모으고 싶으면요? 특정 패스키가 든 기기를 잃어버렸거나 지금 곁에 없으면요?
그런 걸 하나하나 알아볼 시간도 인내심도 없는데, 그건 완전히 '제' 문제일 수도 있겠죠. 그래도 TOTP는 비교하면 정말 거의 마찰이 없잖아요. 내 관리자에서 QR을 스캔하고, 숫자를 웹사이트에 입력하면 끝이에요. 패스키가 뭐가 더 낫다는 거죠?
저는 "패스키는 함정이다"가 바로 이 사용성 악몽에 관한 글일 줄 알았어요. 어떤 사이트는 일단 패스키로 연결하고 나면 다른 방법으로는 로그인하기가 거의 불가능해요. 패스키를 여러 개 지원하는 곳도 있고 아닌 곳도 있고요. 패스키 또는 다른 방법을 지원하는 곳도 있고 아닌 곳도 있어요.
개념과 프로토콜 자체는 꽤 탄탄하지만, 많은 기기 흐름에서 결국 "생체 정보를 비밀번호로 쓰는" 문제로 되돌아가요. 그리고 사이트가 패스키로 바꾸라고 권할 때마다 "여기가 이걸 망쳐 놓을 만한 사이트인가?" 하는 생각이 들어요.
지금까지는 30% 정도의 사이트가 망쳐 놓았어요...
바로 그게 문제입니다.
제 비밀번호 관리자와 인증 앱만큼, 즉 100% 확실하게 작동한다는 확신이 없으면 패스키를 도입할 수 없습니다.
사이트가 패스키 설정을 요구하면 대개 기기 기본 패스키로 잡힙니다(특히 iOS에서요). 그리고 LastPass 키를 기본으로 설정하는 흐름을 찾아내는 건 유난히 어렵습니다.
저는 맥북, 윈도 데스크톱, 아이폰, 아이패드를 함께 씁니다. 이 기기들에서 Firefox, Edge, Brave도 씁니다.
제가 "패스키는 함정이다"라고 하는 건 사용성의 함정이라는 뜻입니다. 패스키를 도입했다가 어느 날 곤란한 상황에서 깨어나는 일이 없을 거라고 확실하게 보증해 줄 사람이 아무도 없으니까요.
아이러니하게도 패스키는 사용자의 모든 기기에 동기화해 주는 비밀번호 관리자와 함께 쓸 때 가장 쓰기 편한데, 바로 그 경우에 기존 비밀번호 대비 보안상 이점이 가장 적습니다.
다만 패스키가 퍼진 덕분에, 비밀번호 관리자보다 더 높은 보안이 정말 필요한 사이트에서 쓸 하드웨어 보안 토큰의 지원이 넓어진 점은 고맙게 생각합니다.
구체적인 보안상 이점은, 기술에 어두운 사람이나 기술을 잘 알아도 잠이 부족한 사람이 PayPal.com 대신 p4ypal.com에 비밀번호를 복사해서 붙여 넣을 방법이 없다는 겁니다.
맞는 말이지만, 비밀번호 관리자를 제대로 설정해 두었다면 애초에 비밀번호를 복사해서 붙여 넣을 일이 없습니다. 비밀번호가 자동으로 채워지지 않으면 문제가 있다는 걸 알 수 있죠.
여기서 패스키의 이점이 0은 아니지만 최소한입니다.
저는 수십 년 동안 여러 비밀번호 관리자를 써 왔습니다. 그래도 가끔은 비밀번호를 복사해서 붙여 넣어야 해요. 웹사이트 설계가 형편없거나 적대적이기도 하고, 아직 플러그인을 설정하지 않은 브라우저나 앱에 인증해야 할 때도 있고, 플러그인이 사이트를 제대로 인식하지 못하는 버그도 있으니까요. 게다가 결국 사용자가 어디에든 복사해서 붙여 넣을 수 있다면, 사용자는 정말로 어디에든 붙여 넣습니다.
그리고 다른 보안상 이점도 있습니다. 비밀번호는 정적인 자격 증명이 핸드셰이크 과정에서 전송됩니다. 중간 어딘가에서 잘못 다뤄지면 그 루트 자격 증명 전체가 유출될 수 있습니다. 패스키에서는 이런 일이 불가능합니다. 자격 증명이 클라이언트를 떠나지 않으니까요. 어떤 구현에서는 자격 증명이 보안 영역(secure enclave) 밖으로 나가지 않아서, 클라이언트 시스템 메모리에 들어오지도 않습니다. 비밀번호는 이 근처에도 못 갑니다.
만든 기기에서 기술적으로 빼낼 수 있는 패스키라면 무슨 의미가 있나요? 저는 패스키의 전제가 애초에 복사할 수 없다는 것, 그래서 기기 접근 통제만큼은 믿을 수 있다는 것인 줄 알았는데요. 제가 뭔가 놓치고 있는 건가요?
패스키를 정말로 한 기기에만 묶어 두면, 이를테면 Secure Enclave 안에 가둬 두면 다른 사용성 문제가 생깁니다. 무엇보다 모든 웹사이트마다, 모든 기기마다 설정을 다시 해야 하니까요. 새 폰을 샀다고요? 석기시대로 돌아가는 겁니다. 새 기기에서 사이트마다 비밀번호로 인증하고, "패스키 추가"가 어디 있는지 찾아서 설치해야 하죠.
기본 비밀번호 관리자는 비밀번호를 한 번 저장해 두면 Apple, Google, Microsoft에 충성하는 한 평생 자동 완성에 그 비밀번호가 따라오는데, 이 편리함과 마찰 수준에 비하면 큰 후퇴라고 생각합니다.
며칠 전 HN 맨 위까지 올라갔던, 패스키의 여러 종류를 전부 설명한 글을 못 보신 것 같네요.
https://news.ycombinator.com/item?id=50048312
패스키가 언제나 더 안전합니다.
비밀번호 관리자도 패스키와 똑같은 보안상 이점을 주면서, 특정 업체에 묶이지도 않습니다.
전혀 아닙니다. 가장 큰 건 피싱 저항성이고, 하드웨어에 기반하면 인포스틸러에도 저항력이 있습니다.
비밀번호 관리자도 피싱 저항성을 주고, 패스키 저장소는 대부분 하드웨어 기반이 아닙니다.
일반적인 상황에서 패스키는 비밀번호 관리자보다 나은 점이 없습니다.
이점은 있어요. 다만 그걸 쓰는 사이트들이 그 이점을 대부분 제대로 살리는지는 아무도 모르죠.
현실에서 패스키를 저장하는 건 전부 잠금 해제할 때마다 생체 인증을 요구하니까, 다른 인증 요소를 또 요구하면 안 되는 게 맞아요(비밀은 "가진 것"이고 생체 정보는 "나 자신"이니까요). 그런데 실제로는 이제 모든 빌어먹을 사이트가 그놈의 "코드를 이메일로 보냈습니다" 헛짓을 고집해요.
패스키는 일부 한심한 사이트(혹은 IT 관리자)가 비밀번호에 요구하는 것처럼 아무 때나 주기적으로 바꿀 필요가 없어요.
하나가 유출되면 그것만 폐기하면 돼요. 비밀번호와는 달리요.
패스키가 10% 정도는 작동하지 않는 걸 보면 훨씬 더 안전한 것 같아요. 제가 써서 계정에 접근도 못 하는데, 공격자는 당연히 못 하겠죠 /s
그런 것 같네요. 패스키 표준을 만드는 사람들(?)은 내년에 더 잘해 보시길. 언젠가는 정리되기를 바랍니다.
이 주제를 계속 되풀이하는 글과 게시물이 많다는 것 자체가 말해 주는 게 있다고 생각해요. 스레드마다 거의 똑같아요. 한쪽은 "패스키가 나한테 안 맞는 이유는 이렇다"고 하고, 다른 쪽은 "쓰는 방법이 틀렸다"고 하죠. 그걸 보고 생각을 바꾸는 사람은 많지 않을 거예요.
기존 로그인 방식의 틀을 깨는 거라서요. 저도 기기 하나를 패스키 관리자로 설정하려다 애를 먹었습니다. 이제는 모든 기기에 각각 만들어야 한다는 걸 알았고요. 제 은행 웹사이트에는 비밀번호 하나와 서로 다른 패스키 두 개가 등록되어 있습니다. 사이트마다 구현에 문제가 있을 수 있지만, 그럴 때는 더 번거로운 비밀번호 방식을 씁니다. 비밀번호 구현 문제도 일부 사이트에서는 여전히 마주치니까요.
iOS 문제처럼 들리네요. 리눅스의 Bitwarden + Firefox나 Bitwarden + 안드로이드에서는 패스키를 저장하고 쓸 때 매끄럽지 않았던 적이 한 번도 없어요.
대표성 없는 일화를 들자면, 제 경우 Bitwarden 패스키는 대부분의 웹사이트에서 무한 루프로 끝납니다. 가져오기와 내보내기는 아직도 약속이거나 "곧 제공"이고요. 하드웨어 키의 경우 기기가 두 개 필요합니다. 저는 패스키 지지자였지만, 대형 업체들이 공유 "표준"이 으레 그렇듯 그걸 망쳐 놨어요.
Bitwarden / ProtonPass + iOS도 매끄러웠어요. 그러면 LastPass 문제 같네요.
iOS는 서드파티 비밀번호 관리자를 정말 잘 지원합니다. Strongbox와 1Password는 연동이 되는 걸 봤고, Bitwarden도 지원한다고 들었습니다. 이 경우에는 LastPass 문제라고 생각합니다.
맞아요, 패스키를 설정하라는 요청을 받을 때마다 그 계정에 나중에 접근할 수 있을지를 걸고 러시안룰렛을 하는 기분이에요. 1년쯤 전에 제가 의지하던 사이트가 생체 인식 패스키 등록을 강제하기 시작했습니다. 아무 생각 없이 폰으로 사이트에 로그인해서 거기서 등록했는데, 안타깝게도 (a) 그러면 내부 시스템에 "다른 기기"로 등록되지 않았고, (b) 그 사이트는 모바일 기기에서 제대로 작동하지 않았습니다(레거시 시스템). 그래서 데스크톱에서 로그인하면 패스키를 활성화하라고 요구하는데, 당연히 패스키는 폰에 있었죠. 접근할 방법이 없었고, 사이트는 QR 코드/블루투스 방식도 제공하지 않았어요. 정확한 이유는 기억나지 않지만 그냥 작동하지 않았고, 아마 리눅스의 Firefox가 마음에 안 든다거나 하는 문제였을 거예요.
설상가상으로, 패스키 옹호자들이 약속하는 것처럼 단일 인증 로그인도 아니었어요. 사이트는 여전히 일반 비밀번호를 요구했습니다! 사실상 3요소 인증이었어요. 아는 것(비밀번호), 가진 것(패스키), 나 자신(생체 정보)이요.
아무도 신경 안 쓰는, 듣보잡들이 만든 아무 웹사이트가 아니었습니다. 보조금을 관리하는 미국 정부 웹사이트였어요.
저희는 몇 년 전에 패스키를 도입했습니다(저는 인증/CIAM 제공 업체에서 일합니다). 대부분의 패스키가 동기화되기 전이었는데(동기화는 소름이 돋아요. 값비싼 개인 키 묶음을 여기저기 실어 나르는 거니까요).
바로 그런 이유로 저희는 패스키를 기본 로그인 수단이 아닌 대체 로그인 수단으로 만들었습니다.
게다가 꼭 로그인하는 바로 그때 물어보는데, 뭘 물어보든 그때가 최악의 타이밍이에요.
앱이나 서비스에 로그인하는 건 뭔가 하고 싶어서잖아요. 거기다 "저기, 다른 걸 하기 전에 이 복잡한 인증 설정부터 해 보시겠어요?" 하고 띄우는 건 좋게 봐줘야 짜증 나는 일이에요.
그러고 나서 보통 필요한 부분을 가리는 튜토리얼이 나오고, 뉴스레터 구독을 권하는 전체 화면 모달이 뜨고, 추적을 허용하라는 쿠키 대화상자가 나오고, 앱 스토어에 평점을 남기라는 팝업이 뜨고, 그리고...
이 모든 방해를 다 물리치고 나서야 겨우 그 망할 앱을 쓸 수 있어요.
저도 같아요. 이해가 안 가고, 상충하는 정보도 충분히 많아서(예로 이 글 쌍을 보세요) 제가 더 읽는다고 해결될 문제가 아닐 거라고 의심해요. 뭔가 근본적으로 혼란스럽고 해석하기 나름인 구석이 있을 거라고 봅니다.
제 의심은 이래요. 이걸 쓰다가 계정을 하나 이상 잃을 가능성이 상당하니, 상황이 정리될 때까지는 안 하려고요. 이걸 밀어붙이는 서비스들의 동기를 못 믿겠어요.
기술적으로 얼마나 아시는지에 따라 도움이 될 수도 있고 아닐 수도 있지만, 근본적으로 패스키는 SSH 키처럼 공개 키 암호 방식으로 작동합니다. 사이트에 패스키를 설정한다는 건 공개 키를 사이트에 보내는 것이고, 사이트는 그걸 내 계정 소유로 저장해 둡니다. 그리고 로그인할 때는 사이트가 내 공개 키로 챌린지를 만들고, 나는 개인 키로 그 챌린지를 풀어서, 대응하는 개인 키가 나한테 있음을 증명하는 응답을 보냅니다.
즉 개인 키를 사이트에 보내는 일이 없으니, 사이트 데이터베이스가 털려도 공격자는 공개 키만 얻고, 그걸로는 아무것도 할 수 없습니다(공개 키니까요).
피싱으로는 나나 내 클라이언트가 개인 키를 넘기게 만들 수 없습니다. 그런 걸 요구하는 경우 자체가 없으니까요. 개인 키는 어떤 상황에서도 어디로도 전송되지 않으므로 중간자 공격(MITM)도 불가능합니다.
계정에서 잠기는 문제는, 패스키를 잃는 건 비밀번호를 잃는 것과 같습니다. 사이트의 비밀번호 재설정 절차를 따라야 하고, 비밀번호 분실에서 복구할 수 있다면 패스키 분실에서도 복구할 수 있습니다.
훌륭한 설명이고 비유네요. 감사합니다!
조금 찔러 볼게요.
이건 처음에는 그럴듯하게 들리지만 미지의 변수와 예외 상황에 무너질 수 있는 시나리오 중 하나라고 보시나요? 최근 HN 스레드에 나온, 좀 억지스러운 비유를 들자면 "암호화폐 하드웨어 지갑을 쓰면 안전하다"고 했다가 가정 밖의 이유로 하드웨어 지갑이 털렸다는 얘기를 읽게 되는 것과 비슷한가요?
여기서 위협 모델은 기존 비밀번호 관리자의 위협 모델과 매우 비슷한 경우가 많습니다. 공격자가 비밀번호 관리자에 접근하면 거기 저장된 모든 비밀번호를 얻어 그 정보로 원하는 걸 할 수 있습니다. 패스키 관리자도 마찬가지이고, 많은 경우(마음의 평화를 위해서라도) 다른 종류의 비밀번호를 담는 비밀번호 관리자와 같은 앱/보관함이거나 그래야 합니다.
강력한 마스터 비밀번호, 생체 인증 잠금 해제, 기기 PIN을 쓰는 것처럼 비밀번호 관리자의 요건과 모범 사례 상당수가 패스키 관리에도 그대로 적용됩니다. 기기에 묶인 하드웨어 보안 영역을 지원하는 비밀번호 관리자를 쓰는 것 등도요.
하지만 평균적인 비밀번호 관리보다도, 패스키는 공개 키 기반 구조라서 별다른 설정 없이 얻는 이점이 일반 비밀번호보다 큽니다. 대부분의 패스키 구현에서 사이트(호스트 이름으로 정의됨)마다 서로 다른 공개 키를 받는 것도 그 하나입니다. (사용자에게 사이트마다 다른 비밀번호를 쓰라고 권하지만 강제하지는 않습니다. 패스키는 기술적으로 그렇게 만들어져 있고, 대체로 브라우저와 운영체제가 이를 강제합니다.) 그 공개 키가 유출되는 것은 더 이상 문제가 아니고(정말로 공개 키니까요), 유출된 공개 키는 일반적으로 다른 사이트와 앱에서 쓸모가 없습니다. (유출된 비밀번호, 심지어 솔트를 치고 해시한 비밀번호가 유출된 경우에도 부담이 되고, 레인보 테이블 공격이나 사회공학 공격, 비밀번호 재사용 공격에 쓰일 수 있습니다.)
패스키 관리에도 분명 예외 상황은 있지만, 대체로 위협 모델은 비밀번호 관리의 위협을 따릅니다. 누군가 내 기기에 물리적으로 접근할 수 있는가? 내 생체 정보나 기기 PIN에 접근할 수 있는가?
그러나 피해 범위도 일반적인 비밀번호 관리의 위협에 비해 줄어듭니다. 개인 키 하나가 유출돼도 대체로 웹사이트/앱 하나에만 영향을 줍니다. 패스키 챌린지에 한 번 서명할 수 있다고 무제한 접근이 되는 것도 아닙니다(비밀번호는 알아내면 계속 쓸 수 있죠). 챌린지에는 타임스탬프와 무작위 엔트로피가 들어 있고, 대체로 재전송 공격은 아예 지원되지 않기 때문입니다.