WebAuthn 상주 키: 패스키로서의 검색 가능한 자격 증명

패스키(Passkeys)와 그 기반이 되는 WebAuthn 프로토콜은 인증 환경에 혁신을 가져오고 있습니다. 하지만 WebAuthn 서버를 올바르게 설정하는 것은 까다로운 작업이 될 수 있습니다. 잘못된 설정은 취약점을 유발할 뿐만 아니라, 나중에 설정을 변경해야 할 경우 기존 패스키를 망가뜨릴 수도 있습니다. 이 블로그 게시물은 종종 복잡하게 느껴지는 WebAuthn 명세를 더 잘 이해하고, 여러분의 사용 사례에 가장 적합한 설정이 무엇인지 조언을 드리고자 작성되었습니다.

WebAuthn은 세 가지 주요 개체를 중심으로 작동합니다.

• 신뢰 당사자(Relying Party, RP): 사용자를 인증하고자 하는 여러분의 웹 서비스입니다. RP는 클라이언트에 챌린지(challenge)를 보내고, 응답을 검증하며, 패스키의 공개 키를 관리합니다.
• 인증자(Authenticators): 자격 증명을 소유하고 있음을 증명할 수 있는 장치입니다. 예를 들어 스마트폰, 노트북 또는 보안 키(예: YubiKey)가 있습니다. 인증자는 Windows Hello나 Apple의 Touch ID/Face ID와 같이 플랫폼에 특화된 것일 수도 있고, 보안 키(예: YubiKey)처럼 여러 플랫폼에서 사용 가능한 것일 수도 있습니다.
• 클라이언트(Clients): 일반적으로 웹 브라우저나 네이티브 앱으로, RP와 인증자 사이의 중개자 역할을 합니다. 데이터가 정확하고 안전하게 흐르도록 통신을 용이하게 합니다.

Want to try passkeys yourself in a passkeys demo?

Try Passkeys

다음은 인증 프로세스(로그인 또는 회원가입) 중의 대략적인 데이터 흐름입니다.

1. 클라이언트 시작: 프로세스는 클라이언트 측에서 시작되며, 보통 사용자가 로그인이나 회원가입을 시도할 때입니다. 예를 들어, 사용자가 "WebAuthn으로 로그인" 버튼을 클릭하면 클라이언트는 RP에 챌린지를 요청합니다.
2. RP 요청: RP는 클라이언트에 챌린지를 다시 보냅니다. 이 챌린지는 무작위로 생성된 값으로, 이어지는 응답의 진위성을 보장합니다.
3. 클라이언트에서 인증자로: 회원가입 시, 클라이언트는 인증자에 공개-개인 키 쌍을 생성하여 새로운 패스키를 만들도록 요청합니다. 로그인 시, 클라이언트는 인증자에 챌린지에 서명하도록 요청합니다. 이 작업은 인증자에 있는 개인 키를 사용하여 이루어지며, 이 개인 키는 이전에 RP에 저장된 공개 키와 쌍을 이룹니다.
4. 인증자 응답: 회원가입 시, 인증자는 공개 키를 클라이언트에 다시 보냅니다. 로그인 시, 인증자는 챌린지에 서명하고 이 서명된 어설션(assertion)을 클라이언트에 다시 보냅니다.
5. 클라이언트에서 RP로: 클라이언트는 이 새로운 공개 키 또는 서명된 어설션을 RP에 전달합니다.
6. RP 검증: RP는 공개 키를 저장하거나, 저장된 공개 키를 사용하여 서명된 어설션을 검증합니다. 유효하다면 인증은 성공합니다.

Ben Gould

Head of Engineering

I’ve built hundreds of integrations in my time, including quite a few with identity providers and I’ve never been so impressed with a developer experience as I have been with Corbado.

10,000+ devs trust Corbado & make the Internet safer with passkeys. Got questions? We’ve written 150+ blog posts on passkeys.

Join Passkeys Community

위에서 설명한 대략적인 프로세스 흐름은 WebAuthn 회원가입 및 로그인 프로세스를 설명합니다. 패스키는 WebAuthn 위에 구축되었습니다. 원래 패스키라는 용어는 WebAuthn보다 더 기억하기 쉽고 비기술적인 용어로 같은 것을 설명하기 위해 사용되었습니다. 더 나아가, 패스키는 클라우드 계정이나 비밀번호 관리자를 통해 패스키를 동기화하는 기능 등 표준 WebAuthn에 비해 더 많은 기능을 제공합니다.

다음 섹션을 더 잘 이해하기 위해, WebAuthn 프로토콜의 몇 가지 중요한 용어를 정의하여 공통된 이해를 갖도록 하겠습니다.

