개인 키를 입력란에 보내지 않고 필요한 증명만 전달할 수 있다면 어떨까?
비밀번호 입력은 로그인 과정에 공유 비밀을 안다는 사실을 전달한다. 패스키에서는 서비스가 공개 키를 보관하고 인증기가 대응하는 개인 키로 질문에 응답한다. 개인 키 자체를 비밀번호처럼 제출하지 않는다. 여기서는 인증 시스템을 만들지 않고 이 역할 분담을 이해한다.
서비스에는 개인 키 사본이 아니라 증명이 필요하다.
이번 방문에 대한 질문
단순화하면 서비스가 새로운 챌린지를 보낸다. 필요한 사용자 상호작용과 확인 후 인증기가 서명된 응답을 만들고, 서비스는 공개 키와 주변 맥락으로 확인한다. 이전에 저장한 응답만으로 새 방문을 승인할 수 없도록 새로움이 중요하다.
이것은 구현법이 아니라 역할 설명이다. 실제 WebAuthn에는 구조화된 데이터, 의존 당사자 식별자, 브라우저 출처 검사와 정책 판단이 필요하다. 등록과 복구도 신중하게 설계해야 한다. 키나 자격 증명을 만들지 않았으며 암호 연산을 임의의 수학으로 대체하지 않았다.
사이트 결합이 바꾸는 것
비밀번호는 올바르게 보이기만 하는 양식에도 입력할 수 있다. 적절한 패스키 흐름은 브라우저와 인증기로 작업을 서비스에 결합한다. 같은 로고를 보여 준다고 가짜 사이트가 진짜 사이트용 응답을 받지는 않는다. 패스키의 피싱 저항성을 설명하는 핵심 구분이다.
피싱 저항성이 계정 주변의 모든 행동을 안전하게 만들지는 않는다. 거짓 페이지는 여전히 결제, 다운로드, 부적절한 권한을 요청할 수 있고 복구나 약한 대체 경로를 노릴 수도 있다. 자격 증명은 로그인의 특정 부분을 개선하며 다른 판단에는 별도의 근거와 보호가 필요하다.
세 사례로 두 조건을 보자
오프라인 모형의 조건은 기대한 사이트 일치와 현재 챌린지 여부뿐이다. 둘 다 맞으면 수락한다. 챌린지가 현재여도 사이트가 다르면 거부하고 사이트가 맞아도 오래된 응답이면 거부한다. 이 작은 결정표에 네 가지 검사를 적용했다.
결과는 작성한 규칙에서 나온 것이지 브라우저가 공격을 막은 실측이 아니다. 실험에는 서명, 인증기, 계정, 네트워크 연결이 없다. 표는 사이트 결합과 새로움을 나누어 보여 줄 뿐 완전한 검증기가 아니다. 운영 인증 코드로 사용해서는 안 된다.
기기 해제와 사이트 로그인
얼굴, 지문, 기기 PIN을 로컬에서 확인해 자격 증명 작업을 허용할 수 있다. 일반적인 WebAuthn에서 사이트는 생체 이미지 사본 대신 확인과 관련된 정보를 받는다. 모든 웹사이트에 지문을 보내는 것과 다르다. 구체적 동작은 기기와 인증기, 서비스 정책에 달렸다.
패스키의 사용 가능 위치도 다르다. 제공자의 자격 증명 시스템으로 동기화되는 것도 있고 특정 하드웨어에 묶인 것도 있다. 이는 편의와 복구에 영향을 준다. 기존 로그인 방식을 바꾸기 전에 기기 분실과 평소 기기를 쓸 수 없는 상황의 접근 방법을 알아보자.
도입에는 예비 경로도 포함된다
실제 서비스의 계정 설정에서 지원되는 등록 절차를 따른다. 새 방식을 이해할 때까지 기존 복구 경로를 유지한다. 여러 기기를 사용한다면 어느 기기가 실제로 자격 증명에 접근할 수 있는지 확인한다. 한 기기의 설정 성공이 모든 기기의 준비 완료를 뜻하지는 않는다.
옛 대체 방법도 살펴보자. 강한 일반 로그인과 약한 복구 경로가 공존할 수 있어 계정 설정 전체를 볼 필요가 있다. 목표는 보안 이름표를 하나 늘리는 것이 아니다. 정상 접근은 쉽게 하고 가짜 사이트에 재사용 가능한 비밀을 넘길 기회는 줄이는 것이다.
더 읽어 보기
W3C: Web Authentication ↗FIDO Alliance: Passkeys ↗MDN: Web Authentication API ↗공식 문서와 함께 읽으면 좋은 자료입니다.