FIDO2와 패스키: 비밀번호 없는 인증과 복구 설계

1장 개념과 보호 목표#

FIDO2는 WebAuthn과 CTAP을 통해 공개키 기반 인증을 구현하는 표준 체계입니다. 서버는 비밀번호 대신 등록된 공개키로 인증 요청의 서명을 검증하며, 사용자는 기기 잠금 해제 등으로 인증기 사용을 승인합니다.

2장 원리와 구분#

패스키는 서비스의 RP ID와 연결되어 피싱 사이트가 다른 사이트의 자격증명을 그대로 쓰기 어렵게 합니다. 생체인증을 사용하더라도 생체정보 자체를 웹 서비스로 보내는 것은 아닙니다. 동기화되는 패스키와 기기에 묶인 자격증명은 보관·복구·위험 가정이 다르므로 같은 정책으로 취급하지 않아야 합니다.

사용자 확인과 사용자 존재 확인은 구분해야 합니다. 단순히 버튼을 누르는 동작과 PIN·생체 방식으로 인증기 사용자를 확인하는 동작의 의미가 다릅니다. 등록된 인증기를 관리하는 화면에도 재인증과 변경 알림을 적용하면 계정 탈취 후 공격자가 새 수단을 추가하는 위험을 줄일 수 있습니다.

3장 패스키는 서비스별 공개키 자격증명이다#

서버는 비밀번호의 후보를 검증하는 대신 등록된 공개키로 응답의 서명을 확인합니다. 사용자의 기기는 개인키 사용을 보호하고 PIN·생체 확인 등의 방식으로 인증기 사용을 허용합니다. 웹 서비스가 생체정보 원본을 받아 저장해야 하는 구조가 아닙니다.

FIDO2는 WebAuthn과 인증기 통신의 CTAP을 연결하는 표준 체계입니다. 브라우저·플랫폼·외부 인증기의 역할을 구분하면 서버가 무엇을 저장하고 검증해야 하는지 이해하기 쉽습니다.

4장 등록은 새로운 로그인 수단을 계정에 연결한다#

이미 계정에 접근한 사람이 새 인증기를 등록할 수 있다면 탈취 세션의 공격자가 자기 인증기를 추가할 수도 있습니다. 등록 절차의 기존 계정 확인·재인증·챌린지·변경 알림을 보호해야 합니다. 새 공개키가 어느 사용자에게 연결되는지도 서버가 결정합니다.

sequenceDiagram
 participant S as 서버
 participant B as 브라우저
 participant A as 인증기
 S->>B: 계정에 연결한 등록 챌린지
 B->>A: 등록 요청과 서비스 문맥
 A->>A: 사용자 확인과 키 생성
 A-->>B: 자격증명 공개 정보
 B->>S: 등록 응답
 S->>S: 챌린지·origin·RP ID 등 검증 후 저장

5장 로그인은 새 챌린지에 대한 응답을 검증한다#

서버는 요청마다 정해진 수명과 일회성을 갖는 챌린지를 발급합니다. 인증기는 해당 서비스 문맥에서 응답에 서명하고 서버는 등록된 공개키로 확인합니다. 이전에 서명한 응답을 다시 받았다고 새 로그인으로 허용해서는 안 됩니다.

서명만 확인하는 것으로 끝나지 않습니다. 응답이 기대한 요청·origin·RP ID·사용자 확인 정책과 맞는지 검증합니다. 클라이언트가 보낸 계정 ID를 임의의 공개키와 연결하는 오류도 점검합니다.

6장 RP ID와 origin이 피싱 저항성에 연결된다#

자격증명은 서비스의 RP ID와 연결되고 브라우저의 출처 문맥을 검증합니다. 다른 사이트가 비슷한 로그인 화면을 만들었다고 같은 자격증명으로 의도한 서비스의 인증을 수행할 수 있는 것은 아닙니다. 비밀번호를 사용자가 직접 가짜 사이트에 입력하는 방식과 다른 보호 구조입니다.

운영 도메인·서브도메인·프록시·테스트 환경의 설정을 실제 배포와 맞춰야 합니다. 검증을 끄거나 광범위한 출처를 허용하면 기대한 경계를 약화시킬 수 있습니다.

7장 사용자 존재와 사용자 확인#

버튼 접촉 등은 사용자 존재를, PIN·생체 확인 등은 사용자 확인을 표현하는 데 사용됩니다. 서비스의 위험 수준에 맞춰 어떤 검증 결과를 요구할지 정합니다. 단순히 인증기가 응답했다는 사실을 사용자의 강한 신원 확인과 동일하게 보면 안 됩니다.

인증 정책은 서버에서 확인합니다. 클라이언트 화면에서 생체 확인을 요청했다는 표시만으로 응답의 검증 결과를 생략하지 않습니다. 지원하지 않는 인증기·접근성의 대체 수단도 고려합니다.

8장 동기화형과 기기 결합형의 보관 차이#

동기화형은 여러 기기에서 이용과 복구가 편리할 수 있지만 동기화 계정의 보호와 생태계의 복구 가정을 포함합니다. 기기 결합형은 특정 기기의 보호 경계를 활용할 수 있으나 분실·고장·대체 기기 등록을 준비해야 합니다. 사용자와 업무에 맞춰 허용 정책을 정합니다.

상황	확인할 선택	함께 설계할 절차
일반 고객의 다중 기기	동기화·플랫폼 지원	계정 복구·기기 분실
민감한 관리 업무	허용 인증기와 확인 수준	별도 등록 승인·대체 수단
외부 보안키	기기 호환·휴대·분실	추가 키 등록·회수