• 자격 증명 ID(Credential ID): 자격 증명 ID는 인증자가 생성한 특정 공개 키 자격 증명에 할당된 고유 식별자입니다. 이를 통해 신뢰 당사자(RP)는 인증 프로세스에 사용할 올바른 공개 키 자격 증명(PublicKeyCredential)을 식별하고 선택할 수 있습니다.
• 공개 키 자격 증명(PublicKeyCredential): 브라우저나 네이티브 앱의 WebAuthn API에서 반환되는 기본 데이터 구조입니다. 회원가입 시의 증명(Attestation) 데이터와 로그인 시의 어설션(Assertion) 데이터를 모두 포함합니다. 본질적으로 RP가 프로세스를 검증하는 데 필요한 데이터를 담고 있습니다.
• 증명(Attestation): WebAuthn 맥락에서 증명은 인증자의 출처와 무결성을 증명하는 역할을 합니다. 회원가입 시, 인증자가 "사용자의 자격 증명을 안전하게 등록했으며, 이를 검증하는 데 사용할 수 있는 명세서가 여기 있습니다"라고 말하는 방식입니다. 그러면 신뢰 당사자는 서명이 허용된 특정 인증자(예: YubiKey)로부터 왔는지 확인할 수 있습니다. 모든 패스키 인증자가 이러한 증명으로 응답하는 것은 아니며, 일부는 유용한 데이터를 보내지 않기도 합니다(여기에서 패스키 인증자 목록 참조). 더 많은 인증자(주로 보안 키, 예: YubiKey)를 식별하는 AAGUID(인증자 증명 GUID)는 FIDO 얼라이언스 메타데이터 서비스에서 찾을 수 있습니다.
• 어설션(Assertion): 회원가입 절차 후 사용자가 로그인하려고 할 때, 인증자는 어설션을 생성합니다. 어설션은 기본적으로 공개 키 자격 증명(PublicKeyCredential)과 서명된 챌린지를 합친 것입니다. 이 어설션은 사용자가 실제 개인 키를 노출하지 않고 등록된 공개 키에 연결된 개인 키를 소유하고 있음을 증명합니다. 이는 인증자가 "이 사람이 진짜 사용자이며, 제가 보증할 수 있습니다"라고 말하는 방식입니다.

Subscribe to our Passkeys Substack for the latest news.

Subscribe

상주 키(Resident keys, RKs)와 비상주 키(non-resident keys, NRKs)는 WebAuthn 프로토콜에서 사용되는 두 가지 유형의 암호화 키이며, 주로 저장 위치와 검색 메커니즘에서 차이가 있습니다.

정의:

상주 키는 인증자 자체에 직접 저장됩니다. 이는 보안 키(예: YubiKey), 플랫폼의 보안 영역(secure enclave)(예: iPhone의 Secure Enclave) 또는 노트북의 신뢰할 수 있는 플랫폼 모듈(TPM)일 수 있습니다. 조건부 UI(패스키 자동 완성)는 상주 키에서만 작동하며, WebAuthn 워킹 그룹은 현재 상주 키를 패스키로 간주하기 위해 이를 요구하고 있습니다.

다음 스크린샷에서는 YubiKey에 저장된 모든 상주 키(자격 증명 ID, rpID, 사용자 이름, 표시 이름) 목록을 볼 수 있습니다. 비상주 키는 인증자에 저장되지 않으므로 목록에 없습니다.

로그인 흐름:

출처: William Brown

로그인 과정에서 신뢰 당사자는 자격 증명을 지정하지 않고 클라이언트(브라우저)에 요청을 보냅니다. 클라이언트는 인증자(여기 차트에서는 보안 키)에 쿼리를 시작합니다. 인증자는 해당 신뢰 당사자에 대한 모든 상주 키를 발견하고 클라이언트(브라우저)는 원하는 상주 키를 선택합니다. 이 상주 키는 챌린지에 서명하는 데 사용됩니다. 서명은 인증자에서 클라이언트를 통해 신뢰 당사자로 전송됩니다.

장점:

1. 간소화된 사용자 경험: 상주 키의 가장 큰 장점 중 하나는 인증자가 사용자 핸들(예: 이메일, 전화번호, 사용자 이름)을 저장하여 로그인 시 사용자 핸들을 미리 채워줄 수 있다는 것입니다. 사용자는 사용자 핸들을 기억하거나 입력할 필요가 없어, 특히 생체 인식 기능이 있는 장치에서 로그인 프로세스가 간소화됩니다. 이는 조건부 UI를 통해 자동으로 이루어질 수도 있습니다.
2. 장치 특정 인증: 상주 키는 인증을 특정 장치에 묶어 추가적인 보안 계층을 제공할 수 있습니다. 이는 사용자가 신뢰할 수 있는 장치에서 로그인하는지 확인하려는 서비스에 특히 유용할 수 있습니다.
3. 조건부 UI(패스키 자동 완성): 조건부 UI는 상주 키에서만 작동하여 가장 원활한 로그인 경험을 제공합니다(자세한 내용은 아래 참조).

