패스키는 시크릿 모드에서 작동하나요?

점점 더 많은 기업이 웹사이트와 앱에 패스키를 도입하고 있습니다. 이 과정에서 많은 소프트웨어 개발자와 제품 관리자는 패스키가 시크릿 모드나 비공개 브라우징 모드에서 작동하는지 궁금해합니다. 이는 전반적인 사용자 경험에 큰 영향을 미치기 때문입니다.

이 블로그 게시물에서는 다음 질문에 대한 답을 찾아보려 합니다.

1. 패스키는 시크릿/비공개 브라우징 모드에서 작동하나요?
2. Chrome, Safari, Edge, Firefox의 시크릿/비공개 모드에서 패스키 인증은 어떻게 작동하나요?

이 정보를 통해 다양한 브라우저와 운영체제에서 원활한 사용자 경험을 보장하고, 애플리케이션의 보안과 편의성을 최신 수준으로 유지할 수 있습니다.

패스키는 기본적으로 기존 비밀번호 없이 사용자를 인증하는 데 사용되는 암호화 키입니다. 비밀번호 도난 및 피싱 공격과 관련된 위험을 제거하여 보안을 강화합니다.

일반적으로 패스키는 기기 내에 안전하게 저장되며, 기기가 패스키를 지원하는 한 Windows 10을 제외한 대부분의 운영체제에서는 시크릿 모드나 비공개 모드에서도 기능이 일관되게 유지됩니다(아래 참조).

시크릿 모드 또는 비공개 모드는 인터넷에 흔적을 남기지 않고 브라우징할 때 흔히 사용됩니다. 이 기능은 개인정보 보호를 중시하는 사용자에게 유용하며, 패스키와 같은 인증 방법이 이러한 모드에서 원활하게 작동하는 것이 중요합니다.

하지만 WebAuthn 개발 과정에서 운영체제와 브라우저 간의 동작이 혼란스럽고 일관성이 없어 지속적인 논의와 개선이 이루어져 왔습니다(참고 자료로 여기, 여기, 여기의 오래된 논의 및 버그 리포트를 확인하세요).

다양한 브라우저와 운영체제에서 패스키의 동작을 이해하면 호환성을 보장하고 원활한 사용자 경험을 제공하는 데 도움이 됩니다.

패스키는 시크릿/비공개 브라우징 모드에서 작동하나요?

Windows 10(22H2)에서는 패스키가 안정적으로 작동하지 않는 유일한 예외를 발견했으며, 플랫폼 인증자(Windows Hello)를 사용하려고 할 때 다음 두 스크린샷과 같은 상황을 마주했습니다.

Windows 10의 Chrome 시크릿 모드에서 표시된 패스키 오류 메시지

Windows 10의 Edge InPrivate 모드에서 표시된 패스키 오류 메시지

일반 브라우징 모드로 전환했을 때는 모든 것이 예상대로 작동했으므로, 팝업의 오류 메시지는 오해의 소지가 있습니다.

또한, 크로스플랫폼 인증자(예: YubiKey와 같은 하드웨어 보안 키 또는 QR 코드/블루투스를 통한 기기 간 인증)을 사용했을 때는 정상적으로 작동했습니다.

이 문제를 더 깊이 파고들어 브라우저 콘솔에서 다음 두 명령을 실행하여 플랫폼 인증자(PublicKeyCredential.isUserVerifyingPlatformAuthenticatorAvailable())와 조건부 UI(PublicKeyCredential.isConditionalMediationAvailable())의 사용 가능 여부를 확인했을 때 흥미로운 사실을 발견했습니다. 첫 번째 프라미스는 false를 반환했고, 두 번째는 true를 반환했습니다. 조건부 UI가 작동하려면 플랫폼 인증자가 필요하기 때문에 이는 논리적으로 맞지 않았습니다.

