로그인 방식은 바뀌어도 계정 운영은 남습니다
- 1 · 등록
Relying party용 자격 증명 생성
WebAuthn은 relying party 범위에 묶인 공개키 자격 증명을 만듭니다. 서비스는 공개키를 저장하고 인증 장치는 개인키를 보관하며 인증 과정에서 사용자 확인이나 존재를 사용합니다.[1][3]
- 2 · 검증
사이트 challenge에 서명
재사용 가능한 비밀번호를 보내는 대신 인증 장치가 예상한 relying party의 challenge에 서명합니다. NIST는 요구되는 verifier name binding을 구현한 WebAuthn/FIDO2를 피싱 저항 인증의 예로 제시합니다.[2][3]
- 3 · 복구
정상 경로 주변을 설계
패스키는 기기에 묶이거나 허용된 제공자를 통해 동기화될 수 있습니다. 더 약한 우회로가 강한 로그인을 무너뜨리지 않도록 등록, 교체, 복구와 대체 정책을 명시해야 합니다.[1][2]
사이트가 받는 공유 비밀이 없습니다
비밀번호는 사용자가 알고 서비스가 검증하는 재사용 값입니다. 패스키는 인증 장치가 보관하는 개인키와 서비스에 등록된 공개키를 사용합니다.[1][3]
애플리케이션은 새로운 challenge에 대한 서명 응답을 요청합니다. 침해와 피싱 판단은 달라지지만 세션, 기기와 계정 복구를 보호할 필요는 사라지지 않습니다.[1][3]
사용자 경험은 계정 상태 문제가 됩니다
기기가 적절한 자격 증명을 제안할 수 있어 로그인 화면은 단순해질 수 있습니다. 더 어려운 일은 생성 설명, 기기 구분, 추가 인증 장치 등록과 기기 변경·분실 처리로 이동합니다.[1][3]
고객이 실제 사용하는 브라우저와 기기 조합에서 전체 여정을 시험하세요. 성공적인 등록과 복구를 측정하기 전에는 기존 경로를 제거하지 않습니다.[1][3]
대체 경로가 실제 보증 수준을 결정합니다
약한 비밀번호 재설정이나 쉽게 속일 수 있는 지원 요청으로 패스키를 우회할 수 있다면 계정은 그 경로에 노출됩니다. 복구에도 별도 신원 확인, 속도 제한, 알림과 감사 기록이 필요합니다.[2]
일반 기기 교체와 의심스러운 계정 복구를 구분합니다. 직원과 관리자 계정에는 둘 이상의 인증 장치를 등록하고 사고 전에 지원팀의 확인 근거를 정하세요.[2]
사용자 집단과 기능별로 전환하세요
내부 또는 희망 사용자부터 시작해 등록과 복구 실패를 관찰한 뒤 범위를 넓힙니다. 어떤 계정에 패스키가 있고 어떤 대체 경로가 남았는지 명확히 표시합니다.[1][2][3]
호주 조직은 패스키를 버튼이 아니라 인증 프로그램으로 다뤄야 합니다. 클라이언트를 조사하고 relying-party 범위를 정하고 복구를 문서화하며 지원팀을 전환 과정에 포함하세요.[1][2][3]
- Relying-party와 도메인 범위 확인
- 시험한 복구 경로 하나 이상 지원
- 대체 경로도 같은 보증 목표로 보호
- 등록·로그인·복구를 분리해 모니터링
- 세션과 계정 변경 통제 유지