단점:

1. 저장 공간 제한: 일부 인증자는 저장 용량이 한정되어 있습니다. 특히 보안 키(예: YubiKey)의 경우, 저장할 수 있는 상주 키의 수에 제한이 있는 경우가 많습니다(대부분 8개에서 약 100개 사이의 제한이 있음). 이 한도에 도달하면 새 키를 위한 공간을 만들기 위해 오래된 키를 삭제해야 하거나, 사용자가 다른 인증자를 사용해야 할 수도 있습니다.
2. 인증자 분실: 인증자, 예를 들어 보안 키(예: YubiKey)나 스마트폰을 분실하거나 손상시키면 해당 장치의 모든 상주 키가 손실됩니다. 이로 인해 사용자는 계정을 다시 등록하거나 복구할 때까지 여러 서비스에서 잠길 수 있습니다. 클라우드 계정(예: iCloud 키체인, Google 비밀번호 관리자)이나 최신 비밀번호 관리자(예: 1Password 또는 Dashlane)을 통해 키를 동기화하면 이러한 손실을 방지할 수 있습니다.
3. 보안 우려: 상주 키가 있는 인증자를 도난당한 경우, 공격자가 키를 추출하려고 시도할 수 있습니다. 최신 인증자는 추출을 방지하기 위한 강력한 보안 메커니즘을 갖추고 있지만(예: 사용자가 강력한 PIN, 비밀번호 또는 제스처로 장치를 보호), 위험은 미미하더라도 여전히 존재합니다.

사용 사례: 개인 스마트폰이나 노트북과 같이 사용자가 자주 인증하는 장치에 이상적입니다.

Want to find out how many people use passkeys?

View Adoption Data

정의:

비상주 키는 반대로 인증자에 저장되지 않습니다. 대신, 인증자는 (내부적으로 보호되는 마스터 키를 기반으로) 새로운 키 쌍을 생성하고, 이 새로운 키 쌍의 공개 키를 자격 증명 ID(시드(seed)를 포함)와 함께 회원가입 시 서버(신뢰 당사자)에 보냅니다. 그러면 서버는 이 공개 키를 사용자 계정과 연결합니다. 이후 인증에서는 인증자가 자격 증명 ID를 받아 시드를 추출하고 마스터 키와 결합하여 개인 키를 다시 파생시킵니다. 이 키는 인증자의 보호된 메모리에서 일시적으로만 사용할 수 있기 때문에 암호학에서는 임시 키(ephemeral key)라고도 불립니다.

로그인 흐름:

출처: William Brown

로그인 과정에서 신뢰 당사자는 먼저 인증을 요청하는 사용자를 식별해야 하며(예: 사용자 핸들, 이메일, 전화번호 또는 사용자 이름 요청), 그런 다음 해당 사용자에 대해 알고 있는 자격 증명 ID를 클라이언트(브라우저)에 보냅니다. 클라이언트는 이를 인증자(여기서는 보안 키)에 전달합니다. 인증자는 자격 증명 ID를 인증자의 마스터 키와 함께 사용하여 임시 개인 키를 파생시키고, 생성된 키로 챌린지에 서명한 후 클라이언트(여기서는 브라우저)에 반환하며, 클라이언트는 이를 신뢰 당사자에 전달합니다. 비상주 키는 원래 패스키가 도입되기 전에 2단계 인증 요소로 사용되었습니다. 따라서 사용자를 먼저 식별하는 것이 일반적인 로그인 프로세스의 일부였습니다.

장점:

1. 확장성: 비상주 키는 인증자에 상주하지 않으므로 사용자는 다양한 서비스와 연결된 거의 무제한의 비상주 키를 가질 수 있습니다. 이는 수많은 플랫폼에 걸쳐 계정을 가진 사용자에게 특히 유용합니다.
2. 로밍 기능: 비상주 키는 보안 키(예: YubiKey)와 같은 로밍 인증자에 이상적입니다. 사용자는 동일한 보안 키(예: YubiKey)를 사용하여 여러 장치와 플랫폼에서 인증하여 일관된 경험을 제공받을 수 있습니다.
3. 인증자 저장 공간 의존도 감소: 적절한 WebAuthn 서버 설정을 통해 인증자의 저장 공간 제한에 대해 걱정할 필요가 없습니다. 이는 보안 키(예: YubiKey)와 같은 저용량 저장 공간을 가진 인증자에게 특히 유리할 수 있습니다.

