패스키는 비밀번호를 어떻게 없앨까 — WebAuthn과 FIDO2의 동작 원리

패스키로 로그인할 때 사용자는 지문이나 얼굴, 기기 PIN을 확인할 뿐 긴 비밀번호를 입력하지 않습니다. 겉으로는 생체정보가 서버로 전송되는 것처럼 보이지만 실제 구조는 다릅니다.

 

패스키의 핵심은 사이트마다 별도의 공개키·개인키 쌍을 만들고, 서버가 보낸 일회성 Challenge에 기기가 전자서명하도록 하는 것입니다. 서버에는 공개키만 저장되며 개인키와 생체정보는 인증 장치의 보호 영역을 벗어나지 않습니다.

 

이 글에서는 패스키, WebAuthn, FIDO2, 인증 장치가 어떤 관계인지 먼저 정리한 뒤 등록과 로그인 메시지 흐름, 피싱 방지 원리, 동기화 패스키와 복구 설계까지 살펴봅니다.

패스키, WebAuthn, FIDO2는 같은 말일까

서로 밀접하지만 같은 용어는 아닙니다.

용어	의미	담당 범위
Passkey	사용자가 비밀번호 대신 쓰는 FIDO 기반 로그인 자격증명	동기화형 또는 특정 기기 결합형 공개키 자격증명
WebAuthn	웹 애플리케이션이 공개키 자격증명을 만들고 사용하는 W3C 웹 API	브라우저·RP 서버·인증 장치 사이의 등록과 인증 절차
CTAP	브라우저·운영체제 같은 Client가 외부 인증 장치와 통신하는 FIDO 프로토콜	USB·NFC·BLE 보안키와 플랫폼 간 통신
FIDO2	WebAuthn과 CTAP을 결합한 공개키 인증 체계	웹과 인증 장치를 포괄하는 표준 집합

웹사이트의 JavaScript는 navigator.credentials.create()와 navigator.credentials.get()을 호출합니다. 브라우저는 운영체제의 패스키 저장소나 보안키 같은 Authenticator와 통신하고, 서버는 반환된 서명을 검증합니다.

웹 애플리케이션 ─ WebAuthn ─ 브라우저·운영체제 ─ CTAP ─ 외부 보안키
                                      └ 플랫폼 Authenticator

그림: Passkey·WebAuthn·CTAP·FIDO2의 구성 관계 · W3C WebAuthn Level 3와 FIDO Alliance 자료를 바탕으로 재구성

비밀번호 인증과 무엇이 다른가

비밀번호 방식에서는 사용자가 알고 있는 동일한 비밀을 서버와 공유합니다. 서버가 원문 대신 안전한 해시를 저장하더라도 사용자는 로그인할 때 비밀번호를 사이트에 제출해야 합니다. 가짜 사이트에 입력하면 공격자가 그대로 재사용할 수 있습니다.

 

패스키는 비대칭키를 사용합니다.

사용자 기기: 개인키 보관 + Challenge 서명
서비스 서버: 공개키 보관 + 서명 검증

개인키는 로그인할 사이트의 RP ID에 묶여 생성됩니다. 사용자는 개인키 값을 알 필요가 없고, 서버도 개인키를 받지 않습니다. 서버 데이터베이스가 유출되어 공개키가 노출되더라도 그 공개키만으로 새로운 서명을 만들 수 없습니다.

 

생체정보의 역할도 오해하기 쉽습니다. 얼굴이나 지문은 서버에 자신을 증명하는 로그인 데이터가 아니라 기기 안의 개인키 사용을 승인하는 로컬 사용자 검증 수단입니다. 기기 PIN도 같은 역할을 할 수 있습니다.

1. 패스키 등록은 어떻게 진행될까

패스키 등록은 서버가 사용자의 계정과 새 공개키 자격증명을 연결하는 과정입니다.

서버가 등록 옵션과 Challenge를 만든다

서버는 충분한 엔트로피를 가진 일회성 Challenge, RP 정보, 사용자 식별자, 허용 알고리즘, 사용자 검증 요구사항 등을 생성합니다.

{
  "challenge": "server-random-bytes",
  "rp": {"id": "example.com", "name": "Example"},
  "user": {"id": "opaque-user-id", "name": "user@example.com"},
  "pubKeyCredParams": [{"type": "public-key", "alg": -7}],
  "authenticatorSelection": {"userVerification": "required"}
}

Challenge는 재생 공격을 막기 위해 서버가 신뢰하는 환경에서 무작위로 만들고, 등록이 끝날 때까지 세션과 연결해 임시 보관해야 합니다.

브라우저가 인증 장치에 키 생성을 요청한다

웹 애플리케이션은 navigator.credentials.create()를 호출합니다. 브라우저는 현재 Origin과 RP ID의 관계를 확인하고 사용자에게 패스키 생성 UI를 표시합니다.

 

