목차
비밀번호를 줄이고 계정 탈취 리스크를 낮추는 가장 현실적인 전환은 패스키다.
패스키는 “서버에는 공개키만 저장하고,
사용자는 기기(또는 플랫폼 계정)에 보관된 개인키로 로그인 서명만 수행”하는 인증이다.
FIDO2는 WebAuthn(브라우저·서버 표준) + CTAP(인증기-클라이언트 통신)으로 이 과정을 표준화한다.
그래서 서비스/OS/브라우저가 같은 방식으로 동작한다.
핵심은 ‘입력 감소’가 아니다.
입력 자체가 필요 없는 구조로 옮긴다는 점이다.
– 보안은 강화했는데 계정 탈취는 왜 계속 나올까
비밀번호는 재사용이 너무 쉽다.
유출되면 다른 서비스까지 연쇄로 깨진다.
OTP는 “추가 입력”을 붙인다.
하지만 사용자가 피싱 페이지에 그대로 입력하면 방어가 무너진다.
운영팀은 재설정/잠금 해제 요청으로 비용이 쌓인다.
사용자는 불편을 이유로 우회한다.
현장에서 흔한 장면은 아래처럼 정리된다.
- 비밀번호 변경을 반복하지만 재사용 습관이 바뀌지 않는다.
- 2단계 인증을 켰는데도 피싱 링크 한 번에 세션/토큰이 넘어간다.
- 보안 정책은 늘었는데 로그인 실패가 늘어 “예외 요청”이 폭증한다.
– 왜 패스키가 ‘피싱 저항’에 강한가
첫째, 패스키는 사이트(도메인)와 묶인 서명 흐름을 사용한다.
그래서 공격자가 가짜 로그인 페이지를 만들어도 정상 도메인에 대한 서명을 받아가기 어렵다.
둘째, 서버가 보관하는 건 공개키다.
비밀번호 DB처럼 “유출→재사용”으로 바로 이어지지 않는다.
셋째, 사용자는 입력 대신 기기 잠금 해제(생체/핀)로 승인을 한다.
이 승인은 복제 가능한 ‘문자열’이 아니다.
하지만 강점이 곧바로 “운영이 쉬움”을 뜻하진 않는다.
복구 흐름이 없으면 기기 분실/교체 시 계정 잠김이 발생한다.
그 순간 사람들은 다시 비밀번호로 되돌아가려 한다.
그래서 패스키 전환은 “기술 설정”이 아니다.
“등록·예외·복구까지 포함한 운영 구조 변경”이다.
전환 실패가 반복되는 증상 4가지
- 패스키를 추가했지만 비밀번호 로그인 경로가 동일하게 열려 공격면이 그대로 남는다.
- 기기 교체/분실 후 복구 경로가 없거나, 복구가 사람 의존(헬프데스크)이라 병목이 된다.
- 브라우저/OS/MDM 정책이 WebAuthn을 차단해 특정 부서·특정 단말에서만 실패한다.
- 공용 계정·공유 계정에서 “누가 소유자(등록자)인가”가 정의되지 않아 책임과 통제가 사라진다.
– 비밀번호·OTP·패스키를 무엇으로 구성할까
| 항목 | 비밀번호 | OTP(앱/문자) | 패스키(FIDO2) |
|---|---|---|---|
| 피싱 저항성 | 낮음 | 중간(입력 유도 가능) | 높음(도메인 결속 서명) |
| 사용자 마찰 | 중간 | 높음(추가 입력) | 낮음(기기 해제) |
| 운영 비용 | 중간 | 중간~높음(재설정/지원) | 초기 높음→안정 후 낮음 |
| 복구 난이도 | 중간 | 중간 | 설계에 따라 낮음/높음 |
| 유출 파급 | 큼(재사용) | 중간 | 낮음(공개키 저장) |
권장 구성은 이렇게 잡으면 된다.
- 개인: 핵심 계정은 패스키 우선 + 복구 경로 확정, 비밀번호는 보조로 낮춘다.
- 조직: 패스키 우선(권장) → 조건 충족 시 강제로 단계화하고, 예외 계정은 별도 통제한다.
– “1계정-2기기-2복구수단”으로 시작하기
개인은 전환 속도가 빠르다.
하지만 한 번의 실수로 “로그인 불가”가 발생하기 쉽다.
그래서 최소 안전 조건을 먼저 고정한다.
- 1계정: 가장 자주 쓰는 핵심 계정 1개부터 시작
- 2기기: 폰 + 노트북(또는 폰 2대)
- 2복구수단: 백업코드 + 복구 이메일(또는 복구 전화/보안키)
진행 순서(실패 방지용)
- 기존 비밀번호/OTP를 유지한 채 패스키를 먼저 등록한다.
- 두 번째 기기에도 패스키를 추가 등록한다(여기서 멈추면 안 된다).
- 백업코드를 저장하고, 복구 이메일/전화가 최신인지 확인한다.
- 기기 교체를 가정해 “복구→재등록”을 1회 완료한다.
– 파일럿→정책 고정→확대의 5단계
조직은 “호환성”보다 “정책 충돌”이 먼저 문제를 만든다.
운영 절차를 단계로 쪼개야 한다.
1. 현재 인증 구성 점검: SSO/IdP, OTP, 복구 절차, 계정 유형(개인/공용/서비스)을 분류한다.
2. 정책 고정: WebAuthn 허용, 브라우저/OS 버전, MDM 제한(생체/핀 정책)을 문서화해 ‘지원 기준’을 만든다.
3. 파일럿: IT/보안/헬프데스크부터 적용해 실패 케이스(차단/호환/예외)를 먼저 수집한다.
4. 확대: 부서 단위로 전개하고, 로그인 화면/가이드를 패스키 우선 UX로 통일한다.
5. 강제(조건부): 조건을 충족한 계정부터 비밀번호를 축소/차단한다.
- 정량 예시: 2기기 등록 완료 + 백업코드 저장 확인 + 최근 30일 로그인 성공 1회 계정부터 적용
– 복구·예외 설계: 계정 탈취보다 더 무서운 것은 ‘락’이다
복구가 약하면 공격자는 인증을 뚫기보다 복구 채널을 노린다.
패스키를 도입해도 복구가 SMS 단일이면 그 지점이 약점이 된다.
또한 공용/공유 계정은 패스키의 “개인 소유” 전제와 충돌한다.
그래서 공용 계정은 개인 계정 전환이 원칙이다.
불가하면 접근 통제/감사/승인 흐름으로 별도 설계해야 한다.
결론적으로 전환 성공 여부는 “패스키 등록 수”가 아니다.
복구 품질 + 예외 분리 + 운영 문서로 결정된다.
– 도입 전 30초 체크리스트
- 패스키를 등록할 두 번째 기기가 준비돼 있다.
- 백업코드/복구 이메일/관리자 복구 중 두 가지가 확보돼 있다.
- 조직은 WebAuthn이 차단되지 않도록 MDM·브라우저 정책을 점검했다.
- 공용/공유 계정은 개인 계정 전환 또는 별도 접근통제(승인·감사)를 정의했다.
- 헬프데스크용 “등록/추가등록/복구/기기교체” 1페이지 안내가 있다.
- 파일럿 실패 케이스를 분류할 티켓 항목(정책 차단/미등록/기기 없음)이 있다.
– 흔한 실수/주의
- “패스키를 켰으니 끝”이라고 보고 비밀번호 경로를 방치해 공격면을 유지한다.
- 단일 디바이스만 등록하고 복구 리허설을 생략해, 분실 시 대규모 락/지원 폭증이 난다.
- 예외 계정(레거시·공용·자동화)을 같은 정책으로 묶어 현장 업무를 멈춘다.
– 실전 팁: 운영이 쉬워지는 3가지
- 안내 문구는 “비밀번호 삭제”가 아니라 “패스키 우선 로그인”으로 정의한다(반발과 문의 감소).
- 실패 안내를 3분기만 해도 지원이 줄어든다: ‘등록 없음’ vs ‘기기 없음’ vs ‘정책 차단’.
- 조직은 롤백 기준을 문장으로 고정한다: “업무 차단 0건 + 복구 완주율 확보” 전에는 비밀번호 보조 경로를 단계적으로만 축소한다.
– 마무리
우선 ‘1개 계정’부터 패스키 등록→로그인→기기 추가→복구까지 테스트하라.
이 한 번의 완주가 전환 속도와 사고 비용을 동시에 줄인다.
- 패스키는 “입력값”을 없애 피싱/재사용 공격면을 구조적으로 줄인다.
- 전환 성공은 등록 기능이 아니라 2기기·2복구수단·복구 리허설에 달려 있다.
- 조직은 파일럿에서 정책 차단과 공용/공유 계정 예외를 먼저 고정해야 한다.
– FAQ
Q1. 패스키를 쓰면 비밀번호를 완전히 없애야 하나요?
A1. 전환 초기에는 “패스키 우선 + 비밀번호 보조”로 시작하고, 복구·예외 정책이 안정되면 계정/그룹 단위로 비밀번호를 축소/차단한다.
Q2. 기기를 잃어버리면 계정이 바로 잠기나요?
A2. “2기기 등록 + 2복구수단 + 복구 리허설”을 충족하면 잠김을 피하고 재등록으로 복구 흐름을 유지할 수 있다.
Q3. 조직에서 가장 먼저 막히는 지점은 어디인가요?
A3. WebAuthn이 MDM/브라우저 정책에 의해 차단되는 구간과 공용/공유 계정 처리 구간이다. 파일럿에서 두 항목을 먼저 고정한다.
Passkeys #FIDO2 #AccountSecurity