다중 인증

Multi-factor Authentication

방법

비밀번호 하나로 끝내지 않고 종류가 다른 증거를 둘 이상 요구해 접속한 사람이 본인인지 확인하는 방식입니다.

등장 배경

오랫동안 로그인은 아이디와 비밀번호 한 쌍이면 끝나는 일이었습니다. 인증, 그러니까 접속한 사람이 누구인지 확인하는 절차 전체를 비밀번호 한 줄이 혼자 짊어진 셈입니다. 문제는 그 한 줄이 새 나가는 경로가 너무 많다는 데 있었습니다. 저장된 비밀번호는 해싱으로 되돌릴 수 없게 뭉개 두지만, 그 방어는 서버가 털린 경우에만 일합니다. 가짜 로그인 화면에 사용자가 직접 입력해 넘겨주면 뭉개기 전의 값이 그대로 건너갑니다.

여기에 사람들이 같은 비밀번호를 여러 서비스에 돌려쓴다는 사정이 겹칩니다. 그래서 공격자는 어렵게 뚫을 필요가 없습니다. 어딘가에서 유출된 아이디와 비밀번호 목록을 받아다가 다른 서비스 로그인 화면에 그대로 넣어 보면, 수만 건 중 몇백 건은 그냥 열립니다. 팀 문서 도구라면 계정 하나가 열리는 순간 그 사람이 속한 워크스페이스의 문서가 전부 열립니다.

다중 인증은 비밀번호가 언젠가 새 나간다고 전제하고 설계를 바꾼 것입니다. 비밀번호를 더 복잡하게 만들거나 더 자주 바꾸게 하는 대신, 비밀번호를 아는 것만으로는 부족하게 만들었습니다. 유출된 목록을 그대로 넣어 보는 공격은 두 번째 증거 앞에서 멈춥니다.

사용 절차

아이디와 비밀번호가 맞아도 바로 들여보내지 않고, 종류가 다른 두 번째 증거를 한 번 더 확인한 뒤에 통과시킵니다.

여기서 종류가 다르다는 말이 중요합니다. 증거는 셋으로 나뉩니다.

  1. 아는 것 — 비밀번호, PIN 처럼 머릿속에 있는 것입니다.
  2. 가진 것 — 휴대폰, 보안 키처럼 손에 쥐고 있는 물건입니다.
  3. 자기 자신인 것 — 지문이나 얼굴처럼 몸에 붙어 있는 것입니다.

서로 다른 칸에서 하나씩 골라야 다중 인증입니다. 비밀번호를 두 번 묻는 것은 같은 칸을 두 번 쓰는 것이라 하나가 새면 둘 다 샙니다.

실제 도입은 다섯 단계로 굴러갑니다.

  1. 등록 — 사용자가 설정 화면에서 두 번째 수단을 미리 연결합니다. 인증 앱이라면 화면의 QR 코드를 찍어 두는 절차입니다.
  2. 복구 수단 발급 — 등록과 동시에 일회용 복구 코드 열 개쯤을 내줍니다. 휴대폰을 잃어버린 사람이 영영 못 들어오는 상황을 막는 장치입니다.
  3. 첫 요소 확인 — 로그인 화면에서 비밀번호를 맞춰 봅니다. 틀리면 두 번째 요소는 묻지 않습니다.
  4. 둘째 요소 요구 — 인증 앱의 여섯 자리 숫자를 입력받거나, 휴대폰으로 보낸 승인 알림을 누르게 하거나, 보안 키를 꽂게 합니다. 인증 앱 숫자는 30초마다 바뀌므로 화면을 훔쳐본 사람이 나중에 쓸 수 없습니다.
  5. 기기 기억 — 통과한 기기를 30일쯤 신뢰 목록에 올려 매번 묻지 않습니다. 이 기간을 너무 늘리면 보호가 사실상 사라지고, 너무 줄이면 사용자가 기능을 꺼 버립니다.

두 번째 수단은 문자, 인증 앱, 승인 알림, 보안 키 순으로 안전해집니다. 문자는 가장 쉽게 붙일 수 있어 널리 쓰이지만, 통신사에 남의 신분을 대고 번호를 자기 유심으로 옮겨 가는 수법이 알려져 있어 관리자 계정에는 권하지 않습니다.

적합한 상황과 한계

