패스키는 개인 키의 서명으로 인증하고 로그인 서비스는 공개 키를 보관한다. 동기화 패스키는 암호화된 인증 정보를 기기 사이에 동기화할 수 있으며 기기 고정형은 동기화하지 않는다. MFA 여부는 요구되는 사용자 확인에 달려 있고 기기·동기화 계정·복구 절차의 보호도 중요하다.
개인 키를 로그인 서비스에 보내지 않는다
FIDO2/WebAuthn은 키 쌍을 사용한다. 서비스는 공개 키를 받아 서명을 검증하며 개인 키를 받지 않는다. 동기화 패스키는 공급자를 통해 암호화된 인증 정보를 동기화할 수 있고, 기기 고정형은 인증 장치에 남는다. 동기화 계정과 복구 절차도 보호한다.
비밀번호
사용자와 서버가 하나의 비밀을 공유. 서버가 유출되거나 가짜 사이트에 입력하면 탈취됨
패스키
공개 키만 유출되어서는 로그인에 필요한 개인 키 서명을 만들 수 없다.
'서버에는 공개 키만 있다'는 점이 핵심입니다. 공개 키는 원래 공개해도 되는 것이므로, 데이터베이스가 유출되어도 그것만으로는 로그인에 쓸 수 없습니다(비밀번호 저장과는 정반대의 전제 → 해싱이란).
비밀번호 + SMS와의 차이
비밀번호 + SMS 코드
- 공유된 비밀(비밀번호)이 유출될 수 있고, 재사용을 통해 연쇄됨
- 가짜 사이트에 입력하면 코드까지 중계됨
- '내가 가짜를 알아챌 수 있다'는 가정에 의존하기 쉬움
패스키
- 공개 키만 유출되어서는 로그인에 필요한 개인 키 서명을 만들 수 없다.
- 서명이 도메인에 묶임 = 가짜 사이트에서는 완료되지 않음
- 사용자가 알아채지 못해도 설계상 가짜 사이트를 차단
중간자 피싱(AiTM)은 사용자가 아무리 신중하게 입력해도 올바른 코드를 다른 정보와 함께 통째로 중계합니다(→ 피싱이란). 패스키의 서명은 도메인에 묶여 있으므로, 그 경로가 원리적으로 막힙니다.
패스키, 2단계 인증, 하드웨어 보안 키의 차이
패스키는 '2단계 인증의 일종'이라고도, '비밀번호를 대체하는 것'이라고도 설명되어 용어가 헷갈리기 쉽습니다. 역할별로 나란히 놓으면 다음과 같습니다.
| 패스키 | 비밀번호 + 일회용 비밀번호 | 하드웨어 보안 키 | |
|---|---|---|---|
| 로그인에 쓰는 것 | 도메인에 묶인 서명, 사용자 확인을 요구하면 PIN·생체 인증 | 기억한 문자열 + 코드(대개 6자리) | USB·NFC 키 안의 개인 키 + PIN 또는 터치 |
| 서버가 저장하는 것 | 공개 키 | 비밀번호 해시(인증 앱 방식이면 코드 생성용 비밀도) | 공개 키 |
| 가짜 사이트에서 쓰면 | 서명이 완료되지 않음 | 비밀번호와 코드 모두 중계될 수 있음 | 서명이 완료되지 않음 |
| 기기를 잃어버리면 | 동기화 패스키는 다른 기기에서 사용 가능 | 인증 앱 이전이나 복구 코드가 필요 | 예비 키나 지원되는 다른 복구 수단이 필요할 수 있음 |
| 적합한 용도 | 거의 모든 개인 용도 | 패스키를 지원하지 않는 서비스 | 관리자 계정, 위험이 높은 사람 |
FIDO2 대응 물리 보안 키에는 클라우드 동기화가 없는 기기 고정형 패스키를 저장할 수 있다. 예비 키나 지원되는 다른 복구 수단을 준비하면 잠금 위험을 줄일 수 있다. 2단계 인증(2FA)이란 / 일회용 비밀번호(OTP)란.
동기화 패스키와 기기 종속 패스키
패스키는 저장 위치에 따라 두 종류로 나뉩니다.
- 동기화 패스키: iCloud 키체인, Google 비밀번호 관리자, 비밀번호 관리자 앱에 저장되며, 같은 계정으로 로그인한 다른 기기에서도 쓸 수 있습니다. 기기 하나를 잃어버려도 로그인하지 못하게 될 가능성이 낮습니다
- 기기 종속 패스키: 하드웨어 보안 키처럼 만든 기기 안에만 보관됩니다. 동기화되지 않으므로 보관 위치를 정확히 관리할 수 있습니다
NIST SP 800-63B-4(2025년 7월)는 사용자 확인과 동기화 기반의 보호 등 관련 요건을 충족할 때 AAL2에서 동기화 가능한 인증 장치를 허용한다. AAL3에는 내보낼 수 없는 키 외에도 추가 요건이 있으므로 동기화하지 않는 키만으로 적합성이 보장되지는 않는다. 필요한 보증 수준, 기기·동기화 계정의 보호, 복구 조건을 함께 판단한다.
패스키를 추가한 뒤에도 남는 약점
패스키 자체가 가짜 사이트에 강해도, 계정은 가장 약한 입구만큼만 강합니다.
- 비밀번호 로그인이 여전히 켜져 있음: 많은 서비스에서 패스키를 추가해도 비밀번호와 SMS 코드 로그인이 남습니다. 가짜 사이트는 패스키 대신 그 남은 방식을 요구합니다
- 약한 복구 수단: 계정 복구에 SMS나 등록된 이메일만 필요하다면 그것이 입구가 됩니다. 복구용 이메일 계정 자체도 패스키로 보호하세요
- 약한 기기 잠금: 패스키는 기기 잠금을 해제하면 쓸 수 있게 되므로, 추측하기 쉬운 화면 잠금 PIN은 피하세요
실제 사례: 증권 계좌 탈취와 패스키 의무화
2025년 일본에서는 증권사를 사칭한 가짜 사이트에서 빼앗긴 로그인 ID와 비밀번호로 다른 사람의 증권 계좌에서 무단 거래가 이루어진 사례가 많이 발생했습니다. 일본 금융청은 주의 환기 페이지에서 패스키 같은 피싱에 강한 다요소 인증의 필수화가 진행되고 있다고 밝히고, 이용자에게 빨리 설정하라고 권고합니다.
일본증권업협회는 2025년 10월 15일 시행으로 온라인 거래의 무단 접근 방지에 관한 가이드라인을 개정했습니다. 로그인, 출금, 출금 계좌 변경 같은 중요한 조작에 피싱에 강한 다요소 인증(예: 패스키 방식이나 PKI 방식)을 구현하고 기본적으로 필수로 할 것을 요구합니다. 필요한 기기가 없는 고객에게는 대체 다요소 인증을 제공하도록 했습니다.
이 사례의 교훈은 두 가지입니다.
- 업계가 '이용자의 주의'에서 '설계'로 옮겨 갔습니다: 가짜 사이트를 알아보라고 호소해도 피해가 멈추지 않자, 가짜 사이트에서는 완료되지 않는 인증이 기본이 되었습니다
- 예로 든 것은 사람이 코드를 읽고 입력하는 방식이 아니라 패스키와 PKI입니다: NIST도 수동으로 입력하는 일회용 비밀번호는 피싱 저항성을 가질 수 없다고 말합니다
증권 계좌 이용자로서의 구체적인 대응(패스키 로그인, 거래 알림)은 다이와증권 위탁업체의 무단 접근 기사를 참고하세요.
자신의 계정과 서비스 점검 방법
중요한 계정이 패스키를 지원하는지 확인한다
이메일, 비밀번호 관리자, 클라우드, 증권·은행, GitHub 계정의 보안 설정에서 '패스키' 항목을 찾습니다. 비밀번호 관리자의 목록에서도 이미 패스키가 저장된 서비스를 확인할 수 있습니다.
두 번째 기기나 예비 키를 등록한다
동기화 패스키라면 같은 계정으로 로그인한 다른 기기에서 작동하는지 확인합니다. 동기화되지 않는 하드웨어 키를 쓴다면 예비 키를 등록하고 다른 장소에 보관합니다.
비밀번호와 SMS라는 옆문을 닫는다
패스키를 추가한 뒤에도 비밀번호만, 또는 SMS 코드만으로 로그인이나 복구가 되는지 확인합니다. 비밀번호를 건너뛰거나 SMS를 제거하는 설정이 있다면 사용합니다. 복구 코드는 비밀번호 관리자처럼 별도의 장소에 보관합니다.
서비스를 만드는 쪽이라면 도메인 검증과 복구를 확인한다
패스키(WebAuthn)를 구현할 때는 서명이 자사 도메인(RP ID)과 오리진에 한정되어 있는지 서버에서 검증합니다. 서명 검증은 직접 작성하지 말고 검증된 라이브러리를 쓰세요. 그리고 SMS만으로 되는 복구 경로가 남아 있으면, 패스키를 도입한 뒤에도 그곳이 약점이 됩니다.
이 사이트의 관점: 한 번에 모두 바꿀 필요는 없다
패스키는 강력하지만, 오늘 당장 모든 계정을 비밀번호 없이 만들 필요는 없습니다. 이 사이트의 입장은 중요한 계정부터 먼저 전환하는 것입니다. 다른 계정을 복구하거나 관리하는 데 쓰는 계정(이메일, 클라우드, 비밀번호 관리자)에 패스키를 추가하고 복구 수단을 마련하세요(여러 기기에 등록, 백업 유지). 비밀번호가 남는 서비스는 비밀번호 관리자와 피싱에 강한 MFA로 보호하다가, 각 서비스가 지원을 추가하는 대로 패스키로 옮기세요.
출처(1차 자료)
- FIDO Alliance, "Passkeys" — fidoalliance.org(정의, 동기화·기기 종속 패스키, 피싱 저항성)
- W3C, "Web Authentication: An API for accessing Public Key Credentials Level 3" — w3.org(RP ID와 오리진에 한정된 자격 증명)
- NIST SP 800-63B-4, "Digital Identity Guidelines: Authentication and Authenticator Management"(2025년 7월) — pages.nist.gov(동기화 패스키는 AAL2에서 허용되고 AAL3에서는 불가, 피싱 저항성의 조건, 기기 내 생체 대조)
- 일본증권업협회, 온라인 거래 무단 접근 방지 가이드라인 개정(2025년 10월 15일, 일본어) — jsda.or.jp (PDF)
- 일본 금융청, 인터넷 증권 서비스의 무단 접근·무단 거래에 대한 주의 환기(일본어) — fsa.go.jp
- passkeys.dev(패스키를 구현하는 개발자용 안내) — passkeys.dev
다음으로 읽기
- 학습: 비밀번호 관리자 고르는 법(패스키 저장·동기화도 처리합니다)
- 2단계 인증: 올바르게 MFA 고르기(피싱 저항성이란 무엇인가) / GitHub 2단계 인증 설정(백업으로 패스키 추가)
- 동작 원리: 비밀번호를 안전하게 저장하는 법 / 용어집: 피싱이란
- 용어집: 2단계 인증(2FA)이란 / 일회용 비밀번호(OTP)란(패스키와 비교되는 방식)