Chrome 129 버전부터(그리고 Chromium 기반인 Edge도 마찬가지로), PublicKeyCredential.isUserVerifyingPlatformAuthenticatorAvailable()는 Windows 10의 시크릿/InPrivate 모드에서도 true를 반환합니다. 이전에는 시크릿 모드에서 이 값이 false였습니다. 이제 true를 반환함에도 불구하고, 플랫폼 인증자는 새 패스키를 생성하는 데 여전히 사용할 수 없어 사용자 흐름이 깨지는 문제가 발생합니다.

아래 표는 Windows 10의 다양한 Chrome/Edge 버전 및 모드에서 PublicKeyCredential.isUserVerifyingPlatformAuthenticatorAvailable()의 반환 값을 보여줍니다.

관찰된 동작:

• Windows 10의 Chrome/Edge 시크릿 모드에서 프라미스가 true를 반환함에도 불구하고, 패스키 생성 시 플랫폼 인증자가 나타나지 않습니다.
• 대신 사용자에게 보안 키(예: YubiKey)를 추가하라는 메시지가 표시됩니다.
• 하드웨어 보안 키는 패스키 생성에 여전히 사용할 수 있지만, 이는 Windows Hello와 같은 플랫폼 인증자를 사용할 때 기대하는 흐름이 아닙니다.

변경의 영향: 이로 인해 시크릿/InPrivate 모드에서 플랫폼 인증자에 패스키를 추가하는 흐름이 사실상 깨지게 됩니다. Chrome 129+의 조정은 주로 시크릿 모드에서 패스키로 로그인 기능을 활성화하기 위해 이루어졌습니다. 로그인 흐름은 패스키 지원 여부를 확인하기 위해 동일한 감지 메커니즘(PublicKeyCredential.isUserVerifyingPlatformAuthenticatorAvailable())을 사용하며, 이 변경으로 로그인이 원활하게 진행될 수 있도록 보장합니다. 하지만 의도치 않은 결과로 비공개 브라우징 모드에서 플랫폼 인증자로 패스키를 생성하는 경험이 깨지는 문제가 발생했습니다.

이 변경에 대한 자세한 내용은 Chromium 소스 코드 리뷰 및 관련 이슈 트래커 토론에서 확인할 수 있습니다. 패스키에 대한 최적의 지원을 제공하려는 웹사이트의 경우, 현재로서는 시크릿 모드를 감지하는 것이 이 문제를 완화할 수 있는 유일한 방법입니다. Windows 10의 Chrome/Edge에서 사용자가 시크릿/InPrivate 모드에 있는지 식별함으로써, 웹사이트는 패스키 생성을 위해 플랫폼 인증자 옵션을 제공하는 것을 사전에 방지할 수 있습니다.

Windows Hello를 플랫폼 인증자로 사용할 때, 시크릿 모드(Chrome) / InPrivate 모드(Edge)에서 패스키를 생성하는 동안 보안 팝업이 나타납니다. 이 팝업은 패스키가 저장되어 나중에 일반 모드에서도 사용할 수 있음을 사용자에게 알립니다(이 동작은 Windows 11 22H2에서 테스트되었습니다). 사용자가 정보의 흔적 없이 계정을 생성하려는 시크릿 모드의 사용 사례 중 하나를 고려할 때, 이 경고는 타당합니다.

Android에서 시크릿 모드(Chrome) / InPrivate 모드(Edge)를 사용할 때의 동작은 Windows 11과 유사합니다. 패스키가 비밀번호 관리자에 저장될 것이며, 비밀번호 관리자에 접근할 수 있는 사람은 누구나 해당 패스키에도 접근할 수 있다는 정보성 팝업이 표시됩니다.

요약하자면, 패스키는 주요 브라우저와 운영체제에서 시크릿 모드 및 비공개 모드에서 안정적으로 작동하지만, Windows 10에서 패스키를 생성할 때는 몇 가지 예외가 있습니다. Corbado의 솔루션을 활용하여 개발자는 패스키를 효율적으로 구현할 수 있고, 제품 관리자는 보안을 유지하면서 사용자 경험을 향상시킬 수 있습니다.