잃었을 때 되돌리기 어려운 것이 걸려 있는 계정부터 겁니다. 문서를 전부 내려받을 수 있는 관리자, 결제 수단을 바꿀 수 있는 계정, 인가 설정을 만질 수 있는 계정이 먼저입니다. 인가는 확인된 사람이 무엇을 해도 되는지 정하는 절차인데, 그 설정을 바꿀 수 있는 계정 하나면 나머지 방어가 의미를 잃습니다.

기업 고객을 받기 시작하면 성격이 달라집니다. 도입 전 보안 점검 문서에 다중 인증 지원 여부가 거의 빠지지 않고 들어 있어서, 없으면 계약 자체가 막힙니다. 이 경우 회사 계정으로 한 번 로그인해 여러 서비스를 쓰게 하는 싱글 사인온과 함께 요구받는 일이 많습니다.

한계도 분명합니다. 첫째로 피싱을 완전히 막지는 못합니다. 가짜 로그인 화면이 사용자가 입력한 여섯 자리 숫자를 받아 실시간으로 진짜 서비스에 대신 넣어 버리면 통과됩니다. 보안 키는 접속한 주소가 진짜인지를 기계가 확인하기 때문에 이 수법에 걸리지 않지만, 사용자에게 물건을 하나 더 사게 해야 합니다.

둘째로 복구 절차가 새 구멍이 됩니다. 휴대폰을 잃은 사용자를 고객센터가 어떻게 확인하고 풀어 줄지 정해 두지 않으면, 공격자가 그 창구를 통해 두 번째 요소를 건너뜁니다. 셋째로 단계가 하나 늘면 사용자는 그만큼 떨어져 나갑니다. 그래서 대개 전 구성원에게 한꺼번에 강제하기보다 관리자부터 걸고, 일반 사용자에게는 선택으로 열어 둔 뒤 점차 범위를 넓힙니다.

실무 용례

"엔터프라이즈 문의 들어왔는데 MFA 지원하냐고 먼저 물어보세요."

보안 점검 문서의 첫 항목이라 지원 여부가 계약 성사를 가른다는 뜻입니다.

"관리자 권한 계정은 다중 인증 필수로 걸어 둡시다."

전체 강제는 미루더라도 피해가 큰 계정만은 지금 막자는 제안입니다.

"문자 말고 인증 앱도 붙여 주세요. 번호 가로채기가 있어서요."

두 번째 수단을 문자 하나로만 두면 유심 탈취 수법에 뚫린다는 지적입니다.

페이지덱에서는 기업 고객 한 곳이 보낸 보안 점검 문서에서 시작됐습니다. 수아가 받아 온 문서의 접근 제어 항목에 다중 인증 지원 여부가 있었고, 지원하지 않으면 그 계약이 거기서 멈추는 조건이었습니다. 태오가 인증 앱 방식을 먼저 붙이고 복구 코드까지 만든 뒤, 규원이 관리자 권한을 가진 열두 명에게만 강제로 켰습니다. 나머지 구성원에게는 설정 화면에서 켤 수 있게만 열어 두고 분기마다 켠 비율을 봅니다.

흔한 오해

다중 인증을 켜면 계정 탈취가 끝난다고 보는 경우가 많습니다. 두 개를 다 뚫어야 한다고 하면 확률이 곱해지는 것처럼 들리니 그럴듯합니다. 하지만 공격자가 가짜 화면과 진짜 서비스 사이에 앉아 사용자가 넣은 숫자를 그대로 넘겨 주면 두 요소가 한꺼번에 통과합니다. 로그인 뒤 브라우저에 남는 접속 증표를 훔치는 수법도 인증 자체를 건드리지 않습니다. 끝났다고 생각하고 로그 감시나 이상 접속 탐지를 접으면, 뚫린 뒤에 알아챌 방법이 사라집니다.

비밀번호를 두 번 묻거나 비밀번호와 보안 질문을 함께 묻는 것을 다중 인증으로 세는 경우도 흔합니다. 화면에 단계가 둘이니 그렇게 보입니다. 그러나 둘 다 아는 것 칸에 속해서, 유출된 개인정보로 보안 질문의 답까지 맞힐 수 있으면 한 번에 무너집니다. 단계 수가 아니라 칸이 다른지를 봅니다.

같이 보면 좋은 페이지

  • 애플리케이션 보안

    다중 인증이 어느 자리에 놓인 수단인지, 앞뒤에 무엇이 있는지 봅니다

  • 인증

    다중 인증이 보강하려는 절차 자체를 먼저 봅니다

마지막 업데이트 2026-09-16