9장 인증 수단 관리 화면도 보안 기능이다#

이름·등록일·사용 이력과 삭제 기능을 제공하면 사용자가 모르는 인증기를 찾아 회수할 수 있습니다. 다만 표시만으로 실제 키를 확실히 구분할 수 있는지와 개인정보 수집 범위를 검토합니다. 등록·삭제·복구에는 알림과 감사기록을 연결합니다.

등록된 키를 삭제한 뒤 관련 세션이 계속 유지되는지 정책을 정합니다. 인증 수단 회수와 이미 발급된 세션 회수는 별도 작업입니다.

10장 모든 기기를 잃은 경우의 복구#

복구 경로가 단순한 개인정보 질문이나 쉽게 탈취한 메일만으로 강한 인증을 해제하면 우회 경로가 됩니다. 계정 종류와 위험에 맞는 근거·지원 절차·추가 지연·변경 알림 등을 설계합니다. 누구나 무조건 복구할 수 있는 편의와 강한 보호 사이의 요구를 명확히 해야 합니다.

flowchart LR
 L["기기 분실"] --> R["허용한 복구 근거 확인"]
 R --> A["새 인증기 등록"]
 A --> C["분실 자격증명 회수"]
 C --> S["관련 세션과 변경 알림 처리"]

11장 실패·도메인·분실 시험#

만료·재사용 챌린지, 다른 출처, 미등록 공개키, 요구한 사용자 확인의 누락을 각각 시험합니다. 신규 기기 추가·분실·삭제·복구·지원하지 않는 브라우저도 확인해야 실제 사용자에게 운영 가능한 인증이 됩니다.

패스키는 강한 로그인 수단의 중요한 선택지이지만 API 인가·세션 보호·계정 복구·단말 안전성까지 자동으로 완성하지는 않습니다. 각 경계를 분리해 검증하면 도입 효과를 정확히 설명할 수 있습니다.

12장 적용 사례와 운영 방법#

도입할 때는 챌린지의 일회성·만료, origin과 RP ID 검증, 사용자 확인 여부를 설정합니다. 신규 기기 등록이나 분실 후 복구가 기존 로그인보다 약하면 공격자가 복구 경로를 노릴 수 있습니다. 지원 기기와 접근성도 실제 사용자 환경에서 확인합니다.

13장 등록과 인증에서 검증하는 값이 다르다#

패스키 등록은 계정에 새로운 공개키 자격증명을 연결하는 절차입니다. 로그인은 서버의 일회성 챌린지에 대한 서명을 등록된 공개키로 확인합니다. 서버가 챌린지를 충분히 예측 불가능하게 만들고 요청·사용자·유효기간에 연결해야 이전 응답을 재사용하기 어렵습니다. origin과 RP ID 검증도 라이브러리의 옵션을 실제 배포 도메인과 맞춰야 합니다.

사용자 확인은 인증기가 PIN이나 생체 방식으로 사용자를 확인했는지를 뜻하며 단순 접촉의 사용자 존재 확인과 다릅니다. 기기의 잠금 해제 수단과 웹 서비스 계정의 권한은 구분됩니다. 패스키가 등록되었다는 사실만으로 계정의 관리 기능을 무제한 허용해서는 안 됩니다.

14장 분실·동기화·새 기기 등록을 함께 설계한다#

동기화형은 여러 기기에서 이용하기 쉽지만 동기화 계정의 보호와 복구를 함께 고려합니다. 기기에 묶인 자격증명은 특정 하드웨어의 보호 경계를 활용할 수 있으나 분실 시 대체 수단이 필요합니다. 관리자·일반 고객의 위험이 다르다면 동일한 등록 정책을 적용하기보다 허용 인증기와 복구 수준을 구분합니다.

패스키를 추가하거나 삭제하는 관리 화면에는 재인증·변경 알림·기존 자격증명 회수 기능을 둡니다. 시험은 신규 등록, 도메인 불일치, 만료 챌린지, 분실 기기와 지원하지 않는 브라우저까지 포함해야 실제 사용 가능한 인증으로 이어집니다.

구성	장점	확인할 조건
동기화형 패스키	여러 기기의 이용·복구 편의	동기화 계정 보호·복구 정책
기기 결합형 자격증명	특정 기기의 보호 경계 활용	분실·대체 기기 등록·회수
사용자 존재 확인	사용자의 접촉·행동 확인	사용자 신원 확인과 구분
사용자 확인	PIN·생체 등으로 사용자 확인	서비스가 요구하는 검증 수준

15장 적용 전 확인할 사항#

등록과 인증 챌린지를 서버에서 검증한다
패스키 추가·삭제와 계정 복구를 보호한다
동기화형·기기형 자격증명의 정책을 구분한다

16장 자주 묻는 질문#

패스키는 항상 생체인증을 요구하나요?#

PIN이나 기기 잠금 해제 등 다른 사용자 확인 수단도 사용할 수 있습니다. 서비스가 요구하는 확인 수준과 인증기 기능을 함께 살펴야 합니다.

생체정보를 서비스가 저장해야 패스키를 쓸 수 있나요?#

일반적인 패스키 인증에서 서버는 공개키와 자격증명 정보를 관리합니다. 기기의 생체 확인 결과는 서명 절차와 연결되며 생체 원본을 웹 서버로 보내는 구조가 아닙니다.

패스키를 쓰면 계정 복구를 없애도 되나요?#

사용자가 모든 기기를 잃거나 동기화 계정에 접근하지 못할 수 있습니다. 강한 인증을 우회하지 않으면서 복구할 수 있는 수단과 운영 절차가 필요합니다.