핵심 요약
- 패스키 로그인은 비밀번호를 보내지 않고, 인증기가 서버의 challenge를 개인키로 서명해 개인키 보유를 증명합니다.
- 등록에서는 인증기가 만든 키 쌍 중 공개키를 서버가 저장하고, 인증에서는 그 공개키로 서명을 검증합니다.
- MDN은 일부 또는 모든 지원 브라우저에서 WebAuthn이 HTTPS 보안 컨텍스트에서만 가능하다고 설명합니다. 실제 지원 범위는 서비스와 브라우저 안내를 확인해야 합니다.
패스키 로그인은 비밀번호라는 비밀을 서버에 보내는 대신, 공개키 암호로 사용자가 개인키를 가지고 있다는 사실을 증명합니다 (MDN). 서버가 보낸 큰 난수(challenge)를 인증기가 개인키로 서명해 돌려주고, 서버는 등록 때 저장해 둔 공개키로 그 서명을 검증합니다 (MDN). MDN은 이 방식이 네트워크로 어떤 비밀도 드러내지 않고 개인키 보유를 증명한다고 설명합니다 (MDN).
비밀번호 로그인과 무엇이 다른가: 서버에는 공개키가 남습니다
WebAuthn(Web Authentication API, 웹 인증 표준 API)은 웹사이트 등록, 인증, 다중 인증에 비밀번호나 SMS 대신 비대칭(공개키) 암호를 사용합니다 (MDN). 웹에서 패스키는 이 API로 구현됩니다 (MDN). 비대칭 키 쌍은 인증기에 저장되고 (MDN), 서버는 이후 인증에 쓰기 위해 공개키를 사용자 신원과 묶어 저장합니다 (MDN).
MDN은 공격자가 검증용 공개키를 손에 넣어도 개인키가 없으면 인증할 수 없다고 밝혔습니다 (MDN). 또 서명이 웹사이트의 출처(origin)에 따라 달라지므로 가짜 로그인 사이트를 만든 공격자는 사용자로 로그인할 수 없다고 설명합니다 (MDN). MDN의 PublicKeyCredential 문서도 이 키 쌍을 비밀번호 대신 서비스 로그인에 쓰는, 피싱이 불가능하고 데이터 유출에 강한 자격증명이라고 설명합니다 (MDN). 패스키를 도입하는 사이트는 보통 기존 비밀번호 인증과 함께 패스키를 추가할 것으로 MDN은 예상합니다 (MDN).
브라우저·서버·인증기는 각각 무엇을 하나요
로그인을 받는 서비스 쪽 서버를 WebAuthn에서는 신뢰 당사자(relying party, RP)라고 부릅니다 (MDN).
| 주체 | 문서에 적힌 역할 |
|---|---|
| 신뢰 당사자(RP) 서버 | challenge를 만들어 보내고, 공개키를 저장하며, 돌아온 응답을 검증합니다 (MDN) |
| 웹 앱 | 서버와 브라우저 사이에서 정보와 PublicKeyCredential을 전달합니다 (MDN) |
| 브라우저(사용자 에이전트) | create()와 get()으로 인증기에 자격증명 생성과 서명을 요청합니다 (MDN) |
| 인증기 | 사용자 동의를 받아 키 쌍을 만들고 저장하며, challenge에 서명합니다 (MDN) |
인증기는 브라우저나 운영체제(예: Windows Hello)에 내장될 수도 있고, USB·Bluetooth 보안 키 같은 물리 토큰일 수도 있습니다 (MDN).
등록: 키 쌍을 만들고 공개키를 서버에 맡깁니다
등록은 navigator.credentials.create()를 호출하는 단계로, 새 계정을 만들 때나 기존 계정에 새 키 쌍을 연결할 때 씁니다 (MDN).
- RP 서버가 사용자·RP 정보와 challenge를 웹 앱에 보냅니다 (MDN).
- 인증기는 사용자 동의를 받은 뒤 키 쌍을 생성하고, 공개키와 선택 사항인 서명된 attestation을 웹 앱에 반환합니다 (MDN).
- 웹 앱이 PublicKeyCredential을 RP 서버로 전달합니다 (MDN).
- 서버는 challenge가 보낸 것과 같은지, 출처가 기대한 출처인지 등을 검증한 뒤 공개키를 사용자 신원과 함께 저장합니다 (MDN).
인증: 서명된 challenge로 개인키 보유를 증명합니다
인증은 navigator.credentials.get()을 호출해 기존 자격증명으로 RP에 인증하는 단계이며, 주 로그인이나 MFA의 추가 요소로 쓸 수 있습니다 (MDN).
- RP가 challenge를 생성해 브라우저에 보냅니다 (MDN).
- 브라우저가 인증기에 challenge 서명을 요청합니다 (MDN).
- 인증기가 요청받은 자격증명을 가지고 있고 challenge 서명에 성공하면, 사용자 동의를 받아 서명된 assertion을 웹 앱에 반환합니다 (MDN).
- 서버는 저장한 공개키로 서명을 검증하고, challenge와 Relying Party ID가 기대한 값인지 확인하면 인증이 성공합니다 (MDN).
이 글의 해석으로는, 비밀번호 로그인에서 비밀 자체를 보내는 것과 달리 서버가 보낸 challenge에 대한 서명을 보낸다는 점이 핵심 차이입니다 (MDN).
적용 전 주의: HTTPS와 브라우저 지원
Web Authentication API는 일부 또는 모든 지원 브라우저에서 보안 컨텍스트(HTTPS)에서만 사용할 수 있습니다 (MDN). 이 기능의 일부는 브라우저마다 지원 수준이 다를 수 있습니다 (MDN).
한계
이 글은 MDN의 Web Authentication API 문서와 PublicKeyCredential 문서에 적힌 흐름을 정리한 것이며, 직접 구현해 재현한 절차가 아닙니다. 실제 브라우저·기기별 지원과 패스키를 잃었을 때의 계정 복구 방식은 원문에서 확인되지 않았으므로, 이용하는 서비스의 안내에서 확인해야 합니다.
자주 묻는 질문
패스키로 로그인하면 서버에 비밀번호 같은 비밀이 전송되나요?
MDN 설명에 따르면 그렇지 않습니다. 서버가 보낸 challenge를 인증기가 개인키로 서명해 돌려보내며, 이는 네트워크로 비밀을 드러내지 않고 개인키 보유를 증명합니다. 서버는 등록 때 받은 공개키를 사용자 신원과 함께 저장합니다.
패스키를 도입하면 비밀번호 로그인은 사라지나요?
MDN은 패스키를 도입하는 사이트가 보통 기존 비밀번호 인증과 함께 패스키를 추가할 것으로 예상합니다. 사용자는 한 사이트에 비밀번호, 하나 이상의 패스키, 또는 둘 다를 가질 수 있습니다.
HTTP 사이트에서도 WebAuthn을 쓸 수 있나요?
MDN은 Web Authentication API가 일부 또는 모든 지원 브라우저에서 보안 컨텍스트(HTTPS)에서만 사용할 수 있다고 적었습니다. 어떤 브라우저에 이 제약이 적용되는지는 문서에서 확인되지 않았습니다.
출처 정보
조사 출처
- 자료 조회
자료 조회 시각은 데이터 관측 시점이나 사실 검증 완료 시각을 뜻하지 않습니다. 수치의 기준 시점과 검토 범위는 본문과 원문에서 확인해 주세요.