2단계 인증(2FA)을 쓰면 비밀번호가 유출되어도 그것만으로는 아무도 들어올 수 없습니다. 혼동되기 쉬운 2단계 검증과의 차이, 그리고 방식별 강약을 정리합니다(공격 절차는 싣지 않습니다).
'2요소'와 '2단계'의 차이
말이 비슷해 혼동되지만, 목표를 기억하면 간단합니다. 인증의 요소는 다음 세 범주로 나뉩니다.
**2단계 인증(2FA)**은 서로 다른 범주 두 가지를 섞습니다(예: 비밀번호 = 지식 + 인증 앱 = 소유). 하나가 뚫려도 다른 범주가 남으므로 공격자가 들어올 수 없다는 것이 핵심입니다.
반면 2단계 검증(2SV)은 '두 번 확인한다'는 뜻일 뿐이라, 두 단계가 같은 범주여도 성립합니다(비밀번호 + 비밀 질문은 두 단계이지만 두 요소는 아님). 그래서 정말로 강하게 하려면 다른 범주를 섞는 것이 핵심입니다.
방식별 강약: 가짜 사이트에 입력한 것을 빼앗길 수 있는가
2FA를 켜도 방식에 따라 강도는 크게 다릅니다. 결정적인 것은 가짜 사이트에 실수로 '증명'을 넘겨줄 수 있는가입니다.
강 ── 패스키 / 보안 키(FIDO2)
서명이 도메인에 묶임. 구조적으로 가짜 사이트에 제시할 수 없음(피싱 저항)
중 ── 인증 앱(TOTP)
SMS보다 강하지만 사람이 코드를 읽으므로 가짜 사이트에 넘겨줄 수 있음
약 ── SMS / 이메일 코드
코드는 피싱될 수 있으며 SMS는 번호 탈취 위험도 있음
약함: SMS / 이메일 코드
- 코드를 사람이 읽고 입력하므로 가짜 사이트에 그대로 넘겨줄 수 있음
- SIM 스왑은 전화번호로 받는 SMS나 음성 통화를 겨냥한다. 이메일 코드는 메일 계정과 복구 절차의 보호에 의존하며, 두 종류의 수동 입력 코드는 모두 피싱될 수 있다.
- 그래도 비밀번호만 쓰는 것보다는 확실히 강함(없는 것보다 훨씬 낫다)
강함: 패스키 / 보안 키(FIDO2)
- 서명이 사이트의 도메인에 묶임, 가짜 사이트에 제시할 수 없음
- 패스키나 키만으로 MFA를 구성하려면 서비스가 PIN·생체 인증 등의 사용자 확인을 요구하고 검증해야 한다. 키와 비밀번호를 결합하는 구성도 있으며, 단순 터치는 두 번째 요소가 아니다.
- 인증 앱(TOTP)은 그 중간. SMS보다 강하지만 가짜 사이트에 제시할 수 있음
2FA, 2단계 검증, MFA, OTP, 패스키의 차이
비슷한 용어가 많은 것은 개념을 가리키는 말과 방식을 가리키는 말이 섞여 쓰이기 때문입니다.
| 용어 | 뜻 | 예 |
|---|---|---|
| 2단계 인증(2FA) | 서로 다른 종류의 증명 두 가지를 조합한다는 개념 | 비밀번호 + 인증 앱 코드 |
| 다요소 인증(MFA) | 서로 다른 종류의 증명 두 가지 이상을 조합한다는 개념(2FA 포함) | 도메인에 묶인 서명, 사용자 확인을 요구하면 PIN·생체 인증 |
| 2단계 검증(2SV) | 두 번 확인하는 것(두 단계가 같은 종류여도 됨) | 비밀번호 + 비밀 질문 |
| 일회용 비밀번호(OTP) | 두 번째 증명으로 자주 쓰이는 일회성 코드 | 인증 앱, SMS, 이메일로 받는 코드 |
| 패스키 | 기기 안의 개인 키로 서명하는 로그인 방식 | 지문이나 얼굴로 잠금을 해제해 로그인 |
2FA와 MFA는 '무엇을 충족해야 하는가', OTP와 패스키는 '어떻게 충족하는가'를 가리킵니다. 코드는 일회용 비밀번호(OTP)란에서, 서명은 패스키란에서 설명합니다. 서비스 화면에 '2단계 인증'이나 '2단계 확인'이라고 적혀 있어도 실제로는 비밀번호 + 인증 앱 같은 2FA인 경우가 많으므로, 실제 방식을 보고 판단하세요.
2FA가 막아 주는 정도
Microsoft 연구진이 2023년 자사 클라우드 이용자를 분석한 연구에서는 MFA를 켠 계정의 침해 위험이 전체적으로 99.22% 낮았고, 유출된 인증 정보가 쓰인 경우에도 98.56% 낮았습니다. 비밀번호 재사용이나 유출에 의한 탈취의 대부분은 방식과 상관없이 2FA를 켜는 것만으로 막힙니다.
그래도 2FA가 막지 못하는 것이 있습니다.
- 가짜 사이트에 입력: 가짜 사이트에 입력한 SMS나 인증 앱 코드는 진짜 사이트로 중계됩니다. 패스키와 하드웨어 키는 이를 막습니다
- 약한 복구 수단: SMS나 등록된 이메일만으로 계정을 복구할 수 있다면 그곳이 입구가 됩니다
- 2FA가 없는 계정: 공격자가 2FA가 없는 업무용 이메일이나 외부 서비스 계정으로 들어오면, 다른 방어는 도움이 되지 않습니다
공개된 사고: 원인 평가와 권장 대책 구분
운영 그룹은 2019년 8월 1일 발표에서 불법으로 얻은 ID·비밀번호 목록을 이용한 공격일 가능성이 높다고 평가했다. 이는 당시 회사의 평가이며 모든 공격 경로가 확정됐다는 뜻은 아니다. 같은 발표는 외부 ID 연동, 비밀번호 알림, 상담 채팅을 통한 재설정 등이 직접 원인이 된 사례를 찾지 못했다고 설명했다. 2019년 7월 31일 17시 기준 808명·38,615,473엔으로 부정 충전과 부정 이용을 모두 포함한다. 8월 1일 발표의 시점이 정해진 수치이며 최종 총피해액으로 제시된 것은 아니다. 7pay 부정 사용 사건(2019년).
이후 2FA를 이용자에게 맡기지 않고 의무화하는 서비스가 늘었습니다. GitHub는 2023년 3월부터 코드를 기여하는 이용자에게 2FA를 단계적으로 의무화하고 있습니다(설정 방법은 GitHub 2단계 인증 설정). 2026년 8월 일본에서 공표된 주요 사고를 분류해 보니, 취약점 악용보다 위탁업체의 Microsoft 365, 업무용 이메일, GitHub 인증 정보처럼 정당한 인증 정보에서 시작된 사례가 더 많았습니다(2026년 일본 침해 사고의 침입 경로).
자신의 계정 점검 방법
순서를 정한다
이메일과 비밀번호 관리자부터 시작합니다. 둘 다 다른 계정을 재설정하거나 관리하는 데 쓰이기 때문입니다. 그다음 도메인, 클라우드, GitHub, 그다음 은행, 증권, 결제입니다.
계정마다 2FA 방식을 확인한다
보안 설정에서 2FA가 켜져 있는지, 어떤 방식인지 봅니다. SMS나 이메일 코드라면 인증 앱이나 패스키를 추가하고 우선 방식으로 지정합니다. 방식 비교는 MFA를 제대로 고르기에 있습니다.
복구 코드와 두 번째 방식을 준비한다
복구 코드는 비밀번호 관리자처럼 휴대폰이 아닌 곳에 저장합니다. 예비 패스키나 하드웨어 키 같은 두 번째 방식도 등록합니다.
복구용 이메일과 전화번호를 점검한다
등록된 복구용 이메일 주소와 전화번호가 여전히 본인 것인지, 복구용 이메일 계정 자체에도 2FA가 켜져 있는지 확인합니다. 비밀번호가 이미 유출되었는지는 비밀번호 유출 확인 방법을 참고하세요.
다른 사람을 관리한다면 2FA를 의무화한다
회사 이메일, GitHub 조직, 클라우드 관리 콘솔에서는 2FA를 선택 사항으로 두지 말고 조직 설정에서 필수로 지정합니다. 관리자 계정에는 패스키나 하드웨어 키를 쓰도록 요청합니다.
이 사이트의 관점: 먼저 켜고, 그다음 '넘겨줄 수 없는 방식'으로
2FA에서 가장 흔한 실패는 '어느 것이 가장 강한가'를 지나치게 고민하다가 결국 아무것도 켜지 않는 것입니다. 우선순위는 분명합니다. 먼저 모든 계정에서 어떤 형태로든 2FA를 켜고, 그다음 가장 중요한 계정(이메일, 도메인, 결제)부터 피싱 사이트에 넘겨줄 수 없는 방식(패스키)으로 옮깁니다.
이 사이트는 '주의해서 가짜 사이트를 알아채는 것'을 방어 전략으로 보지 않습니다. 사람의 주의력보다, 구조적으로 가짜 사이트에 증명을 넘겨줄 수 없는 방식에 기대세요.
출처(1차 자료)
- NIST SP 800-63B-4, "Digital Identity Guidelines: Authentication and Authenticator Management"(2025년 7월) — pages.nist.gov(인증 요소, 피싱 저항성, 전화망 방식은 제한적)
- Meyer et al., "How effective is multifactor authentication at deterring cyberattacks?"(Microsoft, 2023) — arxiv.org(MFA로 침해 위험 99.22% 감소, 유출 인증 정보 사용 시 98.56% 감소)
- CISA, "Implementing Phishing-Resistant MFA"(2022년 10월) — cisa.gov (PDF)(MFA 방식의 강약 순서, SMS를 노리는 SIM 스왑)
- GitHub Docs, "About mandatory two-factor authentication" — docs.github.com(2023년 3월부터 단계적 의무화)
- 운영 그룹의 서비스 폐지·조사·대응 발표 (2019-08-01) — 7andi.com
다음으로 읽기
- GitHub 설정: GitHub 2단계 인증 설정 방법
- 용어집: 일회용 비밀번호(OTP)란(인증 앱 코드의 동작 원리: TOTP/HOTP/SMS) · 패스키란(가짜 사이트에 넘겨줄 수 없는 가장 강한 방식)
- 용어집: 피싱이란(2FA를 노리는 AiTM 공격의 이해)
- 학습: MFA를 제대로 고르기(실무에서의 방식 선택)
- 사례: 7pay 부정 사용 사건(2019년)