MFA, 생체인증, 패스키: 보장 범위 구분하기

핵심 요약

두 단계가 반드시 두 요소는 아닙니다. 비밀번호와 PIN은 모두 지식 요소입니다. 생체인증은 인증기를 활성화할 수 있지만 그 자체로 익명성이나 피싱 저항성을 보장하지는 않습니다.

보안 키 두 개, 빈 카드와 버건디 서류철이 있는 가상의 무인 신원 확인실
이 글의 목차

두 단계가 반드시 두 요소는 아닙니다. 비밀번호와 PIN은 모두 지식 요소입니다. 생체인증은 인증기를 활성화할 수 있지만 그 자체로 익명성이나 피싱 저항성을 보장하지는 않습니다.

화면 수보다 메커니즘을 비교한다

NIST는 지식, 소유, 생체 특성을 구분합니다. 수동 입력 일회용 코드는 가짜 사이트를 통해 중계될 수 있으므로 SMS와 TOTP는 피싱 저항 인증과 같지 않습니다. 올바르게 구현한 패스키는 응답을 해당 서비스에 연결합니다. 보장 범위는 로컬 검증과 백업·동기화 조건에도 달려 있습니다.

생체인증의 역할을 이해한다

WebAuthn에서는 인증기 안에서 생체인식을 수행할 수 있으며 생체 데이터는 수신 웹 서비스로 전송되지 않습니다. 로컬 검증에 PIN을 사용할 수도 있습니다. 사용자 존재 확인(UP)과 사용자 검증(UV)은 다릅니다. 서버가 프로토콜대로 응답을 검증해야 하며 얼굴 인식 화면만으로는 충분하지 않습니다.

전체 수명주기를 보호한다

등록, 인증 수단 추가, 기기 분실, 취소, 계정 복구를 계획합니다. 접근성과 대체 수단도 평가해야 하며 대체 경로가 주 경로를 약화시킬 수 있습니다. 인증은 데이터와 작업에 대한 업무 권한을 대신하지 않습니다.

출처

편집 검토: 2026년 11월 1일.

두 번째 인증 요소를 피싱 방지 기능과 분리하십시오.

NIST는 수동으로 입력한 일회용 코드가 사칭 페이지를 통해 전달될 수 있으므로, 일회용 코드만으로는 로그인 피싱 방지 기능을 확보할 수 없다고 지적합니다. 적절하게 통합된 WebAuthn은 응답을 실제 서비스에 연결합니다. 계정 복구는 여전히 안전한 접근 경로입니다.

  • SMS, 코드 또는 우회 가능한 승인을 여전히 허용하는 애플리케이션 목록을 작성하고, 권한이 있는 계정을 우선적으로 처리하십시오.
  • 실제 사용자 경험을 통해 등록, 기기 분실 및 계정 취소를 테스트하십시오.
  • 저항 요소 적용 범위를 측정하고 소유자에게 날짜별 예외 사항을 제공합니다.

1차 자료: NIST SP 800-63B-4. 관련 방법: 실무 가이드 읽기.

패스키: 도메인과 RP ID 변경 준비

계정, 웹 출처와 RP ID를 구분해 인증 정보를 조용히 다시 연결하지 않는 전환을 준비합니다.

  • 이전과 새 출처, RP ID와 연결 계정을 기록합니다. 같은 계정 이름이라고 패스키가 다른 RP ID에 유효해지지는 않습니다. WebAuthn의 허용 조합과 전환 중 가능한 접근 경로를 확인합니다.
  • 허가된 시험 환경에서 적절한 라이브러리로 챌린지, 출처, RP ID와 계정 연결을 확인합니다. 예상 밖 출처와 재사용 챌린지를 시험합니다. RP ID가 바뀌면 인증된 새 등록을 준비합니다. 행 복사를 키 이전으로 취급하지 않습니다.
  • 이전 인증 정보만 가진 사용자, 복구와 열린 세션을 시험합니다. 검증된 복귀와 함께 경로 개설과 종료 순서를 정합니다. 새 도메인 등록 성공이 모든 이전 세션의 폐기를 입증하지는 않습니다.

재현 가능한 수락 사례

가상 예시입니다. 고객이나 실제 관측 결과를 나타내지 않습니다.

사례 입력 보기
{
    "old_origin": "https://login.old.example",
    "old_rp_id": "old.example",
    "new_origin": "https://login.new.example",
    "new_rp_id": "new.example",
    "same_service_account": true,
    "expected": "authenticated_new_registration"
}

