MFA는 서로 다른 종류의 인증 요소를 두 가지 이상 결합한다. 2FA는 두 종류를 사용하는 경우이며, 2단계 인증은 확인 횟수를 뜻하므로 자동으로 MFA가 되는 것은 아니다.
본 사이트의 견해: MFA는 켜져 있는지가 아니라 방식으로 판단하라
중요한 계정에서는 MFA를 켰는지만 기록하지 말고 실제 방식, 사용자 확인, 복구 수단을 점검한다. 피싱 저항 로그인과 약한 복구 경로가 함께 남을 수도 있다. 이는 본 사이트의 방어 권고이며 대부분의 계정 탈취 원인에 관한 통계적 단정이 아니다.
왜 MFA가 필요한가
비밀번호는 그 자체로 "언젠가 유출된다"고 다뤄야 한다. 재사용, 침해 덤프, 추측, 피싱 모두 비밀번호가 뚫리는 경로다. MFA는 두 번째 요소를 더해, 비밀번호가 뚫려도 그것만으로는 로그인할 수 없게 한다.
무엇보다 이메일 계정이 가장 중요하다. 많은 서비스가 "비밀번호 찾기"를 이메일로 복구하므로, 이메일이 탈취되는 순간 다른 계정들이 차례로 재설정된다. 그래서 이메일은 가장 강한 MFA로 지켜야 할 계정이다(→ 기준선 체크리스트의 Tier 0).
방식에 따른 강도 차이
"2요소"라 불려도 방식 간 강도 차이는 엄청나다. 왼쪽이 약하고 오른쪽이 강하다. 가르는 선은 "가짜 사이트에 제시될 수 있는가?" 이다.
✗ SMS / 이메일
코드는 피싱될 수 있으며 SMS는 번호 탈취 위험도 있음
△ 인증 앱(TOTP)
SMS보다 강하나, 코드가 가짜 사이트로 릴레이될 수 있음
○ 패스키
도메인에 묶인 서명, 사용자 확인을 요구하면 PIN·생체 인증
◎ 보안 키
FIDO2 하드웨어 키; 가장 강함; 예비를 두라
SMS / 이메일 코드
- 코드가 그냥 숫자 — 가짜 사이트에 붙여넣을 수 있음
- SIM 스왑은 전화번호로 받는 SMS나 음성 통화를 겨냥한다. 이메일 코드는 메일 계정과 복구 절차의 보호에 의존하며, 두 종류의 수동 입력 코드는 모두 피싱될 수 있다.
- 릴레이 피싱이 코드를 진짜 사이트로 전달하면 막을 수 없음
- 없는 것보다는 낫지만 중요한 계정에는 그것만으로 부족
패스키 / 보안 키(FIDO2)
- 키가 대상 도메인에 묶임 — 가짜 사이트에선 서명 없음
- 설계상 피싱 저항(사람의 판단에 의존 안 함)
- 패스키나 키만으로 MFA를 구성하려면 서비스가 PIN·생체 인증 등의 사용자 확인을 요구하고 검증해야 한다. 키와 비밀번호를 결합하는 구성도 있으며, 단순 터치는 두 번째 요소가 아니다.
- 이메일, 도메인, 결제 계정에 이것을 쓰라
"피싱 저항"이 실제로 뜻하는 것
이것이 핵심 개념이다. SMS나 인증 앱 코드는 결국 올바른 사이트에 입력하는지를 사람이 눈으로 판단해야 하는데 — 사람은 완벽한 복제 도메인을 구별하지 못한다. 반면 패스키나 보안 키(FIDO2)는 자신이 어느 도메인을 위한 것인지 안다. 그래서 가짜 사이트에는 어떤 서명도 돌려주지 않는다. 다시 말해, 사람이 속아도 키는 가짜 사이트에 서명하지 않는다. 그것이 "피싱 저항"이며, 약한 방식과 강한 방식을 가르는 결정적 차이다.
비교표 (푸시 알림 포함)
이 비교는 CISA의 2022년 10월 자료를 따르며 모든 서비스의 전체 안전성을 평가한 것은 아니다. SMS, 인증 앱, 패스키 외에도 설정 화면에는 방식이 하나 더 나오는 경우가 많다. 휴대폰으로 온 알림에서 "예"를 누르는 방식(푸시 알림)이다. 미국 사이버보안·인프라보안청(CISA)은 MFA를 강한 순서대로 다음과 같이 정리한다.
| 방식 | 가짜 사이트에 입력한 경우 | 누를 때까지 반복 요청 | SIM 스왑 | 위치(CISA) |
|---|---|---|---|---|
| 패스키 / 보안 키(FIDO2) | 서명이 만들어지지 않음 | 해당 없음 | 해당 없음 | 가장 강함(피싱 저항) |
| 인증 앱 코드(TOTP) | 릴레이될 수 있음 | 해당 없음 | 해당 없음 | 두 번째 등급 |
| 숫자 일치가 있는 푸시 알림 | 릴레이될 수 있음 | 일어나기 어려움 | 해당 없음 | 두 번째 등급 |
| 푸시 알림(승인 버튼만) | 릴레이될 수 있음 | 가능 | 해당 없음 | 세 번째 등급 |
| SMS 또는 음성 코드 | 릴레이될 수 있음 | 해당 없음 | 가능 | 최후 수단 |
푸시 알림의 약점은 이렇다. 공격자가 비밀번호를 손에 넣으면, 사용자가 실수로 또는 귀찮아서 "승인"을 누를 때까지 승인 요청을 계속 보낸다. CISA는 이것을 "푸시 폭탄(push bombing)", 즉 MFA 피로 공격이라고 부른다. 대책은 숫자 일치다. 로그인 화면에 표시된 숫자를 앱에 입력해야만 승인할 수 있다. Microsoft의 회사·학교 계정(Microsoft Entra ID)에서는 2023년 5월 8일부터 Microsoft Authenticator의 모든 푸시 알림에 숫자 일치가 필수가 되었다.
표의 수동 코드와 일반 푸시는 피싱 저항 방식이 아니다. FIDO만 가능한 것은 아니며 NIST는 클라이언트 인증 TLS도 설명한다. 이 글은 개인 서비스에서 흔한 패스키·FIDO2 키를 다룬다. CISA는 이전 단계의 대안으로 인증 앱 코드나 숫자 일치 푸시를 권고한다.
상황별: 어느 방식을 고를까
모든 계정에 같은 방식을 쓸 필요는 없다. 탈취되었을 때 피해가 얼마나 큰지로 나눠라.
| 계정 또는 상황 | 권장 방식 | 함께 설정할 백업 |
|---|---|---|
| 개인 이메일(Gmail, Outlook.com 등) | 패스키 | 두 번째 기기의 패스키 또는 백업 코드 |
| 비밀번호 관리자 | 패스키 또는 보안 키 | 두 번째 보안 키와 종이에 적어 둔 복구 정보 |
| 도메인, 서버, 클라우드 관리 | 보안 키(두 개) | 다른 곳에 보관한 두 번째 키, 복구 코드 |
| 은행, 증권 | 금융사가 제공하는 패스키 또는 다른 방식 | 금융사 자체의 재설정 절차 |
| 소셜 미디어, 온라인 쇼핑 | 패스키, 없으면 인증 앱 | 백업 코드 |
| 스마트폰이 없는 가족 | 보안 키(두 개), 쓸 수 없으면 SMS | 가족이 보관하는 백업 코드 |
헷갈리면 "이 계정이 다른 계정을 복구하는 데 쓰이는가?"를 물어라. 이메일과 비밀번호 관리자는 다른 모든 계정으로 가는 입구이므로, 이 둘에 가장 강한 방식을 둔다.
설정하는 법 (순서가 중요하다)
이메일, 도메인, 결제부터 시작
비밀번호 관리자 자체에 MFA
지원 안 되면 인증 앱(TOTP)을 써라
복구 코드를 안전하게 저장
백업 요소를 하나 두라
MFA가 있어도 비밀번호 재사용은 멈춰라
MFA는 보험이지 약한 비밀번호의 핑계가 아니다. 피싱 저항이 아닌 MFA(SMS 등)만 가능한 서비스에서는 비밀번호의 강도와 고유성이 여전히 주된 보호 수단이다. 비밀번호 강도 점검기로 가늠하라.
주요 서비스에서 설정하는 곳
시작할 위치는 다음과 같다(2026년 10월 기준 공식 도움말 기준이며, 화면 이름은 바뀔 수 있다).
| 서비스 | 찾는 위치 | 방식과 참고 |
|---|---|---|
| Google 계정 | Google 계정 → "Security & sign-in"(보안 및 로그인) → "2단계 인증" | 패스키, 보안 키, Google 메시지(프롬프트), 인증 앱, SMS 또는 음성, 백업 코드 |
| Microsoft 계정(개인) | account.microsoft.com/security → "Manage how I sign in"(로그인 방법 관리) → "Additional security"(추가 보안) → "Two-step verification"(2단계 인증) | 비밀번호를 없애고 비밀번호 없이 로그인할 수도 있다 |
| Apple 계정 | 설정 → [사용자 이름] → "Sign-In & Security"(로그인 및 보안) → "이중 인증" → "보안 키" | FIDO 인증(FIDO Certified) 키를 최소 두 개 추가해야 한다(iOS 16.3 이상). 추가하면 6자리 확인 코드 대신 키를 쓴다 |
| GitHub | Settings → "Password and authentication"(비밀번호와 인증) | 절차는 GitHub 2단계 인증 설정 방법 |
어느 서비스든 첫 번째 방식을 등록했다면, 같은 날 백업 방식을 설정하고 백업 코드를 저장하라. 미루면 기기를 잃었을 때 그것이 없다.
인증 앱과 보안 키 고르기
인증 앱에서 확인할 것
- 기기를 바꿀 때 코드를 새 휴대폰으로 옮길 수 있는지
- Google Authenticator는 2023년 4월부터 Google 계정으로의 동기화를 선택 사항으로 제공한다
- 코드를 비밀번호 관리자에 두면 편리하지만, 그곳이 뚫리면 두 요소가 같은 곳에서 함께 유출된다
- 중요한 계정은 비밀번호와 분리된 앱에 코드를 둔다
보안 키에서 확인할 것
- FIDO2를 지원하는(FIDO Certified) 제품을 고른다
- 기기의 포트(USB-A, USB-C)나 휴대폰용 NFC에 맞는지 확인한다
- 처음부터 두 개를 사서 같은 계정에 둘 다 등록한다
- 하나는 들고 다니고 다른 하나는 집 등 다른 곳에 둔다
내 설정을 점검하는 법
Google 보안 진단을 실행
Microsoft 계정의 로그인 방식 검토
iPhone에서 신뢰하는 번호와 키 확인
계정별 방식을 목록으로
백업으로 실제 로그인해 보기
흔한 실수와 고치는 법
- 패스키를 추가했지만 SMS로도 로그인이나 재설정이 가능하게 남겨 둔다: 서비스가 허용하면 SMS를 제거하고, 허용하지 않으면 등록된 번호가 여전히 내 것인지 확인한다.
- 예상하지 못한 승인 요청을 누른다: 로그인하지 않았는데 온 요청은 항상 거부하고, 그 계정의 비밀번호를 바꾼다.
- 백업 코드를 휴대폰의 사진이나 스크린샷으로 보관한다: 휴대폰을 잃으면 함께 잃는다. 비밀번호 관리자나 다른 곳의 종이에 보관한다.
- 예비 키나 지원되는 다른 복구 수단이 필요할 수 있음.
- 기기를 바꿀 때 옛 휴대폰부터 초기화한다: 새 휴대폰에서 인증 앱과 패스키가 작동하는지 확인한 뒤에 옛 휴대폰을 초기화한다.
- 전화나 메시지로 요청받아 코드를 불러 준다: 상대가 서비스나 회사 헬프데스크를 자칭하더라도 코드는 누구에게도 알려 주지 않는다.
실제 사례: 넘겨진 코드
미국에서 치과·안과 보험 혜택을 운영하는 DentaQuest는 2026년 5월의 무단 접근에 대해 여러 주 법무장관에게 신고서를 제출했다. 신고서에 따르면, 침입 경로는 사회공학에 속아 인증 정보와 다요소 인증 코드를 제공한 직원 한 명이었다. 회사는 8월 3일의 갱신 신고에서 전국적으로 2,740만 명 이상을 확인했다고 밝혔다. 신고서에는 어떤 종류의 MFA를 쓰고 있었는지는 적혀 있지 않다.
이 사례가 보여 주는 것은, 사람이 불러 주거나 입력할 수 있는 코드는 그 사람이 속으면 넘겨질 수 있다는 점이다. 계정을 운영하는 쪽의 대응은 두 가지다.
- 중요한 계정을 패스키나 보안 키처럼 넘겨줄 수 없는 방식으로 옮긴다
- 헬프데스크가 누군가의 인증 방식을 재설정하기 전에 요청자의 본인 확인을 한다
전체 경위와 가입자가 할 일은 DentaQuest 데이터 유출(영문)에 정리했다.
본 사이트는 어떻게 하는가
본 사이트는 중요한 계정(특히 이메일, 도메인, 서버 관리, 결제)을 가능한 한 피싱 저항 MFA로 잠근다. 이유는 단순하다: 이 중 하나가 탈취되면 다른 계정까지 함께 탈취될 수 있기 때문이다. 일상 로그인은 비밀번호 관리자에 두고, 관리자 자체에도 MFA를 건다.
그리고 "MFA를 켰다"에 멈추지 않고 — 어느 방식이 걸려 있는지 주기적으로 검토한다. 중요한 계정이 SMS만 있는 것을 발견하면, 그것을 약점으로 보고 패스키/보안 키로 올리는 것을 우선한다. 존재가 아니라 강도로 관리하라 — 그것이 본 사이트의 방침이다.
출처
-
NIST SP 800-63-4 / SP 800-63B-4 — NIST: authentication factors / NIST: phishing resistance
-
FIDO Alliance — Passkeys FAQ: user verification
-
CISA, "Implementing Phishing-Resistant MFA"(2022년 10월) — cisa.gov(PDF)(강한 순서의 MFA 형태, 푸시 폭탄, SIM 스왑)
-
CISA, "Implementing Number Matching in MFA Applications"(2022년 10월) — cisa.gov(PDF)
-
Microsoft Learn, "How number matching works in MFA push notifications for Authenticator" — learn.microsoft.com
-
Google 계정 고객센터, "Turn on 2-Step Verification" — support.google.com
-
Microsoft 지원, "How to use two-step verification with your Microsoft account" — support.microsoft.com
-
Apple 지원, "About Security Keys for Apple Account" — support.apple.com
-
Google Security Blog, "Google Authenticator now supports Google Account synchronization"(2023년 4월 24일) — security.googleblog.com
-
DentaQuest의 워싱턴주 법무장관 신고(2026년 7월 16일, 8월 3일 갱신) — atg.wa.gov
다음으로 읽기
- GitHub 설정: GitHub 2단계 인증 설정 방법
- 탈취 여부 확인: 누군가 내 계정에 접속했는지 확인하는 법(로그인 기록, 로그인된 기기)
- 실제 사례: DentaQuest — 속은 직원이 MFA 코드를 넘긴 사례(영문)
- 기본: 보안 기준선 체크리스트(이메일, 도메인, 결제부터)
- 저장: 비밀번호를 안전하게 저장하는 법
- 용어집: SPF/DKIM/DMARC(위조 방지 이메일 인증)
- 용어집: 피싱이란 무엇인가(피싱 저항 MFA가 막으려는 위협)
- 용어집: 2단계 인증(2FA)이란 / 일회용 비밀번호(OTP)란(방식 용어 정리)
- 비밀번호 없는 로그인: 패스키란: 공개 키 로그인·피싱 저항·동기화의 차이
- 도구: 비밀번호 강도 점검기