단점:

1. 사용자 핸들이 필요하여 UX 저하: 비상주 키의 가장 큰 단점은 사용자가 사용자 핸들(예: 이메일, 전화번호, 사용자 이름)을 제공해야 한다는 점으로, 조건부 UI를 통한 사용자 이름 자동 완성을 불가능하게 만듭니다. 이 사용자 핸들은 임시 키로 래핑된 키(ephermal key-wrapped key)를 계산하는 데 필요한 자격 증명 ID와 연결되어야 합니다.
2. 잠재적인 관리 부실: RP는 사용자 계정과 공개 키 간의 연관성을 관리하고 보호해야 합니다. 관리 부실이나 취약점은 보안 문제로 이어질 수 있습니다.

사용 사례: 여러 서비스나 플랫폼에서 사용되는 보안 키(예: YubiKey)와 같은 로밍 인증자에 이상적입니다.

보안 키(예: YubiKey)가 있고 두 개의 온라인 서비스 A와 B에 등록한다고 상상해 보세요. 서비스 A에는 상주 키를 사용합니다. 서비스 B에는 비상주 키를 사용합니다. 서비스 A에 인증할 때는 보안 키(예: YubiKey)를 탭하기만 하면 사용자 이름을 지정할 필요 없이 로그인됩니다. 서비스 B의 경우, 먼저 브라우저나 네이티브 앱에 사용자 이름을 입력해야 합니다. 그러면 서비스가 연결된 자격 증명 ID를 보안 키(예: YubiKey)로 보내고, 보안 키는 인증을 위해 임시 개인 키를 다시 생성합니다.

본질적으로, 상주 키와 비상주 키 모두 암호화 인증을 활용하여 보안을 강화하지만, 사용자 경험과 저장 메커니즘이 달라 다양한 사용 사례에 맞춰져 있습니다.

Want to experiment with passkey flows? Try our Passkeys Debugger.

Try for Free

조건부 UI는 패스키/WebAuthn의 획기적인 기능입니다. 사용자가 비밀번호를 기억할 필요가 없을 뿐만 아니라, 신뢰 당사자에 가입할 때 사용한 사용자 핸들(예: 이메일, 전화번호, 사용자 이름)도 기억할 필요가 없게 되어 사용자의 부담을 더욱 덜어줍니다. 특히, 신뢰 당사자의 서비스를 가끔 사용하는 경우 이는 큰 진전입니다.

이것이 가능한 이유는 로그인 페이지가 열리자마자 신뢰 당사자 서버가 백그라운드에서 클라이언트에 챌린지를 보내기 때문입니다(이 호출에서는 자격 증명 ID를 보낼 필요가 없다는 점을 기억하세요). 클라이언트는 이 챌린지를 받아 이 인증자에서 신뢰 당사자 ID와 일치하는 패스키를 확인하고 자동 완성 메뉴를 통해 선택지를 제공하며, 사용자는 여기서 적절한 패스키를 선택할 수 있습니다.

또한, 자동 완성 메뉴에서 패스키를 선택하는 즉시 로그인 프로세스가 시작되므로 사용자는 로그인 버튼을 한 번 더 클릭할 필요가 없습니다.

CTAP은 FIDO2 표준의 기본 프로토콜로, 클라이언트(예: 브라우저)와 인증자(예: 보안 키, YubiKey 또는 스마트폰) 간의 통신 격차를 해소합니다. CTAP을 더 잘 이해하기 위해, 상주 키와 비상주 키에 미치는 영향을 분석하기 전에 먼저 다른 프로토콜 버전을 간략히 살펴보겠습니다.

이전 버전으로, 종종 U2F(Universal 2nd Factor)라고 불리며 주로 2단계 인증을 위해 설계되었습니다. U2F에서 서버는 챌린지를 제공하고 인증자는 개인 키 소유를 증명하는 응답을 제공합니다. 하지만 U2F는 상주 키를 지원하지 않으므로, 2단계 인증을 요청할 때 프로세스의 일부였기 때문에 사용자를 위해 어떤 키를 사용할지 식별하기 위해 항상 서버 측 조회가 필요합니다.

U2F의 후속 버전인 CTAP2는 상주 키 지원을 도입하여 비밀번호 없는, 사용자 이름 없는 인증을 가능하게 했습니다. 상주 키를 사용하면 인증자가 사용자의 사용자 이름과 자격 증명 ID(신뢰 당사자 ID와 함께)를 저장하므로, 인증 중에 신뢰 당사자 서버가 이를 제공할 필요가 없습니다. 이는 더 원활한 UX를 향한 중요한 도약입니다.