예상 판단

가상 예: 계정은 같지만 old.example에서 다른 RP ID의 new.example로 옮깁니다. 이전 인증 정보를 조용히 다시 연결하면 안 되며 새 등록은 계획한 인증 경로를 따라야 합니다.

W3C — Web Authentication Level 2

데이터베이스를 수정해 패스키 RP ID를 바꿀 수 있나요?

아닙니다. RP ID는 검증되는 인증 정보 범위의 일부입니다. 새 범위에서 유효한 등록과 인증된 계정 연결을 준비하세요.

1차 자료: W3C — Web Authentication Level 2. 관련 방법: 실무 가이드 읽기.

postMessage: 출처, 창과 요청 명령 검증

iframe 또는 팝업 메시지 계약으로 예상 밖의 발신자와 데이터를 거부합니다.

  • 정확한 허용 origin, 예상 창 참조와 필요한 유형을 기록합니다. 민감한 데이터는 명확한 targetOrigin을 씁니다. origin은 프로토콜, 호스트와 포트를 포함하며 도메인의 부분 문자열로 발신자를 검증할 수 없습니다.
  • event.origin과 이 통합의 event.source를 예상 창과 비교합니다. 구조, 허용 값과 작업 상태를 검증합니다. eval이나 HTML 삽입 없이 데이터로 처리합니다. 허용 출처도 서버 권한 검증을 대신하지 못합니다.
  • 비슷한 도메인, 다른 포트, 같은 출처의 다른 창, 잘못된 필드와 종료 후 메시지를 시험합니다. 불필요한 리스너를 제거하고 끝난 교환을 무효화합니다. 창 이동 후에도 응답은 미리 승인한 origin으로만 보냅니다.

재현 가능한 수락 사례

가상 예시입니다. 고객이나 실제 관측 결과를 나타내지 않습니다.

사례 입력 보기
{
    "allowed_origin": "https://widget.example",
    "observed_origin": "https://widget.example",
    "expected_window": "active_iframe",
    "observed_window": "another_window",
    "payload_schema_valid": true,
    "expected": "reject_without_effect"
}

예상 판단

가상 예: https://widget.example은 허용되지만 event.source는 다른 창입니다. 계약은 활성 iframe 창을 요구하므로 명령 없이 거부합니다.

MDN — Window.postMessage

1차 자료: MDN — Window.postMessage. 관련 방법: 실무 가이드 읽기.

신원: 인증 요소, 세션 및 복구

두 요소: 인터페이스뿐 아니라 프로토콜 확인

입력 코드, push 승인, WebAuthn 응답은 서비스에 연결되는 방식이 다릅니다. 생체인증은 인증기를 활성화하지만 응답의 암호학적 검증을 대신하지 않습니다.

WebAuthn: 네 가지 별도 통제
사용자 검증을 요구하는 예시입니다. PIN 또는 생체정보는 로컬에 남으며 업무 권한은 별도로 확인합니다.
  1. 로컬 활성화 — 인증기에 맞는 PIN 또는 생체인증.
  2. 응답에 서명 — 서비스 범위의 키와 받은 챌린지.
  3. 서버에서 검증 — 챌린지, 출처, 서명, 플래그.
  4. 작업 권한 확인 — 객체와 작업에 대한 권한.
  • UP와 UV를 따로 관찰한다.
  • 실제 필요한 동기화와 내보내기 제한을 확인한다.
  • 기존 세션에서 분실과 인증 수단 추가를 연습한다.

신원 통제 자세히 보기 →

출처 확인일 · NIST SP 800-63B-4 · final publication NIST · Authenticator Event Management W3C · WebAuthn Level 3

확장 프로그램: 권한과 접근

이 언어판의 상세 참고 설명은 영어로 제공됩니다.

Robust authentication does not describe extension access

Phishing resistance does not remove the need to examine what runs in the browser after a session opens. A manifest provides clues about cookies, scripting, debugging and identity without establishing collection.

  • Test approved extensions in a profile dedicated to sensitive operations.
  • For identity, inspect OAuth scopes and recipients; this permission does not enumerate identity-provider rights.
  • Distinguish session revocation, token revocation, extension disablement and native-component removal.

Read the permission directory and manifest examples →

Google Chrome · Stay secure · Documentation consulted 2026-10-23; browser behaviour remains version-dependent