사용자가 생체인식이나 기기 PIN으로 승인하면 Authenticator가 새로운 공개키·개인키 쌍을 만듭니다. 개인키와 RP ID, 사용자 핸들 같은 Credential Source는 인증 장치 또는 안전한 패스키 저장소에서 관리됩니다.

서버는 등록 응답을 검증하고 공개키를 저장한다

브라우저는 Credential ID, Attestation Object, Client Data 등을 서버로 보냅니다. 서버는 최소한 다음을 검증합니다.

• 반환된 Challenge가 발급한 값과 일치하는가
• origin이 허용된 HTTPS Origin인가
• rpIdHash가 기대한 RP ID의 해시와 일치하는가
• 사용자 존재와 사용자 검증 플래그가 정책을 충족하는가
• 요청한 공개키 알고리즘을 사용했는가
• Attestation을 요구한 경우 신뢰 정책을 통과하는가

검증이 끝나면 서버는 Credential ID, 공개키, 사용자 연결 정보, Sign Count와 Transport 같은 필요한 메타데이터를 저장합니다. 개인키는 저장하지 않습니다.

그림: WebAuthn 등록 Ceremony의 주요 메시지와 검증 항목 · W3C WebAuthn Level 3 등록 절차를 바탕으로 재구성

2. 패스키 로그인은 어떻게 진행될까

로그인은 서버가 “이 Challenge에 서명할 개인키를 실제로 가지고 있는가”를 확인하는 과정입니다.

서버가 인증 Challenge를 보낸다

서버는 새로운 Challenge와 RP ID, 허용 Credential 목록, 사용자 검증 정책을 제공합니다. Discoverable Credential을 사용하면 사용자가 먼저 아이디를 입력하지 않아도 브라우저가 해당 사이트에 사용할 수 있는 패스키를 제안할 수 있습니다.

인증 장치가 사용자 승인 후 서명한다

웹 애플리케이션이 navigator.credentials.get()을 호출하면 브라우저는 현재 Origin과 RP ID를 Authenticator에 전달합니다. 사용자가 지문·얼굴·PIN으로 승인하면 Authenticator는 다음 정보에 개인키로 서명합니다.

authenticatorData || hash(clientDataJSON)

여기에는 RP ID의 해시, 사용자 존재·검증 플래그, 서명 카운터와 서버 Challenge 및 Origin에 연결된 데이터가 포함됩니다.

서버가 공개키로 Assertion을 검증한다

서버는 등록 때 저장한 공개키를 찾아 전자서명을 검증합니다. Challenge, Origin, RP ID Hash, UP·UV 플래그, Credential ID, 서명 알고리즘과 정책을 확인한 뒤에만 세션을 발급합니다.

서명 유효 + Challenge 일치 + Origin 허용 + RP ID 일치 + 정책 충족
→ 로그인 성공

그림: WebAuthn Authentication Ceremony와 Assertion 검증 흐름 · W3C WebAuthn Level 3 인증 절차를 바탕으로 재구성

패스키가 피싱에 강한 이유

패스키의 개인키는 특정 RP ID에 묶여 있습니다. example.com에서 만든 자격증명을 공격자의 examp1e.com에서 사용하려 해도 브라우저와 Authenticator가 다른 RP ID로 판단하므로 해당 개인키를 제공하거나 서명에 사용하지 않습니다.

 

비밀번호 관리자는 사용자가 경고를 무시하고 비밀번호를 복사할 가능성이 있지만, WebAuthn 개인키는 웹 스크립트가 읽어 복사하는 값이 아닙니다. W3C 사양은 스크립트가 자격증명 자체에 접근하지 못하고 Credential 객체 형태의 결과만 받도록 설계합니다.

 

서버 역시 반환된 origin을 반드시 검증해야 합니다. RP ID 범위 제한이 1차 방어라면 Origin 검증은 잘못된 구현과 교차 출처 위험을 줄이는 추가 계층입니다.

 

다만 패스키가 모든 공격을 막지는 않습니다.

• 이미 인증된 세션 쿠키가 탈취되는 공격
• 사용자 기기나 브라우저 자체가 침해된 경우
• 패스키 등록 전에 계정 복구 절차가 탈취된 경우
• 악성 OAuth 승인이나 원격제어 사기
• 서버가 Challenge·Origin·RP ID 검증을 잘못 구현한 경우

패스키는 로그인 피싱과 Credential Stuffing을 크게 줄이는 기술이지 전체 계정 보안을 대체하는 만능 장치는 아닙니다.

동기화 패스키와 기기 결합 패스키

FIDO Alliance는 패스키를 여러 기기에 안전하게 동기화할 수 있는 형태와 특정 기기에 묶인 Device-bound 형태로 구분합니다.

구분	동기화 패스키	기기 결합 패스키
사용성	같은 플랫폼 계정의 여러 기기에서 사용	등록된 기기 또는 보안키가 필요
복구	플랫폼 계정의 복구 체계 활용	예비 보안키·다른 등록 자격증명 필요
주요 위험	클라우드 계정 탈취와 복구 정책 의존	기기 분실 시 계정 접근 상실 가능
적합한 환경	일반 소비자 서비스	관리자·고위험 업무·규제 환경