하지만 CTAP2에는 과제가 있습니다. 주목할 만한 문제 중 하나는 상주 키 관리입니다. 예를 들어, CTAP2.0 장치에서 특정 상주 키를 삭제하려면 종종 전체 장치 초기화가 필요합니다(따라서 마스터 키도 재설정되어 모든 비상주 키도 더 이상 작동하지 않게 됨). 이는 사용자 친화적이지 않으며 단일 장치에 여러 상주 키가 저장된 시나리오에서 문제가 될 수 있습니다. 이로 인해 CTAP2.0 장치의 상주 키는 신중하게 사용해야 합니다. 특히 보안 키(예: YubiKey)의 제한된 공간을 실수로 채우고 싶지 않을 것입니다.

CTAP2.1은 CTAP2의 후속 버전으로, 프로토콜에 추가 기능과 개선 사항을 가져왔습니다. CTAP 2.1의 몇 가지 핵심 사항은 다음과 같습니다.

• 더 나은 상주 키 관리: CTAP 2.1은 장치에서 특정 상주 키를 개별적으로 관리, 업데이트 및 삭제할 수 있습니다.
• 기업 증명: 이 기능을 통해 기업은 직원이 사용하는 키에 대해 더 많은 통제권을 가질 수 있습니다. 기업이 사용 중인 키가 회사에서 발급한 것인지 확인할 수 있는 방법을 제공합니다.
• 다중 사용자 인식: 일부 인증자는 여러 사용자를 인식할 수 있습니다. CTAP 2.1은 이러한 인증자가 어떤 사용자가 인식되었는지 표시할 수 있는 방법을 제공합니다.
• 하위 호환성: CTAP 2.1은 CTAP2와 하위 호환되도록 설계되어, 이전 버전을 지원하는 장치와 플랫폼이 새 버전과도 계속 작동할 수 있도록 보장합니다.

상주 키, 비상주 키 및 다양한 CTAP 버전을 살펴본 후, 이제 신뢰 당사자 측, 즉 WebAuthn 서버 측을 더 깊이 분석해 보겠습니다.

WebAuthn의 유연성(그리고 복잡성)은 서버 설정, 특히 authenticatorSelection 객체에 크게 기인합니다. 이 객체는 클라이언트가 작업에 적합한 인증자를 선택하도록 안내합니다.

{
    "rp": {
        "name": "corbado.com",
        "id": "corbado.com"
    },
    "user": {
        "id": "dGVzdefEyMjE",
        "name": "test-username",
        "displayName": "test-username"
    },
    "challenge": "mhanjsapJjCNaN_Ttasdfk1C0DymR-V_w_0UVOPsdfdfJG2ON_FK5-ODtqp33443tgqHzuuDjv-NUUmMAE4hg",
    "pubKeyCredParams": [
        {
            "type": "public-key",
            "alg": -7
        },
        {
            "type": "public-key",
            "alg": -257
        }
    ],
    "timeout": 60000,
    "excludeCredentials": [],
    "authenticatorSelection": {
        "authenticatorAttachment": "platform",
        "residentKey": "preferred",
        "requireResidentKey": false,
        "userVerification": "preferred"
    },
    "attestation": "none",
    "extensions": {
        "credProps": true
    }
}

이 서버 옵션은 인증자가 클라이언트 장치에 어떻게 부착되어 있는지를 지정합니다. 인증자가 클라이언트와 통신하는 방식에 대한 통찰력을 제공합니다.

가능한 값

• Platform: 인증자가 클라이언트 플랫폼에 부착되어 있어 제거할 수 없음을 나타냅니다.
• Cross-platform: 인증자가 클라이언트 플랫폼에 묶여 있지 않고 여러 장치에서 사용할 수 있음을 나타냅니다.

사용 사례 및 예시

• Platform: 노트북에 내장된 지문 스캐너나 휴대폰의 얼굴 인식 시스템(예: Face ID, Touch ID 또는 Windows Hello)이 예입니다.
• Cross-platform: USB 보안 키(예: YubiKey), 블루투스 장치 또는 NFC 카드가 예입니다.

WebAuthn 레벨 1 명세에서는 이 서버 옵션을 requireResidentKey라고 불렀으며, 부울 값 true(인증자가 상주 키를 생성해야 함) 또는 false(인증자가 비상주 키를 생성해야 함)를 가질 수 있었습니다. WebAuthn 레벨 2에서는 이 서버 옵션을 새로운 서버 옵션 residentKey로 대체했습니다.

가능한 값

