2026년 9월 1일부터 Microsoft는 Entra ID에서 기본 로그인 방법으로 패스키를 포함하기 시작했으며, 2027년 2월 1일부터는 SMS 및 음성 코드의 자체 제공을 중단합니다. Google은 2023년 10월부터 개인 계정의 기본 로그인 옵션으로 패스키를 설정했습니다. 한 사람의 한 계정에 대해서는 편리합니다. 그러나 여러 계정을 운영하는 경우, 패스키는 서로 격리된 프로필을 연결하는 눈에 띄지 않는 실이 될 수 있습니다. 아래에서는 이것이 어떻게 이루어지는지, 그리고 계정 간에 키가 '유출'되지 않도록 하는 방안을 설명합니다.
왜 지금 이 문제가 제기되었는가
패스키는 2022년부터 존재했지만, 2026년에는 '사용할 수 있다'에서 '요청할 것이다'로 변화했습니다. 세 가지 구체적인 이유가 있습니다:
- Microsoft Entra ID. 2026년 9월부터 SMS 또는 전화로 로그인을 확인한 사용자에게는 자동으로 패스키가 활성화됩니다: 다음 MFA 확인 시 키 등록 제안이 나타납니다. 2027년 1월 31일까지는 연기할 수 있지만, 2027년 2월 1일부터는 연기가 불가능합니다. Microsoft는 AI를 이용한 피싱 캠페인이 12%의 일반적인 클릭률에 비해 54%의 클릭률을 기록하고 있다는 수치를 근거로 제시합니다.
- Google. 2023년 10월부터 개인 계정에서는 기본적으로 '가능할 때 비밀번호 입력 생략' 옵션이 활성화됩니다. 키가 생성되면 Google은 이를 사용하여 로그인할 것을 제안합니다.
- 키를 관리자로 간편하게 전송하기. FIDO Alliance는 Credential Exchange 표준(CXF 및 CXP 형식)을 발표했습니다. iOS 26 및 macOS 26에서는 Apple Passwords, 1Password, Bitwarden, Dashlane 및 기타 애플리케이션 간에 패스키를 암호화하여 파일을 내보내지 않고 전송할 수 있습니다. 키는 더 이상 하나의 저장소에 고정되어 있지 않습니다. 멀티 계정 운영에 있어 이는 기회이자 위험입니다.
패스키의 구조와 프로필 격리를 깨는 이유
패스키는 암호화 키 쌍입니다. 공개 키는 웹사이트에 저장되고, 개인 키는 '인증자'에 저장됩니다. 키는 도메인에 연결되어 있으므로(사양에서는 rpId로 명시됨) 피싱 사이트는 이를 얻을 수 없습니다. 멀티 계정 운영에 있어 가장 중요한 질문은 개인 키가 물리적으로 어디에 저장되는가입니다. 안티탐지 시스템은 쿠키, localStorage, IndexedDB 및 지문을 격리합니다. 키 저장소는 종종 브라우저 프로필 외부에 위치합니다:
- Windows Hello는 Windows 계정 수준에서 키를 저장합니다. 이 계정 아래의 모든 브라우저와 프로필은 동일한 저장소에 접근합니다.
- macOS의 iCloud 키 체인은 Apple ID에 속합니다. 동일한 Mac의 Chrome과 Safari는 동일한 키 세트를 볼 수 있습니다.
- Google 비밀번호 관리자는 브라우저나 전화기가 로그인한 Google 계정에 연결되어 있습니다. 하나의 서비스용 Google 계정이 20개의 프로필을 공유하는 것은 하나의 공용 금고와 같습니다.
- 확장 프로그램 관리자 (Bitwarden, 1Password 등)는 자신의 계정 저장소에 키를 저장합니다. 모든 프로필에 대한 하나의 저장소는 모든 것을 볼 수 있는 단일 지점으로 작용합니다.
여기서 전형적인 오류가 발생합니다. 계정 №7의 프로필에서 '패스키로 로그인'을 클릭하면 시스템은 동일한 웹사이트에서 계정 №3 및 №12의 키를 보여줍니다. 웹사이트는 이 목록을 보지 않습니다: 선택된 키만을 받습니다. 그러나 잘못된 클릭 하나로 인해 계정 №3이 계정 №7의 프로필, IP 및 지문으로 로그인하게 됩니다. 이러한 연결은 취소할 수 없습니다.
패스키로 로그인할 때 웹사이트가 실제로 아는 것
패스키는 리스크 스코어링을 없애지 않으며, 단지 비밀번호를 대체합니다. 로그인 시 플랫폼은 여전히 IP, 브라우저 지문 및 세션 기록을 봅니다. 또한 WebAuthn의 몇 가지 고유 신호를 받습니다:
- 키 식별자 (credential ID). 이는 '계정 — 인증자' 쌍에 대해 고유합니다.
- AAGUID — 인증자 모델의 식별자. Google과 같은 웹사이트는 계정 설정에서 키를 서명할 때 이를 사용합니다: 'iCloud 키 체인에서 생성됨', 'Google 비밀번호 관리자에서 생성됨' 등. 이는 장치의 고유 번호는 아니지만, 프로필의 전설과 일치해야 하는 또 다른 특성입니다.
- BE 및 BS 플래그 (backup eligibility 및 backup state)는 이 키가 동기화 가능한지 또는 장치에 연결되어 있는지를 보여줍니다.
결론: '모바일' 프로필이 Windows Hello에서 키로 로그인하는 것은 브라질의 시간대와 독일의 IP를 가진 iPhone처럼 비논리적으로 보입니다. 키는 프록시 및 지문과 동일한 전설에 맞아야 합니다.
단계별 계획: 하나의 계정 — 하나의 프로필 — 하나의 저장소 — 하나의 IP
- 인벤토리를 수행하세요. 여러분의 계정이 이미 패스키를 가지고 있거나 생성하라는 제안을 받은 플랫폼을 나열하세요: Google, Microsoft, 대형 마켓플레이스 및 소셜 미디어. 각 계정의 보안 설정에서 등록된 키의 수와 생성된 위치를 확인할 수 있습니다. 'Windows Hello' 및 'iCloud Keychain'과 같은 예상치 못한 기록은 삭제 후보입니다.
- 작업 프로필에 대한 시스템 키 저장소를 비활성화하세요. 프로필이 작동하는 브라우저에서 내장된 관리자에 비밀번호 및 패스키 저장을 비활성화하세요. 작업 머신에서 Windows Hello 또는 iCloud 키 체인에서 키를 생성하지 마세요. 키 생성 창에서 '이 컴퓨터'를 제안하면 다른 방법을 선택하세요.
- 각 계정에 대한 저장소를 선택하세요. 규칙은 간단합니다: 저장소는 프로필과 동일하게 분리되어야 합니다. 옵션:
- 계정 또는 하나의 클라이언트의 계정 그룹당 별도의 비밀번호 관리자 저장소;
- 가장 소중한 계정에 대한 하드웨어 키 (FIDO2);
- 자동화를 위한 소프트웨어 인증자, 이는 6단계에서 다룹니다.
- 키는 '원주율' 프로필에서만 등록하세요. 동일한 프로필, 동일한 지문, 동일한 고정 세션 프록시, 동일한 지리적 위치에서 일반적인 계정 작업을 수행합니다. 키 등록은 민감한 작업이며, 플랫폼은 이를 면밀히 관찰합니다. 절차 중 IP를 변경하면 추가 확인이 발생할 수 있습니다. 프로필에 대해 하나의 주소를 유지하는 방법은 스티키 세션 또는 프로필 안티탐지를 위한 프록시 회전 기사에서 자세히 설명했습니다.
- 예비 로그인 방법을 남겨두세요. 저장소가 사라지면 계정이 손실됩니다. 각 계정에는 두 번째 로그인 방법이 필요합니다: 다른 저장소의 두 번째 패스키, TOTP 비밀번호 또는 키와 별도로 저장되는 복구 코드. Microsoft는 Entra에서 2027년 2월까지 사용자에게 피싱에 강한 방법으로 전환할 것을 요구합니다. 등록 창이 닫히지 않도록 기다리지 마세요.
- 자동화에서 가상 인증자를 사용하세요. Chrome DevTools Protocol에는 WebAuthn 도메인이 있습니다.
addVirtualAuthenticator메서드는 ctap2 프로토콜과internal(플랫폼) 또는usb/hybrid전송을 사용하는 소프트웨어 인증자를 생성합니다.hasResidentKey및hasUserVerification매개변수는 인증자에 키 저장 및 사용자 확인을 포함합니다.getCredentials는 등록 후 전체 키를 반환합니다: credentialId, rpId, userHandle, signCount 및 PKCS#8 형식의 개인 키.addCredential는 다음 실행 시 이를 다시 저장합니다. 이렇게 하면 여러분의 비밀 저장소에서만 존재하고 특정 계정의 세션에 연결되는 키가 생성됩니다. 두 가지 주의 사항: 도메인은 실험적으로 표시되며 WebAuthn 테스트를 위해 생성되었고, 내보낸 개인 키는 비밀번호 수준의 비밀이며 그에 맞게 저장해야 합니다. - 키는 수동이 아닌 Credential Exchange를 통해 전송하세요. 관리자를 변경하거나 계정을 다양한 저장소로 분산할 경우, FIDO 표준에 따라 내장된 내보내기를 사용하세요: 이는 Apple Passwords, 1Password, Bitwarden, Dashlane, DuckDuckGo, Devolutions에서 지원됩니다. macOS에서는 일부 애플리케이션이 이 메커니즘을 아직 구현하지 않았음을 유의하세요.
주의 사항
- 기본 동기화. '이 장치에서 생성된' 키는 즉시 iCloud 또는 Google 클라우드로 전송되어 해당 계정의 모든 장치에서 나타날 수 있으며, 개인 전화기에서도 나타날 수 있습니다.
- QR을 통한 크로스 디바이스 로그인. '전화기로 QR을 스캔하세요' 시나리오(하이브리드 전송)는 실제 전화기를 프로필 세션에 연결합니다. 작업 프로필에는 불필요한 연결입니다.
- 전체 농장에서 동일한 AAGUID는 정상입니다. 수백만 명이 동일한 관리자를 사용합니다. 위험한 것은 동일한 공급자가 아니라 공통 키 또는 공통 저장소입니다.
- 패스키는 '더러운' 로그인을 치료하지 않습니다. 계정이 이미 다른 계정에서 드러난 IP로 로그인하거나 플랫폼이 싫어하는 데이터 센터에서 로그인하면 강력한 암호화도 도움이 되지 않습니다. 위험은 신호의 조합에 따라 평가됩니다.
- 두 번째 요소도 격리해야 합니다. 예비 로그인 방법이 TOTP인 경우, 비밀도 계정에 분산되어야 하며, 개인 전화의 하나의 애플리케이션에 저장되어서는 안 됩니다. 2FA와 프록시를 연결하는 방법은 프록시를 통한 작업에서의 이중 인증 자료에서 다루었습니다.
어떤 프록시가 필요하고 그 이유
패스키로 로그인할 때 가장 중요한 것은 일관성입니다: 계정은 키를 등록하고 동일한 네트워크, 동일한 지리적 위치에서 로그인해야 합니다. 따라서:
- 안티탐지의 웹 프로필은 주거용 프록시로, 계정의 국가에서 세션이 고정되어야 합니다. 이는 가정용 제공자의 주소이며, '일반 사용자가 집에 있는' 전설과 일치합니다.
- 모바일 플랫폼 및 모바일 전설이 있는 계정은 모바일 프록시를 사용해야 합니다. 가정 네트워크에서 다른 쪽 끝에서 키를 등록하는 모바일 프로필은 자신의 역사에서 벗어납니다.
- 각 요청에 대한 회전은 파싱에 적합하지만 계정 로그인에는 적합하지 않습니다. 전체 작업 세션에 여유를 두고 간격을 설정하세요.
결론
패스키는 피싱에 강한 로그인을 가능하게 하지만, 계정 간의 연결 지점을 쿠키와 비밀번호에서 키 저장소로 옮깁니다. 이 지점은 종종 안티탐지 프로필 외부에 위치합니다: Windows Hello, iCloud, Google 계정 또는 관리자 공용 저장소에 있습니다. 작업 방식은 각 계정에 대해 고유한 프로필, 고유한 키 저장소, 고유한 고정 IP 및 예비 로그인 방법을 갖는 것입니다. 자동화를 위해 CDP에서 가상 인증자가 있습니다. 2027년 2월까지 이 작업을 수행하세요. Microsoft가 등록 연기를 중단한 후에는 서두르며 실제 계정에서 문제를 해결해야 할 것입니다.