WebAuthn 옵션 생성과 응답 검증을 credential·challenge 저장소에서 분리합니다.
패스키는 피싱에 강한 인증 방식입니다. 장치에 보관된 개인키로 challenge에 서명하고, 서버는 등록해 둔 공개키로 그 서명을 검증합니다. 개인키는 서버로 전달되지 않고, credential은 서비스 식별자와 origin에 암호학적으로 묶입니다.
서버에는 공개키만 저장하고, 개인키는 사용자의 인증 장치 밖으로 나가지 않습니다.
서명은 정해진 서비스 식별자와 origin에서만 유효하므로, 비슷한 도메인으로 유도하는 피싱이 통하지 않습니다.
일회용 challenge와 서명 횟수를 검증해 응답 재생을 막고 복제된 인증기의 흔적을 잡아냅니다.
아래 증명은 글로 된 설명이 아닙니다. 버튼을 누르면 이 서버가 지금 직접 계산합니다.
인증기에 건네는 challenge는 서버가 발급한 일회용 값이고, 검증은 저장소에서 같은 값을 소비하면서 이뤄집니다. 서명 검증(표준 engine)은 이 결속이 있어야 의미가 있습니다.
표준 문서에 실린 테스트 벡터를 그대로 넣어 같은 값이 나오는지 확인합니다.
서명이 유효해도 결속이 깨지면 거부합니다. 이미 쓴 challenge, 다른 사이트의 rpId, 소유자가 다른 자격증명, 되감긴 counter는 모두 인증 실패입니다. RP 구성도 HTTPS가 아니면 아예 만들어지지 않습니다.
막아야 할 입력을 실제로 넣고 거부되는지 확인합니다.
규격 원문을 먼저 실었습니다. 사례는 이 분야에서 실제로 보안이 뚫린 일을 다룬 자료입니다.
attestation·assertion 검증 절차의 원문입니다.
인증기가 자기 출처를 증명하는 방식과, 대부분의 서비스가 이를 검증하지 않아도 되는 이유를 설명합니다.
authenticator·RP·discoverable credential 같은 규격 용어를 먼저 정리할 때 좋습니다.
attestation object를 인코딩하는 CBOR 형식과 그 규칙을 정의합니다.
다음 단계
브라우저 클라이언트와 credential repository adapter를 연결해 실제 authenticator 조합에서 검증합니다.