• Required: 인증자는 반드시 상주 키를 생성해야 합니다(불가능할 경우 작업은 실패해야 함).
• Preferred: 인증자는 상주 키 생성을 시도해야 합니다(불가능할 경우 비상주 키를 생성해야 함).
• Discouraged: 인증자는 반드시 비상주 키를 생성해야 합니다(불가능할 경우 작업은 실패해야 함).

사용 사례 및 예시

• Required: 사용자 이름 없는 로그인을 원하거나, 사용자가 이전에 등록한 장치에서만 인증하도록 하려는 시나리오(사용자 자격 증명을 특정 장치에 바인딩하여 추가 보안 계층 추가)에 이상적입니다.
• Preferred: 웹 서비스가 가능하다면 최상의 로그인 UX(상주 키를 통해)를 제공하고 싶지만, 상주 키가 불가능할 경우 비상주 키도 지원하려는 시나리오에 적합합니다.
• Discouraged: 서비스가 패스키 인증을 제공하고 싶고, 사용자가 저장 기능이 없는 인증자를 포함한 모든 인증자를 사용할 수 있도록 보장하면서 자격 증명을 특정 장치에 바인딩하지 않으려는 경우입니다.

사용자 확인은 인증자와 상호 작용하는 사람이 합법적인 소유자인지 확인하는 프로세스를 의미하며, 일반적으로 PIN 입력, 지문 제공 또는 얼굴 인식과 같은 특정 인증 제스처를 요구합니다.

때때로 사용자 존재(UP)도 사용자 확인과 유사하게 언급되거나 사용되지만 실제로는 몇 가지 차이점이 있습니다. 사용자 존재는 누군가가 물리적으로 존재하며 장치와 상호 작용하고 있다는 것만 확인합니다. 그 사람의 신원을 확인하지는 않습니다. 추가 신원 확인 없이 보안 키를 간단히 터치하는 것만으로도 사용자 존재를 충족할 수 있습니다. 패스키/WebAuthn의 경우, 사용자는 항상 존재해야 합니다.

가능한 값

• Required: 작업에 반드시 사용자 확인이 있어야 합니다.
• Preferred: 작업에 가능하다면 사용자 확인이 있어야 하지만, 없어도 진행할 수 있습니다.
• Discouraged: 작업에 사용자 확인이 없어야 합니다.

사용 사례 및 예시

• Required: 은행이나 의료와 같은 고보안 애플리케이션에 이상적이며, 사용자 신원 확인(예: 지문 또는 PIN)이 중요합니다.
• Preferred: 추가 보안이 보너스이지만 엄격하게 필요하지는 않은 일반 애플리케이션에 유용합니다.
• Discouraged: 위험이 낮은 작업이나 사용자 확인이 불편할 수 있는 시나리오에 적합합니다.

패턴

• 인증자 부착: platform
• 상주 키: required
• 사용자 확인: required

예시: 기업 애플리케이션에서 직원들이 회사에서 지급한 노트북의 내장 지문 인식기를 사용하여 비밀번호 없이 로그인하기를 원합니다. 자격 증명은 장치에 저장되고, 사용자는 매번 지문으로 확인해야 합니다.

패턴

• 인증자 부착: cross-platform
• 상주 키: required
• 사용자 확인: required

예시: 사용자가 자신의 온라인 뱅킹을 위해 보안 키(예: YubiKey)를 등록합니다. 그들은 사용자 이름을 입력할 필요 없이 이 키를 사용하여 모든 장치에서 인증할 수 있습니다.

많은 하드웨어 기반 보안 키(예: YubiKey)는 내재적인 저장 공간 제약이 있습니다. 이 제한은 장치에서 사용 가능한 물리적 메모리와 제조업체의 설계 고려 사항 때문입니다.

예시: YubiKey는 20개의 상주 키만 저장할 수 있는 용량을 가질 수 있습니다. 이 한도에 도달하면 기존 키를 삭제하지 않고는 추가 상주 키를 추가할 수 없습니다.

해결책:

• 상주 키의 선택적 사용: 모든 사용자에 대해 상주 키를 사용하는 대신, 특정 역할이나 시나리오에 대해 고려하세요. 예를 들어, 강화된 보안이 필요한 관리자 역할이나 높은 권한을 가진 사용자에게 상주 키를 우선적으로 사용하세요.
• 사용자 교육: 사용자에게 보안 키(예: YubiKey)의 한계에 대해 알리세요. 무제한 상주 키를 사용할 수 있는 장치(예: 노트북 또는 스마트폰)로 전환하도록 권장하세요.

