패스키는 비밀번호보다 피싱에 강하다고 합니다. origin·RP ID·challenge 검증은 어떤 역할을 하나요?

패스키 기반 인증은 공개키 자격을 relying party 범위에 묶고 서버 challenge에 서명하게 합니다. 비밀번호를 임의 사이트에 입력하는 방식과 달리 사이트 바인딩을 활용하지만 서버의 검증·복구 정책이 여전히 필요합니다.

동작 원리와 전제

서버는 challenge의 일회성·만료, expected origin·RP ID, 서명과 사용자 확인 요구를 검증합니다. client가 보낸 사용자 ID나 성공 플래그만 믿지 않습니다. RP ID와 origin은 관련되지만 동일한 문자열 규칙은 아니므로 검증된 라이브러리와 프로토콜 계약을 사용합니다.

선택과 실패 처리

동기화된 패스키와 기기 바인딩 자격은 백업·복구·기기 분실의 특성이 다릅니다. 계정 복구가 이메일만으로 쉽게 우회되면 강한 기본 인증의 효과가 줄 수 있습니다. 새 자격 등록·삭제에는 적절한 재인증·알림이 필요합니다.

구체적인 사례와 검증

공격 사이트가 받은 challenge 응답을 진짜 사이트에 재사용하려 해도 origin·RP 바인딩과 일회성 challenge 검증이 맞으면 거절되어야 합니다. 서버가 예상 origin을 request header의 임의 값에서 만들면 이 경계가 약해질 수 있어 신뢰된 설정을 사용합니다. 사용자 확인 UV 요구와 자격 등록·로그인 정책을 구분하고, 동일 계정에 새 패스키를 추가할 때 강한 기존 인증이 필요한지 정합니다. 기기 분실 시 복구가 가능해야 하지만 지원센터가 쉽게 새 자격을 등록해 주면 피싱 저항의 효과를 우회할 수 있습니다. 인증·등록·삭제·복구를 하나의 수명으로 평가하겠습니다.

다른 origin·재사용 challenge·취소·기기 분실·동기화 복구를 시험합니다. 패스키가 세션 탈취나 이미 인증된 악성 동작을 모두 막는 것은 아닙니다. 인증 후 자원 인가·세션 수명과 복구 경계를 함께 유지하겠습니다.