userVerification 심층 분석

Eiji Kitamura

이 문서에서는 WebAuthn에 있는 userVerification의 내용과 패스키 생성 또는 인증 중에 userVerification가 지정될 때 생성되는 브라우저 동작을 설명합니다.

'사용자 인증'이란 무엇인가요? 무엇인가?

패스키는 공개 키 암호화를 기반으로 합니다. 패스키를 만들면 공개 키/비공개 키 쌍이 생성되고, 패스키 제공업체가 비공개 키를 저장하며, 공개 키는 신뢰 당사자 (RP) 서버에 반환하여 저장합니다. 서버는 페어링된 공개 키를 사용하여 동일한 패스키로 서명된 서명을 확인하여 사용자를 인증할 수 있습니다. '사용자 존재' 공개 키 사용자 인증 정보의 (UP) 플래그는 누군가 인증 중에 기기와 상호작용했음을 증명합니다.

사용자 확인은 인증 과정에서 특정 사람이 아닌 올바른 사람이 존재했음을 어설션하는 선택적 보안 레이어입니다. 스마트폰에서는 일반적으로 화면 잠금 메커니즘(생체 인식이든 PIN 또는 비밀번호)을 사용하여 이를 수행할 수 있습니다. 사용자 확인이 'UV'에 보고되었는지 여부 패스키 등록 및 인증 중에 인증자 데이터에 반환되는 플래그

<ph type="x-smartling-placeholder">

</ph> <ph type="x-smartling-placeholder">

</ph> macOS의 iCloud 키체인에서 사용자 확인 대화상자

를 통해 개인정보처리방침을 정의할 수 있습니다.

를 통해 개인정보처리방침을 정의할 수 있습니다. <ph type="x-smartling-placeholder">

</ph> <ph type="x-smartling-placeholder">

</ph> Android Chrome의 사용자 인증 대화상자

서버에서 UP 및 UV를 검증하는 방법

사용자 정보 (UP) 및 사용자 인증 (UV) 불리언 플래그는 인증자 데이터 필드를 통해 서버에 신호를 보냅니다. 인증 과정에서 저장된 공개 키로 서명을 확인하여 인증자 데이터 필드의 내용을 검증할 수 있습니다. 서명이 유효하면 서버에서 플래그가 진짜라고 생각할 수 있습니다.

<ph type="x-smartling-placeholder">

</ph> <ph type="x-smartling-placeholder">

</ph> 공개 키 사용자 인증 정보의 인증자 데이터 필드

패스키 등록 및 인증에서 서버는 UP 플래그가 true인지, UV 플래그가 요구사항에 따라 true인지 false인지를 검사해야 합니다.

userVerification 매개변수 지정

WebAuthn 사양에 따라 RP는 사용자 인증 정보 생성과 어설션 모두에서 userVerification 매개변수를 사용하여 사용자 인증을 요청할 수 있습니다. 'preferred', 'required' 또는 'discouraged'를 허용하며 이는 각각 다음을 의미합니다.

• 'preferred' (기본값): 기기에서 사용자 인증 방법을 사용하는 것이 좋지만 사용자 인증 방법을 사용할 수 없는 경우 건너뛸 수 있습니다. 응답 사용자 인증 정보에는 사용자 확인이 수행된 경우 true, UV가 수행되지 않은 경우 false의 UV 플래그 값이 포함됩니다.
• 'required': 기기에서 사용할 수 있는 사용자 확인 방법을 호출해야 합니다. 사용할 수 없는 경우 요청이 로컬에서 실패합니다. 즉, 응답 사용자 인증 정보가 항상 UV 플래그가 true로 설정된 상태로 반환됩니다.
• 'discouraged': 사용자 확인 방법 사용은 권장하지 않습니다. 그러나 기기에 따라 사용자 확인을 수행할 수도 있으며 UV 플래그에는 true 또는 false가 포함될 수 있습니다.

패스키 생성을 위한 샘플 코드:

const publicKeyCredentialCreationOptions = {
  // ...
  authenticatorSelection: {
    authenticatorAttachment: 'platform',
    residentKey: 'required',
    requireResidentKey: true,
    userVerification: 'preferred'
  }
};

const credential = await navigator.credentials.create({
  publicKey: publicKeyCredentialCreationOptions
});

패스키 인증의 샘플 코드:

const publicKeyCredentialRequestOptions = {
  challenge: /* Omitted challenge data... */,
  rpId: 'example.com',
  userVerification: 'preferred'
};

const credential = await navigator.credentials.get({
  publicKey: publicKeyCredentialRequestOptions
});

userVerification에 어떤 옵션을 선택해야 할까요?

사용해야 하는 userVerification 값은 애플리케이션 요구사항과 사용자 환경 요구사항에 따라 다릅니다.

userVerification='preferred' 사용 시점

보호보다 사용자 환경이 더 중요하다면 userVerification='preferred'를 사용하세요.

사용자 확인이 보호보다 마찰이 더 많은 환경이 있습니다. 예를 들어 Touch ID를 사용할 수 없는 macOS의 경우 (기기가 이를 지원하지 않거나, 비활성화되어 있거나, 기기가 폴더형 모드이므로) 사용자에게 시스템 비밀번호를 입력하라는 메시지가 표시됩니다. 이로 인해 문제가 발생하며 사용자가 인증을 완전히 중단할 수도 있습니다. 불편함을 없애는 것이 더 중요하다면 userVerification='preferred'를 사용하세요.

<ph type="x-smartling-placeholder">

</ph> <ph type="x-smartling-placeholder">

</ph> Touch ID를 사용할 수 없을 때 macOS에서 표시되는 패스키 대화상자

userVerification='preferred'를 사용하는 경우 UV 플래그는 사용자 확인이 성공적으로 수행되면 true이고 사용자 확인을 건너뛰면 false입니다. 예를 들어 Touch ID를 사용할 수 없는 macOS에서는 사용자에게 사용자 확인을 건너뛰는 버튼을 클릭하라고 요청하며, 공개 키 사용자 인증 정보에 false UV 플래그가 포함됩니다.

그러면 UV 플래그가 위험 분석에서 신호가 될 수 있습니다. 다른 요인으로 인해 로그인 시도가 위험해 보이는 경우 사용자 인증이 수행되지 않았다면 사용자에게 추가 로그인 질문을 표시할 수 있습니다.

<ph type="x-smartling-placeholder">

</ph> 참고: 현재 google.com 인증에서는 userVerification='preferred'를 사용합니다.

userVerification='required' 사용 시점

UP 및 UV가 모두 절대적으로 필요하다고 생각되면 userVerification='required'를 사용합니다.

이 옵션의 단점은 사용자가 로그인할 때 더 많은 불편이 발생할 수 있다는 것입니다. 예를 들어 Touch ID를 사용할 수 없는 macOS에서는 사용자에게 시스템 비밀번호를 입력하라는 메시지가 표시됩니다.

userVerification='required'를 사용하면 기기에서 사용자 인증이 실행되도록 할 수 있습니다. 서버에서 UV 플래그가 true인지 확인해야 합니다.

결론

패스키를 사용하는 당사자는 사용자 인증을 활용하여 기기 소유자가 로그인할 가능성을 측정할 수 있습니다. 대체 로그인 메커니즘이 사용자 플로우에 얼마나 중요한 영향을 미치는지에 따라 사용자 인증을 요구할지, 아니면 선택사항으로 만들 것인지 선택할 수 있습니다. 서버에서 패스키 사용자 인증을 위해 UP 플래그 및 UV 플래그를 확인하는지 확인합니다.