다른 인증자는 상주 키 요청을 다르게 처리할 수 있습니다. 일부는 명시적으로 요청하지 않아도 기본적으로 상주 키를 생성할 수 있는 반면, 다른 인증자는 명시적인 지침이 필요할 수 있습니다.

다른 플랫폼에서 다른 WebAuthn 서버 옵션에 대한 일관되지 않은 동작은 주요 문제입니다. 예를 들어, iOS는 전달된 WebAuthn 서버 옵션에 관계없이 항상 상주 키를 생성하는 반면, Android는 옵트인(예: residentKey: preferred 또는 residentKey: required)이 필요합니다.

동작 외에도, 서버 측에 저장된 데이터를 기반으로 저장된 자격 증명이 상주 키인지 비상주 키인지 100% 확신할 수 없다는 점이 더 큰 문제입니다. 대신, 몇 가지 확인 절차를 따르고 범위를 좁힐 수 있지만(아래 참조), 여전히 자격 증명의 동작이 예상과 일치하기를 바랄 수밖에 없습니다.

그 이유는 자격 증명 속성 확장(credential properties extension)(clientExtensionResults.credProps.rk는 true 또는 false)에 자격 증명 종류(상주 키 또는 비상주 키)에 대한 정보를 저장하라는 WebAuthn 제안이 있기 때문입니다. 그러나 모든 WebAuthn 확장은 선택 사항이므로 RP에 이 정보를 제공하는 것이 보장되지 않습니다. 예를 들어, iOS는 이 정보를 보내지 않으므로(상주 키인지 비상주 키인지 알 수 없음) 문제가 됩니다.

