패스키를 쓰지 말고 비밀번호와 TOTP 코드로 돌아가라는 주장은 패스키의 증명 기능을 잘못 설명하고 있다고 보안 전문가 스콧 헬름(Scott Helme)이 반박한다. 그는 패스키가 도메인에 묶여 있어 피싱에 강한 반면, TOTP 코드는 가짜 사이트에 입력하면 탈취될 수 있다고 설명한다.
논란이 된 글은 패스키에 사이트가 어떤 소프트웨어로 만든 인증 수단인지 확인할 수 있는 증명(attestation) 기능이 있다고 주장한다. 이 기능이 점차 확대되면 승인된 운영체제와 프로그램만 로그인에 허용될 수 있다는 우려도 제기한다.
그러나 헬름은 iCloud Keychain, Google Password Manager, 1Password, Bitwarden 등에 저장해 동기화하는 일반적인 패스키는 웹사이트에 증명 정보를 제공하지 않는다고 설명한다. 사이트가 증명을 요청하더라도 돌아오는 값은 none이라는 것이다. 소비자 웹사이트가 증명된 패스키만 허용하면 이용자 대부분이 즉시 로그인할 수 없게 되며, 소비자 대상 사이트에는 수년간 증명을 요청하지 말라는 지침이 있었다고 덧붙인다.
증명이 제공될 때 사이트가 확인하는 정보는 인증 수단의 제조사와 모델이다. 이는 AAGUID와 제조사가 발급한 인증서 체인으로 식별한다. 헬름에 따르면 이 정보만으로는 운영체제, 브라우저, 확장 프로그램, 휴대전화의 루팅·탈옥 여부, 펌웨어 버전을 알 수 없다.
헬름은 하드웨어 보안 키인 YubiKey를 증명 우려에 대한 대안으로 추천하는 것도 앞뒤가 맞지 않는다고 지적한다. YubiKey는 증명 기능을 수행하는 인증 수단이며, 제품마다 Yubico가 발급한 증명 인증서가 포함된다. 조직이 승인된 하드웨어 키만 허용하도록 하는 기업용 증명 기능도 있다. 다만 그는 YubiKey 자체는 훌륭한 보안 키라며 사용을 권한다고 밝혔다.
TOTP는 비밀번호만 사용하는 것보다 낫지만, 코드를 가짜 사이트에 입력할 수 있다는 약점이 있다. Evilginx 같은 피싱 도구는 비밀번호와 코드를 실시간으로 실제 사이트에 전달해 로그인 세션을 탈취할 수 있다. 반면 패스키는 만들어진 도메인에 묶여 있어 브라우저가 example.com용 패스키를 examp1e.com에서 사용하지 않는다. 따라서 사용자가 코드를 읽어 입력할 필요도, 잘못된 사이트에 코드를 입력할 위험도 없다. 패스키가 중간자 공격에 저항한다는 점은 논란이 된 글의 부록에서도 인정했지만, 해당 글은 여전히 패스키를 피하라고 권한다고 헬름은 짚었다.
헬름은 웹사이트가 패스키를 제공하면 신뢰하는 비밀번호·패스키 관리자에 저장해 사용하고, 자격 증명을 다른 곳으로 옮길 수 있어야 한다면 이를 지원하는 제공업체를 선택하라고 권한다. 소비자 로그인에서 증명 기능이 확대된다면 문제를 제기할 만하지만, 현재 그런 일이 일어나지는 않았고 주요 제공업체도 이를 지원하지 않는다고 주장한다. 패스키를 피하는 것은 피싱을 막아주지 않고 오히려 계정을 피싱에 노출할 수 있다는 게 그의 결론이다.
헬름은 패스키 제공 현황을 추적하는 WhyNoPasskeys.com을 만들고, 자신의 SaaS에 패스키를 도입했으며, 직접 만든 패스키 라이브러리를 보안 검토 후 공개했다. 관련 글로는 웹사이트에서 패스키를 사용할 때의 보안 고려사항, 패스키의 기본 원리와 작동 방식, 패스키 구현의 보안 테스트, 1Password의 WebAuthn 래퍼 보안 테스트, 증명을 사용하지 않을 때의 한계도 소개했다.
댓글 (0)
로그인하면 이 기사에 내 생각을 남길 수 있어요