패스키
IT 위키
더 많은 작업
- Passkey; 패스키
- FIDO 표준에 따라 기기가 사이트마다 만드는 공개키 쌍으로, 비밀번호 대신 로그인하는 자격 증명
패스키는 비밀번호를 대신하는 로그인 수단이다. 사용자가 사이트에 패스키를 등록하면 기기(또는 비밀번호 관리자)가 그 사이트 전용 공개키 쌍을 만들고, 서버에는 공개키만 저장된다. 로그인할 때는 서버가 보낸 난수(챌린지)에 기기가 개인키로 서명하고, 서버는 공개키로 서명을 확인한다. 사용자는 지문, 얼굴, PIN, 패턴 같은 기기 화면 잠금을 풀기만 하면 된다. 비밀번호처럼 외우거나 입력하는 비밀이 없고, 서버가 털려도 유출될 비밀이 없으며, 키가 도메인에 묶여 있어 가짜 사이트에서는 쓸 수 없다.
기술적으로는 FIDO 얼라이언스와 W3C가 만든 FIDO2 표준(W3C WebAuthn과 FIDO CTAP)의 자격 증명이다. "패스키"는 기술 명칭이라기보다 이 자격 증명을 일반 사용자에게 설명하기 위한 이름이다. 2022년 5월 5일 애플, 구글, 마이크로소프트가 FIDO 자격 증명을 여러 기기에서 쓸 수 있게 하겠다고 공동 발표했고[1], 같은 해 6월 애플 WWDC에서 패스키라는 이름이 널리 알려졌다.
| 항목 | 내용 |
|---|---|
| 표준 | W3C Web Authentication(WebAuthn), FIDO CTAP 2.x |
| 서버에 저장되는 것 | 공개키, 자격 증명 ID, 서명 카운터 등. 비밀 정보 없음 |
| 사용자가 하는 일 | 기기 잠금 해제(생체 인식, PIN, 패턴, 비밀번호) |
| 생체 정보의 역할 | 기기 안에서 개인키 사용을 허락하는 잠금 해제용. 서버로 전송되지 않는다 |
| 범위 | 사이트(RP ID, 보통 등록 도메인)마다 다른 키. 다른 도메인에서는 쓸 수 없다 |
| 종류 | 동기화 패스키(클라우드로 여러 기기 공유), 기기 결합 패스키(한 기기나 보안 키에만 존재) |
| 선행 기술 | FIDO UAF(기기 결합, 앱 중심), FIDO U2F(보안 키를 2차 인증으로) |
패스키는 로그인 ID까지 대신할 수 있다. 사용자 식별자를 품은 "검색 가능한 자격 증명(discoverable credential)"이면 아이디를 입력하지 않고 기기가 보여 주는 계정 목록에서 고르기만 하면 된다. 반면 아이디를 먼저 입력하게 하거나, 비밀번호 로그인 뒤 2차 인증 수단으로만 패스키를 쓰는 사이트도 있다.
| 구성 요소 | 담당 | 역할 |
|---|---|---|
| WebAuthn | W3C | 웹 페이지(JavaScript)와 브라우저 사이의 API. navigator.credentials.create(), get(). Level 1(2019), Level 2(2021)를 거쳐 Level 3가 2026년 8월 W3C 권고안이 되었다[2]
|
| CTAP(Client to Authenticator Protocol) | FIDO 얼라이언스 | 브라우저·OS(클라이언트)와 인증기(보안 키, 휴대폰) 사이의 프로토콜. USB, NFC, BLE, 하이브리드 전송. CTAP1은 U2F와 같고, CTAP 2.2(2025년 7월 제안 표준)에 하이브리드 전송이 들어 있다[3] |
| 앱용 API | 각 OS | Android Credential Manager, Apple AuthenticationServices(ASAuthorization), Windows WebAuthn API
|
| 자격 증명 교환(CXP/CXF) | FIDO 얼라이언스 | 비밀번호 관리자 사이에 패스키를 옮기는 규격(아래 절) |
패스키는 공개키 암호화를 이용한 챌린지-응답 인증이다.
- 신뢰 당사자(RP, Relying Party): 로그인을 받는 웹 사이트나 앱. RP ID는 보통 도메인(
example.com)이며, 그 도메인이나 하위 도메인에서만 해당 패스키를 쓸 수 있다.[2] - 인증기(authenticator): 개인키를 보관하고 서명하는 주체. 기기 내장(플랫폼 인증기: 휴대폰의 보안 칩, PC의 TPM, 애플 Secure Enclave), 외장(로밍 인증기: USB·NFC 보안 키), 소프트웨어(비밀번호 관리자)가 있다.
- 사용자 확인: 인증기는 서명 전에 사람이 있는지(UP, user presence: 터치 등)와 본인인지(UV, user verification: 생체 인식이나 PIN)를 확인한다. 이 확인은 기기 안에서 끝나고, 서버는 결과 플래그만 받는다.
- 인증기 데이터 플래그: UP, UV 외에 백업 가능(BE, backup eligible)과 백업됨(BS, backup state) 플래그가 있어 서버가 동기화 패스키인지 알 수 있다.[2]
- 사용자가 로그인한 상태에서(또는 가입 중에) "패스키 만들기"를 누른다.
- 서버가 무작위 챌린지, RP ID, 사용자 ID, 허용 알고리즘을 보낸다.
- 브라우저가 현재 페이지의 출처(origin)가 RP ID와 맞는지 확인하고 인증기에 요청한다.
- 인증기가 사용자 확인(생체 인식 등) 뒤 새 키 쌍을 만들고, 공개키와 자격 증명 ID를 돌려준다. 필요하면 인증기 제조사를 증명하는 증명서(attestation)를 붙인다.
- 서버가 챌린지와 출처를 검사한 뒤 공개키를 계정에 저장한다.
// 등록 (값은 서버가 내려준 것을 쓴다)
const cred = await navigator.credentials.create({
publicKey: {
challenge: serverChallenge, // 서버가 만든 무작위 바이트
rp: { id: 'example.com', name: 'Example' },
user: { id: userIdBytes, name: '[email protected]', displayName: '김철수' },
pubKeyCredParams: [{ type: 'public-key', alg: -7 }, // ES256
{ type: 'public-key', alg: -257 }], // RS256
authenticatorSelection: { residentKey: 'required', userVerification: 'preferred' }
}
});
// cred.response 안의 attestationObject, clientDataJSON을 서버로 보내 검증
- 서버가 새 챌린지를 보낸다.
- 브라우저가 출처를 확인하고, 그 RP ID에 맞는 패스키가 있는 인증기에 서명을 요청한다.
- 사용자가 잠금을 해제하면 인증기가 챌린지, 출처가 담긴 클라이언트 데이터, 인증기 데이터에 개인키로 서명한다.
- 서버가 저장된 공개키로 서명을 확인하고, 챌린지·출처·RP ID·플래그를 검사한다.
// 로그인 폼 자동 완성 목록에 패스키를 함께 보여 주는 조건부 UI
// <input name="username" autocomplete="username webauthn">
const assertion = await navigator.credentials.get({
mediation: 'conditional',
publicKey: { challenge: serverChallenge, rpId: 'example.com', userVerification: 'preferred' }
});
- 브라우저가 출처를 검사하므로
examp1e.com같은 가짜 사이트에서는 진짜 사이트의 패스키가 목록에 뜨지조차 않는다. 사용자가 속아도 줄 수 있는 것이 없다. - 서명 대상 데이터에 실제 접속한 출처가 들어 있어, 공격자가 중간에서 요청을 중계해도 서버가 출처 불일치를 알아챈다. 사용자가 코드를 옮겨 적는 SMS 인증이나 OTP는 피싱 사이트가 실시간으로 중계하면 뚫린다.
- 사이트마다 키가 달라 한 사이트가 유출되어도 다른 사이트 계정에 쓸 수 없다(크리덴셜 스터핑 불가). 서버에는 공개키만 있으므로 DB가 유출되어도 사전 공격이나 무차별 대입 공격으로 알아낼 비밀이 없다.
- 매번 새 챌린지에 서명하므로 가로챈 응답을 다시 보내는 재전송 공격도 통하지 않는다.
기존 바이오 인증 방식 중에는 생체 정보(또는 그 특징값)를 서버에 등록하는 것도 있었는데, 생체 정보는 유출되면 바꿀 수 없다. 패스키에서 생체 정보는 기기 밖으로 나가지 않고 개인키 사용을 허락하는 데만 쓰이며, 키 자체는 생체 정보에서 만들어지지 않는다. 그래서 패스키는 언제든 지우고 새로 만들 수 있다.
| 동기화 패스키(synced passkey) | 기기 결합 패스키(device-bound passkey) | |
|---|---|---|
| 정의 | 클라우드 서비스를 통해 사용자의 여러 기기에 복제되는 패스키 | 한 기기(또는 보안 키) 밖으로 나가지 않는 패스키[4] |
| 예 | iCloud 키체인, Google 비밀번호 관리자, Samsung Pass, 1Password, Bitwarden, Dashlane | YubiKey 등 FIDO2 보안 키, Windows Hello(TPM), 일부 기업용 인증 앱 |
| 기기 분실 | 같은 계정의 다른 기기나 복구 절차로 계속 사용 | 그 기기의 패스키는 사라짐. 여분 키를 미리 등록해야 함 |
| 보안 기준 | 동기화 계정의 보안에 의존. 동기화는 보통 종단간 암호화 | 키 추출 불가. 높은 보증 수준(규제 산업, 관리자 계정)에 적합 |
| 증명(attestation) | 대부분 제공하지 않음 | 제조사·모델 증명 가능. 기업은 허용할 인증기 모델을 제한할 수 있다 |
| 플래그 | BE=1 | BE=0 |
- 검색 가능한 자격 증명(discoverable credential, 예전 이름 resident key)은 사용자 정보를 인증기에 저장해 아이디 없이 로그인할 수 있게 한다. 일반적으로 패스키라고 하면 이것을 가리킨다. 검색 불가능한 자격 증명은 서버가 자격 증명 ID 목록을 먼저 알려 줘야 한다. OpenSSH도 FIDO 보안 키 안에 SSH 키를 두는 형식(
ed25519-sk등)을 지원한다. - 미국 NIST는 2024년 4월 SP 800-63B 보충 문서에서 적절히 구성된 동기화 패스키가 인증 보증 수준 AAL2를 충족할 수 있다고 인정했다. 키 복제를 금지하던 이전 요구 사항을 동기화에 한해 완화한 것이다. 가장 높은 AAL3에는 키를 내보낼 수 없는 기기 결합형 인증기가 필요하다.[5] 이 보충 문서는 2025년 개정판 SP 800-63-4에 흡수되었다.
패스키가 없는 기기(예: 새 PC, 남의 PC)에서 휴대폰의 패스키로 로그인하는 방법이다. FIDO에서는 하이브리드 전송(hybrid transport)이라고 부르며, 구글이 caBLE(cloud-assisted BLE)이라는 이름으로 개발한 방식이 CTAP 2.2에 표준으로 들어갔다.[3]
- 로그인하려는 PC의 브라우저가 "다른 기기 사용"을 고르면 QR 코드를 띄운다. QR 코드에는 암호화 채널을 만들 키 정보가 들어 있다.
- 휴대폰 카메라로 QR 코드를 찍는다.
- 휴대폰이 블루투스 저전력(BLE) 광고를 보내고 PC가 이를 받아, 두 기기가 실제로 가까이 있음을 확인한다. 이 근접 확인 때문에 멀리 있는 공격자가 QR 코드를 피해자에게 보내 중계하는 공격이 어렵다.
- 실제 데이터는 인터넷의 중계(터널) 서버를 거쳐 종단간 암호화된 채널로 오간다.
- 휴대폰에서 잠금을 해제하면 서명이 PC로 전달되어 로그인된다. 한 번 연결한 기기는 다음부터 QR 없이 알림으로 연결할 수 있고, 사이트에 따라 PC에 새 패스키를 만들라고 권한다.
따라서 PC와 휴대폰 모두 블루투스가 켜져 있어야 하고 인터넷에 연결되어 있어야 한다. 운영체제나 브라우저가 달라도(아이폰의 패스키로 Windows의 Chrome에 로그인) 동작한다.
| 비밀번호 | SMS 인증번호 | TOTP 앱 | 푸시 승인 | 패스키 | |
|---|---|---|---|---|---|
| 피싱 사이트에서 중계 | 뚫림 | 뚫림 | 뚫림 | 뚫림(피로 공격 포함) | 막힘(출처 결합) |
| 서버 DB 유출 | 해시 크래킹 위험 | 해당 없음 | 공유 비밀 유출 위험 | 해당 없음 | 공개키만 유출 |
| 여러 사이트 재사용 | 흔함 | 해당 없음 | 해당 없음 | 해당 없음 | 불가(사이트별 키) |
| 사용자 입력 | 외워서 입력 | 코드 입력 | 코드 입력 | 탭 | 잠금 해제 |
| 단독 사용 시 인증 요소 | 지식 1개 | 소유 1개 | 소유 1개 | 소유 1개 | 소유(기기) + 지식 또는 생체(잠금 해제). 다중 요소를 한 번에 충족 |
이중 인증을 이미 쓰는 사이트에서도 패스키 하나로 비밀번호와 2차 인증을 모두 대신하는 경우가 많다.
| 플랫폼 | 패스키 저장소 | 지원 시작과 조건 |
|---|---|---|
| 애플 | iCloud 키체인(종단간 암호화 동기화), iOS 17부터 암호 공유 그룹, iOS 18부터 암호 앱 | iOS 16, iPadOS 16, macOS 13 Ventura(2022년). Safari 16 이상[6][7] |
| 구글 | Google 비밀번호 관리자(동기화) | Android 9 이상. Android 14부터 다른 비밀번호 관리자를 패스키 제공자로 지정 가능. Chrome은 Windows, macOS, Linux, ChromeOS에서 지원하며 macOS에서는 iCloud 키체인도 쓸 수 있다[8][9] |
| 마이크로소프트 | Windows Hello(기기 결합, TPM 보호) | 지원되는 모든 Windows에서 Windows Hello로 패스키를 만들고 쓸 수 있고, 휴대폰으로 크로스 기기 로그인도 된다. Windows 11 22H2의 2023년 9월 업데이트(KB5030310)부터 설정 앱에서 패스키를 관리하는 기능이 들어갔고, 24H2부터는 앱이 패스키에 접근할 때 개인 정보 동의를 묻는다. Edge, Chrome, Firefox에서 사용[10] |
| 삼성 | Samsung Pass | One UI 6 이상 갤럭시 기기[11] |
| 서드파티 비밀번호 관리자 | 1Password, Bitwarden, Dashlane, NordPass, Proton Pass, KeePassXC 등 | 브라우저 확장 또는 OS 자동 완성 제공자로 동작. Android는 14 이상, iOS는 17 이상에서 OS 수준 통합 |
| 하드웨어 보안 키 | YubiKey, Google Titan 등 FIDO2 키 | 키 안에 저장(기기 결합). 저장 개수에 한도가 있다 |
Android 일부 제조사 기기는 Android 14에서도 서드파티 제공자를 지원하지 않는 경우가 있고, 사이트에 따라 Google 비밀번호 관리자 외의 제공자와 잘 맞지 않는 경우도 있다.[9]
초기에는 패스키를 다른 비밀번호 관리자로 옮길 표준 방법이 없어, 관리자를 바꾸려면 사이트마다 패스키를 새로 만들어야 했다. FIDO 얼라이언스는 2024년 10월 두 규격의 작업 초안을 공개했다.[12][13]
- CXP(Credential Exchange Protocol): 두 자격 증명 제공자 사이에 암호화된 채널을 만들어(디피-헬만 키 교환) 자격 증명을 안전하게 옮기는 절차
- CXF(Credential Exchange Format): 옮기는 데이터의 형식. 패스키뿐 아니라 비밀번호, TOTP 시드, 카드 정보 등도 담는다
평문 CSV로 내보내는 기존 방식의 위험을 없애는 것이 목적이다. 1Password, 애플, Bitwarden, Dashlane, 구글, 마이크로소프트, 삼성, SK텔레콤 등이 참여했다. 애플은 iOS 26, macOS 26 등(2025년)에서 이 방식의 앱 간 가져오기·내보내기 API를 제공하기 시작했다.[14]
- 구글: 2023년 10월 10일부터 개인 구글 계정의 기본 로그인 방식으로 패스키를 제시했다. 비밀번호도 계속 쓸 수 있다.[15]
- 마이크로소프트: 2025년 5월 1일 첫 "세계 패스키의 날"에 맞춰 새로 만드는 마이크로소프트 계정을 비밀번호 없는 계정으로 기본 설정한다고 발표했다.[16]
- 카카오: 2024년 11월 25일 카카오계정에 패스키 로그인을 도입했다. 앱이 아닌 웹 기반으로 구현해 카카오 로그인을 쓰는 외부 서비스에서도 패스키 로그인을 할 수 있게 했다. 카카오계정 웹의 계정 보안 메뉴에서 등록한다.[17]
- 네이버: 2025년 1월 PC와 모바일 웹에 패스키 로그인을 먼저 적용하고 네이버 앱은 이후 적용한다고 밝혔다.[18]
- 삼성전자는 Samsung Pass로 패스키 제공자 역할을 하고, SK텔레콤도 PASS 앱을 통한 패스키 사업을 하는 것으로 알려져 있다. 두 회사 모두 FIDO 자격 증명 교환 규격 작업에 참여했다.
- FIDO 얼라이언스가 인용한 2024년 조사에서 응답자의 53%가 한 개 이상의 계정에 패스키를 켰다고 답했다.[4]
- 그 밖에 아마존, 애플, GitHub, PayPal, eBay, 닌텐도, PlayStation Network, TikTok, X, LinkedIn 등 대형 서비스가 지원한다. 지원 사이트와 방식(아이디 없이 로그인, 아이디 입력 뒤 패스키, 2차 인증 전용)은 자주 바뀌므로 passkeys.directory 같은 목록을 참고한다.
- 계정 복구: 모든 기기와 동기화 계정을 잃으면 패스키도 잃는다. 사이트가 복구 수단으로 SMS나 이메일, 비밀번호를 남겨 두면 공격자는 그쪽을 노리므로 전체 보안 수준이 가장 약한 복구 수단으로 내려간다. 여분의 기기나 보안 키를 함께 등록해 두는 것이 좋다.
- 동기화 계정이 곧 마스터 키: 동기화 패스키의 안전은 애플 계정, 구글 계정, 비밀번호 관리자 계정의 보안에 달려 있다. 이 계정에는 강한 2차 인증을 건다.
- 기기 잠금의 강도: 패스키는 기기 잠금 해제로 쓰이므로, 추측하기 쉬운 패턴이나 짧은 PIN을 쓰면 기기를 손에 넣은 사람이 패스키를 쓸 수 있다. 기기가 악성 코드에 장악되면 그 기기의 패스키도 위험하다.
- 플랫폼 종속: 동기화는 보통 같은 생태계 안에서만 된다. 크로스 기기 인증(QR)과 서드파티 관리자, CXP로 완화되고 있지만 아직 모든 조합이 매끄럽지는 않다.
- 공유 계정: 가족이나 팀이 한 계정을 함께 쓸 때는 동기화 계정을 공유하지 말고 관리자의 공유 기능(애플 암호 공유 그룹, 1Password 공유 보관함 등)을 쓴다.
- 기업 환경: 동기화 패스키는 증명을 제공하지 않는 경우가 많아 허용 인증기를 통제하기 어렵고, 개인 클라우드 계정으로 회사 자격 증명이 복제될 수 있다. 이런 곳은 기기 결합 패스키나 관리형 보안 키를 쓴다.
- 사용성: 사이트마다 등록 위치와 문구가 달라 사용자가 패스키가 어디에 저장되었는지 헷갈리기 쉽다. 대부분의 서비스가 비밀번호를 병행해 남겨 두므로 피싱 저항의 이점이 줄어드는 측면도 있다.
- 크로스 기기 인증에는 블루투스와 인터넷 연결이 모두 필요해 일부 PC나 블루투스를 막는 보안 정책에서는 쓰기 어렵다. 마이크로소프트는 이런 조직에 FIDO용 블루투스 서비스만 허용하는 정책 설정을 안내한다.[10]
- ↑ FIDO Alliance, Apple, Google and Microsoft Commit to Expanded Support for FIDO Standard to Accelerate Availability of Passwordless Sign-Ins (2022-05-05)
- ↑ 2.0 2.1 2.2 W3C, Web Authentication: An API for accessing Public Key Credentials Level 3
- ↑ 3.0 3.1 FIDO Alliance, Client to Authenticator Protocol (CTAP) v2.2, Proposed Standard (2025-07-14)
- ↑ 4.0 4.1 FIDO Alliance, Passkeys
- ↑ NIST, Giving NIST SP 800-63B a Boost: Supplement Incorporating Syncable Authenticators (2024-04)
- ↑ Apple Developer, Meet passkeys (WWDC22)
- ↑ Apple Support, About the security of passkeys
- ↑ Android Developers Blog, Bringing passkeys to Android & Chrome (2022-10)
- ↑ 9.0 9.1 Google for Developers, Passkey support on Android and Chrome
- ↑ 10.0 10.1 Microsoft Learn, Support for passkeys in Windows
- ↑ Samsung, How to create and use a passkey in Samsung Pass
- ↑ FIDO Alliance, Credential Exchange Protocol, Working Draft (2024-10-03)
- ↑ FIDO Alliance, Credential Exchange Specifications
- ↑ Apple Developer, What's new in passkeys (WWDC25)
- ↑ CNBC, Google passkeys now default login option for Google accounts (2023-10-10)
- ↑ Microsoft Security Blog, Pushing passkeys forward (2025-05-01)
- ↑ 카카오, 카카오계정에 '패스키' 로그인 도입 (2024-11-25)
- ↑ 세계일보, 네이버, 얼굴·지문으로 로그인 '패스키' 도입 (2025-01-30)