우리의 연구 과정에서, 우리는 두 개의 WebAuthn 데모 페이지(https://webauthn.io 및 https://webauthntest.identitystandards.io/)를 사용하여 다양한 플랫폼과 인증자(Windows 10, Windows 11, Android 7, Android 13, iOS17, macOS Ventura, YubiKey)에서 생성된 자격 증명에 대한 더 자세한 정보를 얻기 위해 동작을 테스트했습니다. 후자는 레거시 requireResidentKey 속성(WebAuthn 레벨 1)으로 작업하고 이를 residentKey 속성(WebAuthn 레벨 2)과 결합할 수 있는 가능성을 제공합니다. 그러나 결과는 신뢰할 수 없었습니다(예: iOS에 대해 비상주 키라고 표시되었지만 명확하게 조건부 UI가 작동함).

우리가 찾은 가장 신뢰할 수 있는 확인 체계는 다음과 같습니다.

1. WebAuthn 서버 설정에서 "residentKey" 속성이 무엇인지 확인합니다.
   1. "residentKey: required"이고 자격 증명이 성공적으로 생성되면 -> 상주 키입니다.
   2. "residentKey: preferred" 또는 "residentKey: discouraged"인 경우 다음 확인으로 넘어갑니다.
2. credProps.rk 확장이 지원되고 서버의 자격 증명에 저장되어 있습니까?
   1. credProps.rk = true이면 자격 증명은 상주 키입니다.
   2. credProps.rk = false이면 자격 증명은 비상주 키입니다.
   3. credProps가 비어 있으면 자격 증명 유형을 알 수 없습니다.

보시다시피, 이것은 범위를 좁히는 데 도움이 되지만, 여전히 알 수 없는 옵션이 남아 있어 키 유형을 100% 확신할 수 없습니다.

이는 SUSE의 William Brown이 그의 훌륭한 기사에서 밝힌 내용과도 일치합니다. 그는 신뢰 당사자가 상주 키를 요구할 경우 보안 키(예: YubiKey)가 어떻게 쓸모없어질 수 있는지 설명합니다(우리는 그의 표를 확장했습니다).

표에서는 다른 WebAuthn 서버 상주 키 옵션에 대해 상주 키가 생성되었는지(true), 비상주 키가 생성되었는지(false) 또는 다른 일이 발생했는지를 볼 수 있습니다.

해결책:

• 철저한 테스트: 배포하기 전에 다양한 인기 인증자에서 WebAuthn 구현을 테스트하여 동작을 이해하세요.
• 명시적인 서버 설정: WebAuthn 서버를 설정할 때 요구 사항을 명시적으로 하세요. 패스키만 사용하려면 residentKey 옵션을 required로 설정하세요(참고: 이로 인해 상주 키 용량이 제한된 인증자와 관련하여 다른 문제가 발생할 수 있음, 위 참조).

사용자가 보안 키(예: YubiKey)의 저장 한도에 도달하면 오류가 발생하거나 새 자격 증명을 등록할 수 없을 수 있습니다. 이는 혼란과 불만을 유발할 수 있습니다.

해결책:

• 점잖은 오류 처리: 사용자의 보안 키(예: YubiKey)가 가득 찼을 때 이를 알리는 명확한 오류 메시지를 구현하고 문제 해결 방법에 대한 지침을 제공하세요.
• 안내 워크플로: 사용자가 상주 키를 관리하는 방법에 대한 단계별 가이드나 튜토리얼을 제공하여 독립적으로 문제를 해결할 수 있도록 하세요.

9. 개발자 및 제품 관리자를 위한 모범 사례

위에서 보셨듯이, 선택하는 WebAuthn 서버 설정은 인증 프로세스의 사용자 경험과 보안에 상당한 영향을 미칠 수 있습니다. 정보에 입각한 결정을 내리려면 이러한 설정의 미묘한 차이를 이해하는 것이 중요합니다.

상주 키 vs. 비상주 키: 대부분의 사용자가 주로 스마트폰이나 노트북과 같은 개인 장치에서 서비스에 액세스하는 경우 상주 키가 적합한 선택입니다. 상주 키는 장치 자체에 저장되며 동일한 장치를 자주 사용하는 사용자에게 원활한 인증 경험을 제공합니다. 그러나 보안 키(예: YubiKey)를 사용하는 사용자의 경우 비상주 키가 더 적절할 수 있습니다.

사용자 확인(UV) 설정: 달성하려는 보안 수준에 따라 사용자 확인 프로세스를 얼마나 엄격하게 할지 결정할 수 있습니다. 높은 보안을 목표로 하는 경우 PIN, 지문 또는 얼굴 인식(userVerification: preferred 또는 userVerification: required)을 요구하는 것이 좋습니다.

증명 및 신뢰성: 증명을 통해 인증자의 출처와 무결성을 확인할 수 있습니다. 모든 인증자를 신뢰할지 아니면 특정 제조업체의 인증자만 신뢰할지 결정하세요. 이는 민감한 데이터를 다루고 고품질의 신뢰할 수 있는 인증자만 사용하도록 보장하려는 경우에 중요할 수 있습니다.

대체 메커니즘: 항상 대체 메커니즘을 마련해 두세요. 사용자가 인증자를 분실하거나 오작동하는 경우, 계정에 액세스할 수 있는 다른 방법이 있어야 합니다. 이는 백업 코드, SMS 확인, 이메일 매직 링크 또는 기타 다단계 인증 방법을 통해 가능합니다.

지속적인 학습: 패스키와 WebAuthn의 환경은 계속해서 진화하고 있습니다. 최신 개발, 취약점 및 패치를 최신 상태로 유지하세요. 개발팀이 패스키 및 WebAuthn 관련 워크숍, 웨비나 및 컨퍼런스에 참여하도록 장려하세요.

사용자 온보딩 및 교육: 패스키 인증을 도입할 때 사용자가 그 이점과 작동 방식을 이해하도록 하세요. 회원가입 과정에서 명확한 지침을 제공하고 사용자가 패스키를 설정하고 사용하는 데 도움이 되는 리소스(예: FAQ 또는 비디오 튜토리얼)를 제공하세요.

이러한 모범 사례를 준수함으로써 개발자와 제품 관리자는 보안과 사용자 경험의 균형을 맞추면서 패스키 인증을 효과적으로 구현할 수 있습니다.

웹사이트나 앱에서 주류 채택을 위해 패스키를 구현하고 싶고, 대부분의 사용자가 스마트폰이나 노트북을 사용할 것이므로 보안 키(예: YubiKey)를 지원할 필요가 없다면 다음 설정을 권장합니다.

• authenticator: platform
• residentKey: required
• userVerification: required

이점:

• 생성된 모든 키가 상주 키이므로, 이 설정은 조건부 UI를 허용하여 사용자가 사용자 이름을 기억할 필요가 없으므로 로그인을 더욱 원활하게 만듭니다.
• Apple, Google, Microsoft의 모든 최신 장치가 지원되며 패스키를 사용합니다.

WebAuthn 서버 설정은 복잡하지만 인증을 위한 강력하고 유연한 프레임워크를 제공합니다. 이러한 설정을 마스터하는 것은 중요합니다. 단순히 새로운 표준을 구현하는 것이 아니라 사용자 인증의 보안과 효율성을 근본적으로 개선하는 것이기 때문입니다.

본질적으로, WebAuthn 서버 설정을 이해하는 것은 더 안전하고 효율적이며 미래 지향적인 애플리케이션을 구축하는 데 대한 투자입니다. 디지털 환경이 발전함에 따라 이러한 기술에 정통하는 것은 필수 불가결해질 것입니다. 최신 정보를 얻으려면 패스키 커뮤니티에 가입하거나 아래 뉴스레터를 구독하세요.