Passkey — 비밀번호의 진짜 대체 (대부분)

Passkey (WebAuthn / FIDO2) 가 산업이 "비밀번호 더 이상 X" 에 가장 가까이 간 거야. Phishing-resistant, device-bound 또는 sync, 모든 모던 OS 와 브라우저에서 작동.

Passkey 가 실제로 뭔지

디바이스의 secure enclave (TouchID, Windows Hello, Android keystore) 또는 비밀번호 매니저 (1Password, iCloud Keychain, Google) 에 저장된 keypair. 서버는 public key 만 저장. 로그인 = 디바이스가 challenge sign 해서 private key 소유 증명 — phish 할 공유 시크릿 없음, leak 할 비밀번호 없음.

다중 디바이스, 다중 사용자한테 PIN 을 이기는 이유

속성	PIN (Track 5)	Passkey
Phishing 가능	응 (가짜 페이지에 타이핑)	아니 (브라우저가 origin-bound)
Brute-forceable	4자리는 1만 조합	암호학적 키, 불가능
Per-user identity	아니 (PIN 공유 모델)	응 (각 디바이스 = 자기 credential)
디바이스 간 sync	수동 (공유해야)	iCloud / Google / 1Password 통해 native
셋업 복잡도	5분	20–60분 (서버 사이드 WebAuthn)
복구	Track 6 의 복구 토큰	계정 복구 flow + backup passkey

정직한 trade-off

복구가 더 어려워. Passkey 가진 모든 디바이스 잃음 = 다시 들어가기 더 어려움. 항상 최소 두 개 등록: 예를 들어 노트북 + 폰, 또는 backup 으로 하드웨어 키.
서버 복잡도가 진짜. WebAuthn ceremony 가 edge case 있음 (user verification flag, AAGUID, attestation). 라이브러리 써; spec 에서 직접 짜지 마.
오래된 브라우저 / 회사 제한 여전히 있음. 지금은 fallback (PIN, 이메일 magic link) 가져.

Code

Passkey 등록 & 인증, 개념적으로·python

# 등록 (디바이스당 한 번)
options = generate_registration_options(
    rp_id="myapp.example.com",
    rp_name="My App",
    user_id=user.id,
    user_name=user.email,
)
# 브라우저로 options 보냄 → navigator.credentials.create(options)
# 브라우저가 credential 반환 → 검증하고 credential.public_key 저장

# 인증
options = generate_authentication_options(rp_id="myapp.example.com")
# 브라우저로 → navigator.credentials.get(options)
# 브라우저가 assertion 반환 → 저장된 public_key 와 검증
# 성공 → session 쿠키 발급 (Track 5 와 같은 모델)

Passkey — 비밀번호의 진짜 대체 (대부분)

Passkey 가 실제로 뭔지

다중 디바이스, 다중 사용자한테 PIN 을 이기는 이유

정직한 trade-off

Code

External links

Exercise

Progress

댓글 0