동기화는 개인키를 평문으로 클라우드에 올린다는 뜻이 아닙니다. 플랫폼 제공자는 종단 간 암호화와 기기·계정 보호를 적용하지만 구체적인 보호와 복구 방식은 생태계마다 다릅니다. 조직은 동기화 여부, Attestation, 기기 관리 요구사항을 위험 수준에 맞춰 결정해야 합니다.

휴대폰으로 다른 PC에 로그인하는 하이브리드 흐름

패스키가 없는 공용 PC에서도 휴대폰의 패스키를 사용할 수 있습니다. 브라우저에 표시된 QR 코드를 휴대폰으로 스캔하고 근접성을 확인한 뒤 휴대폰의 생체인식으로 승인하는 방식입니다.

 

중요한 점은 패스키 개인키를 PC로 복사하는 것이 아니라 휴대폰이 인증 장치 역할을 수행해 해당 로그인 Ceremony에 서명한다는 것입니다. 공용 PC에는 최종 서비스 세션이 남을 수 있으므로 로그아웃과 세션 관리가 여전히 필요합니다.

서버 구현에서 반드시 검증해야 할 항목

WebAuthn은 브라우저 API만 호출한다고 완성되지 않습니다. 서버 검증이 보안의 핵심입니다.

1. Challenge는 서버에서 충분히 무작위로 만들고 일회성·짧은 만료로 관리합니다.
2. 반환된 Challenge가 세션에 저장된 값과 정확히 일치하는지 확인합니다.
3. origin은 허용 목록과 정확히 비교하고 예상하지 않은 하위 도메인을 허용하지 않습니다.
4. rpIdHash가 설정한 RP ID의 SHA-256 값과 일치하는지 확인합니다.
5. UP(User Present)와 UV(User Verified) 플래그가 서비스 정책을 만족하는지 확인합니다.
6. Credential ID와 사용자 계정의 연결을 검증합니다.
7. 등록된 공개키와 알고리즘으로 Assertion Signature를 검증합니다.
8. Sign Count는 복제 의심 신호로 활용하되 동기화 자격증명의 특성을 고려합니다.
9. 등록·삭제·복구·새 기기 추가 같은 수명주기 이벤트를 감사 로그에 기록합니다.

직접 암호 처리를 구현하기보다 검증된 서버 라이브러리를 사용하되, 라이브러리가 어떤 값과 정책을 검증하는지 운영자가 이해해야 합니다.

패스키 도입 시 계정 복구가 더 중요하다

로그인만 강하게 만들고 계정 복구가 이메일 링크 하나로 끝나면 공격자는 더 약한 경로를 선택합니다.

 

권장 설계는 다음과 같습니다.

• 한 계정에 여러 패스키 등록 허용
• 패스키 목록과 마지막 사용 기기를 사용자가 확인·삭제
• 새 패스키 등록과 복구 시 강한 재인증
• 관리자 계정은 예비 하드웨어 보안키 보관
• 복구 코드의 안전한 발급과 재발급 감사
• 의심스러운 등록·삭제 이벤트 알림
• 비밀번호 병행 기간에는 기존 피싱 위험이 남는다는 안내

패스키를 추가 인증 수단으로만 제공하면 전환은 쉽지만 비밀번호 공격면은 그대로 남습니다. 서비스는 이용자 전환율과 복구 성공률을 관찰하면서 단계적으로 Passwordless 정책을 확대해야 합니다.

결론

패스키는 생체정보를 서버에 보내는 기술이 아니라 사이트별 공개키 암호를 사용해 비밀번호라는 공유 비밀을 없애는 기술입니다.

 

등록 때 인증 장치가 키 쌍을 만들고 서버는 공개키만 보관합니다. 로그인 때 서버가 일회성 Challenge를 보내면 사용자의 기기가 로컬 검증 후 개인키로 서명하고, 서버가 공개키로 검증합니다. RP ID와 Origin에 자격증명이 묶이기 때문에 가짜 사이트가 같은 개인키의 서명을 받아내기 어렵습니다.

패스키의 보안성은 강한 암호 기술뿐 아니라 브라우저의 출처 검증, 인증 장치의 사용자 승인, 서버의 정확한 Ceremony 검증과 안전한 계정 복구가 함께 작동할 때 완성됩니다.

사용자는 비밀번호를 기억하지 않아도 되고, 서비스는 비밀번호 DB 유출과 피싱·재사용 공격의 위험을 크게 줄일 수 있습니다. 다음 인증 체계를 설계한다면 비밀번호에 패치를 더하기보다 패스키 중심의 공개키 인증을 기본 경로로 검토할 시점입니다.

참고 자료

• W3C Web Authentication Level 3
• FIDO Alliance Passkeys
• Google Passkeys Developer Guide
• Google Server-side Passkey Registration
• Google Server-side Passkey Authentication