"비밀번호를 복잡하게, 자주 바꾸세요"라는 조언은, 절반은 오해이고 절반은 시대에 뒤떨어진 말입니다. 현대의 정답은 비밀번호 자체가 아니라, 그 너머에 있습니다.
들어가며: 우리가 비밀번호에 대해 잘못 알고 있는 것들
비밀번호에 관한 조언만큼 널리 퍼져 있으면서 동시에 오해가 많은 것도 드뭅니다. "복잡한 비밀번호를 쓰세요." "주기적으로 바꾸세요." "특수문자를 섞으세요." 이런 조언들은 너무 익숙해서, 우리는 그것이 정말 효과적인지 의심하지 않습니다.
그러나 이 보너스 장은 그 조언들의 상당 부분이 환상에 가깝다고 말합니다. 일부는 처음부터 오해였고, 일부는 한때 의미가 있었으나 이제 시대에 뒤떨어졌습니다. 더 중요하게는, 비밀번호에 대한 이 모든 논의가 사실 잘못된 곳에 초점을 맞추고 있다는 것입니다. 현대 보안에서 비밀번호는 더 이상 방어의 중심이 아닙니다. 방어의 중심은 그 너머에 있습니다.
이 장에서는 비밀번호에 관한 흔한 환상을 하나씩 짚고, 무엇이 실제로 의미가 있는지를 가립니다. 그리고 현대의 진짜 정답 — 2채널 인증과, 백엔드 연결에 대한 IP 화이트리스트 — 으로 나아갑니다. 본문 7장에서 SSH를 다루며 공개키 인증이 비밀번호의 약점으로부터 자유롭다고 했던 것을, 여기서는 비밀번호 일반으로 확장합니다.
핵심 메시지를 미리 말하면 이렇습니다. 비밀번호를 완벽하게 만들려는 노력보다, 비밀번호 하나에 의존하지 않는 구조를 만드는 것이 옳습니다. 비밀번호는 뚫릴 수 있다고 가정하고(원칙 2, 침해를 가정하라), 그것이 뚫려도 안전한 구조를 만드는 것입니다.
H.1 환상 1: "자주 바꿀수록 안전하다"
가장 널리 퍼진, 그리고 가장 잘못된 환상부터 시작합니다. 비밀번호를 주기적으로(예: 3개월마다) 강제로 바꾸게 하는 관행입니다.
왜 이것이 환상인가
직관적으로는 자주 바꾸면 더 안전할 것 같습니다. 그러나 현실은 정반대일 수 있습니다. 비밀번호를 자주 바꾸게 강제하면, 오히려 보안이 약해지는 경향이 있습니다.
이유는 사람의 행동에 있습니다. 비밀번호를 자주 바꿔야 하는 사람은, 매번 강하고 새로운 비밀번호를 기억하기 어렵습니다. 그래서 사람들은 예측 가능한 방식으로 대응합니다. 기존 비밀번호에 숫자만 하나씩 늘리거나(끝에 1, 2, 3을 붙이는 식), 약간의 변형만 가하거나, 기억하기 쉬운 단순한 패턴을 쓰거나, 어딘가에 적어 둡니다. 결국 자주 바꾸라는 요구가, 더 약하고 더 예측 가능한 비밀번호를 만들어 냅니다.
게다가 비밀번호를 더 자주 입력하고 더 자주 다룬다는 것은, 그만큼 유출될 기회가 늘어난다는 뜻일 수도 있습니다. 변경 과정에서, 새 비밀번호를 적어 두는 과정에서, 더 자주 입력하는 과정에서, 노출의 기회가 생깁니다.
그렇다면 언제 바꿔야 하는가
비밀번호를 바꿔야 할 때는, 정해진 주기가 아니라 이유가 있을 때입니다. 유출되었거나 유출이 의심될 때, 다른 곳에서 침해 정황이 있을 때, 해당 비밀번호가 약했음을 깨달았을 때입니다. 이것은 7장에서 SSH 키를 "유출·분실·권한 종료 시 즉시 폐기"하라고 한 것과 같은 원리입니다. 일정이 아니라 사건이 변경의 트리거여야 합니다.
현대의 보안 권고는 이 방향으로 이동했습니다. 무의미한 주기적 강제 변경을 폐기하고, 대신 충분히 강한 비밀번호를 만들되 이유가 있을 때 바꾸고, 무엇보다 비밀번호 하나에 의존하지 않는 구조(H.4의 2채널 인증)를 갖추는 것입니다.
이건 제 개인 의견이 아니라, 비밀번호 정책의 사실상 국제 표준인 미국 NIST(국립표준기술연구소)의 공식 지침이기도 합니다. NIST의 디지털 인증 가이드라인(SP 800-63B)은 "유출 정황이 있을 때를 제외하고 비밀번호를 주기적으로 강제 변경하지 말 것"을 명시합니다. 즉 3개월마다 바꾸라는 사내 규정이 아직 있다면, 그건 보안을 위한 것이 아니라 오히려 표준에 역행하는 관행입니다. 현장에서 고객사 보안 정책을 손볼 때 제가 가장 먼저 들어내는 항목도 이 "90일 강제 변경"입니다 — 없애는 것만으로 사용자들의 비밀번호 품질이 눈에 띄게 좋아집니다.
H.2 환상 2: "복잡할수록 안전하다" — 절반의 진실
다음은 "비밀번호를 복잡하게(특수문자, 대소문자, 숫자를 섞어) 만들라"는 조언입니다. 이것은 환상이라기보다 절반의 진실입니다. 의미가 있지만, 그 이유를 정확히 알아야 합니다.
복잡함이 막으려는 진짜 것
비밀번호를 복잡하게 만들라는 조언의 진짜 목적은, 흔히 오해하듯 "공격자가 추측하기 어렵게" 하는 것만이 아닙니다. 더 중요한 목적은 공격자가 데이터베이스화해 둔 목록에 들어 있지 않게 하는 것입니다.
이 차이가 중요합니다. 공격자는 비밀번호를 하나씩 머리로 추측하지 않습니다. 그들은 방대한 비밀번호 목록을 가지고 있습니다. 과거 여러 유출 사고에서 모은 실제 비밀번호들, 흔히 쓰이는 단어와 조합들을 데이터베이스로 만들어 두고, 그것을 대량으로 빠르게 시도합니다(본문 1장의 무차별 대입, 11장의 자격 증명 스터핑). 만약 당신의 비밀번호가 그 목록에 있다면 — 즉, 누군가 이미 쓴 적이 있어 유출 데이터에 포함되어 있거나, 흔한 조합이라면 — 그것은 복잡해 보여도 즉시 뚫립니다.
그래서 "복잡하게"의 진짜 의미는, 남들이 쓰지 않는, 그래서 그 목록에 없는 비밀번호를 쓰라는 것입니다. 특수문자를 섞는 것이 도움이 되는 이유도, 그 자체가 마법이어서가 아니라, 그것이 흔한 목록에서 벗어나게 해 주기 때문입니다.
복잡함보다 중요한 것: 길이와 고유성
현대의 이해에 따르면, 비밀번호의 강도에서 복잡함(특수문자 섞기)보다 더 중요한 것은 길이와 고유성입니다.
길이가 중요한 이유는, 충분히 긴 비밀번호는 무차별 대입으로 뚫는 데 비현실적으로 오랜 시간이 걸리기 때문입니다. 짧고 복잡한 것보다, 충분히 길면서 기억할 수 있는 것이 종종 더 낫습니다. 여러 단어를 조합한 긴 구절(passphrase, 패스프레이즈 — 예: correct-horse-battery-staple처럼 무관한 단어 여러 개를 이은 암호 문구)이 좋은 예입니다. 기억하기는 쉬우면서 충분히 길어, 무차별 대입에 강합니다.
이 역시 앞서 본 NIST SP 800-63B의 권고와 일치합니다. 이 표준은 "대문자·숫자·특수문자를 반드시 섞으라"는 식의 복잡도 강제 규칙(composition rule)을 요구하지 말 것을 권하고, 대신 충분한 길이(최소 8자, 가능하면 그 이상을 허용)와 유출 목록 대조를 강조합니다. 다시 말해, 표준이 가리키는 방향도 "복잡함"이 아니라 "길이와 고유성"입니다.
고유성이 중요한 이유는 H.3에서 다룰 재사용 문제 때문입니다. 아무리 강한 비밀번호라도, 여러 곳에 재사용하면 한 곳의 유출이 모든 곳의 침해가 됩니다.
요컨대, "복잡하게"라는 조언은 틀린 것이 아니라 부정확합니다. 정확히는 "흔하지 않고, 충분히 길고, 어디에도 재사용하지 않은" 비밀번호를 쓰라는 것입니다.
H.3 진짜 위험: 재사용
비밀번호에 관한 가장 실질적인 위험은, 복잡함이나 변경 주기가 아니라 재사용입니다. 이것은 환상이 아니라 진짜 위협입니다.
재사용이 왜 치명적인가
사람들은 기억의 한계 때문에, 여러 서비스에 같은(또는 비슷한) 비밀번호를 재사용하는 경향이 있습니다. 그리고 이것이 현대 계정 침해의 가장 흔한 원인 중 하나입니다.
그 구조는 이렇습니다(11장의 자격 증명 스터핑). 어떤 서비스가 침해되어 비밀번호가 유출됩니다. 당신 잘못이 아니어도, 당신이 쓰던 서비스가 뚫리면 당신의 비밀번호가 유출 데이터에 포함됩니다. 공격자는 이 유출된 비밀번호를 가지고, 당신이 같은 비밀번호를 썼을 법한 다른 서비스들 — 이메일, 금융, 업무 시스템 — 에 차례로 시도합니다. 만약 당신이 그 비밀번호를 재사용했다면, 한 곳의 유출이 당신의 모든 계정으로 번집니다.
이것이 H.2에서 고유성을 강조한 이유입니다. 아무리 강한 비밀번호라도, 재사용하는 순간 그 강도는 무의미해집니다. 가장 약한 서비스의 보안 수준이, 그 비밀번호를 쓰는 모든 곳의 보안 수준이 되어 버리기 때문입니다.
지금 바로 확인하기. 내 이메일이나 비밀번호가 과거 유출 사고에 포함됐는지는 Have I Been Pwned(HIBP)에서 1분 만에 확인할 수 있습니다. 보안 연구자 Troy Hunt가 운영하는 무료 서비스로, 지금까지 공개된 수십억 건의 유출 계정을 모아 둔 데이터베이스입니다. 이메일을 넣어 보고 하나라도 걸린다면, 그 비밀번호를 재사용한 모든 곳을 지금 바꿔야 한다는 신호입니다(H.1에서 말한 "이유가 있을 때"의 바로 그 이유입니다). 비밀번호 칸이 아니라 이메일을 넣는 게 핵심이고, 비밀번호 자체를 확인하고 싶다면 같은 사이트의 'Pwned Passwords'를 쓰면 됩니다 — 비밀번호 원문이 서버로 전송되지 않도록 설계돼 있어 안전합니다.
방어: 비밀번호 관리 도구
모든 서비스에 서로 다른, 강한 비밀번호를 쓰는 것은 사람의 기억으로 불가능합니다. 그래서 현대의 현실적 해법은 비밀번호 관리 도구(password manager)입니다.
비밀번호 관리 도구는 각 서비스마다 서로 다른 강한 비밀번호를 생성하고, 안전하게 저장하고, 필요할 때 채워 줍니다. 사용자는 하나의 강한 마스터 비밀번호(그리고 H.4의 2채널 인증)만 기억하면, 나머지는 도구가 관리합니다. 이로써 재사용 없이, 각 서비스마다 고유하고 강한 비밀번호를 쓸 수 있게 됩니다. 기억의 한계라는 근본 문제를, 도구가 해결하는 것입니다.
널리 쓰이는 도구로는 Bitwarden(오픈소스이고 무료 요금제로도 개인용으로 충분합니다)과 1Password 등이 있습니다. 어느 것이든 좋으니 하나를 골라 오늘 시작하는 것이 중요합니다 — 처음 도입할 때 기존에 재사용하던 비밀번호 몇 개를 도구가 생성한 고유한 것으로 바꾸는 데서 시작해, 자주 쓰는 계정부터 차차 옮기면 됩니다. 저도 수백 개의 서비스 자격 증명을 다루지만, 머릿속에 기억하는 비밀번호는 관리 도구의 마스터 비밀번호 단 하나뿐입니다. 나머지는 전부 도구가 만든, 저조차 외우지 못하는 무작위 문자열입니다.
다만 이 도구 자체가 모든 비밀번호의 열쇠이므로, 그 마스터 비밀번호는 매우 강해야 하고, 반드시 2채널 인증으로 보호되어야 합니다. 보너스 2에서 이메일이 다른 계정의 열쇠라고 했듯, 비밀번호 관리 도구도 같은 무게로 보호해야 합니다.
H.4 현대의 정답: 2채널 인증
이제 이 장의 핵심에 도달합니다. 비밀번호에 관한 모든 논의의 결론은 이것입니다. 현대의 비밀번호는 반드시 2채널 인증과 함께여야 합니다. 비밀번호 하나에 의존하는 시대는 끝났습니다.
왜 2채널 인증이 결론인가
지금까지 본 모든 것 — 자주 바꾸기의 환상, 복잡함의 한계, 재사용의 위험 — 이 가리키는 한 가지 진실이 있습니다. 비밀번호는 본질적으로 취약하며, 언젠가 유출될 수 있다는 것입니다. 아무리 강하고 고유한 비밀번호를 써도, 피싱으로 넘어갈 수 있고(3장), 서비스 유출에 포함될 수 있고, 다양한 경로로 새어 나갈 수 있습니다.
그래서 옳은 접근은, 비밀번호를 완벽하게 만들려 애쓰는 것이 아니라, 비밀번호가 유출되어도 안전한 구조를 만드는 것입니다(원칙 2, 침해를 가정하라). 그 구조가 바로 2채널 인증(다단계 인증, MFA)입니다.
2채널 인증(흔히 2단계 인증·2FA, 더 일반적으로는 다단계 인증·MFA로 부릅니다. 로그인할 때 비밀번호 외에 인증 요소를 하나 더 요구하는 방식)은, 비밀번호(아는 것)에 더해 두 번째 인증 요소 — 예를 들어 당신이 가진 것(특정 기기, 하드웨어 키) — 를 요구합니다. 그러면 공격자가 비밀번호를 손에 넣어도, 두 번째 요소가 없으면 접근할 수 없습니다. 비밀번호의 유출이 곧 침해로 이어지지 않게 되는 것입니다. 본문 3·7·14장과 보너스 2에서 반복해 강조한 이유가 이것입니다.
모든 중요한 계정에 적용하라
2채널 인증은 이제 선택이 아니라, 모든 중요한 계정의 기본이어야 합니다. 특히 보너스 2에서 강조한 이메일(다른 계정의 열쇠), 비밀번호 관리 도구(모든 비밀번호의 열쇠), 금융 계정, 그리고 업무 시스템에는 반드시 적용해야 합니다.
모든 2채널이 똑같지 않다
다만 한 가지를 분명히 해야 합니다. 2채널 인증의 방식에 따라 안전성이 다릅니다. 7장에서 강조했듯, 어떤 방식은 피싱에 취약할 수 있습니다 — 공격자가 두 번째 요소까지 가로채도록 유도하는 정교한 피싱이 있기 때문입니다. 가능하면 피싱에 강한 방식, 특히 7장에서 다룬 하드웨어 보안 키를 우선하십시오. 하드웨어 키는 물리적 장치가 있어야 하고 피싱으로 가로채기 어려워, 가장 강한 두 번째 요소입니다. 그렇더라도, 어떤 형태든 2채널 인증이 있는 것이 없는 것보다 훨씬 낫습니다.
H.5 백엔드 연결: 비밀번호를 넘어 IP 화이트리스트로
지금까지는 사람이 쓰는 비밀번호를 다뤘습니다. 그러나 시스템과 시스템 사이의 연결 — 특히 API 서버나 백엔드 연결 — 에서는, 또 다른 차원의 방어가 필요합니다. IP 화이트리스트입니다.
시스템 간 연결의 특수성
API 서버나 백엔드 시스템에 연결할 때도 자격 증명(API 키 등)을 씁니다. 그런데 시스템 간 연결은 사람의 로그인과 다른 특성이 있습니다. 연결하는 주체가 정해진 시스템들이라는 점입니다. 사람은 어디서든 로그인할 수 있지만, 백엔드 연결은 보통 정해진 서버들 사이에서만 일어납니다.
이 특성을 활용한 강력한 방어가 IP 화이트리스트입니다. 핵심 발상은, 허용된 출처(IP 주소)에서 오는 연결만 받고, 그 외의 모든 연결은 거부하는 것입니다. 이것은 본문 5·6장에서 다룬 공격면 축소와 기본 거부 원칙(12장)의 적용입니다.
IP 화이트리스트가 주는 보호
IP 화이트리스트의 보호는 강력합니다. 설령 API 키나 자격 증명이 유출되어도, 공격자가 허용된 IP에서 연결하지 않는 한 그 키를 쓸 수 없습니다. 즉, 자격 증명 유출이 곧 침해로 이어지지 않게 합니다 — H.4에서 2채널 인증이 사람의 로그인에 대해 한 일을, IP 화이트리스트가 시스템 간 연결에 대해 하는 것입니다. 둘 다 "자격 증명 하나에 의존하지 않는다"는 같은 원리입니다.
그래서 이 원칙을 강조합니다. API 서버 등 백엔드 연결은 반드시 IP 화이트리스트를 사용하십시오. 정해진 시스템들 사이의 연결이라면, 그 정해진 출처만 허용하고 나머지를 모두 막는 것은, 적은 노력으로 큰 보호를 주는 방어입니다. 이것은 6장에서 Cloudflare의 IP 대역만 허용하여 오리진을 보호한 것과 같은 발상이며, 7장에서 SSH 접근 사용자를 제한한 것의 네트워크 버전입니다.
화이트리스트와 다른 방어의 결합
IP 화이트리스트는 그 자체로 강력하지만, 다른 방어와 함께일 때 더 안전합니다(깊이 방어, 원칙 3). IP 화이트리스트로 출처를 제한하고, 그 위에 강한 자격 증명을 쓰고, 통신을 암호화하고(8장), 6장의 방식으로 백엔드를 인터넷에서 숨기면, 여러 겹의 방어가 백엔드 연결을 보호합니다. 어느 한 겹이 뚫려도 다음 겹이 막습니다.
H.6 이 장이 남기는 교훈
이 보너스 장에서 확인한 것을 압축합니다.
첫째, "자주 바꿀수록 안전하다"는 환상입니다. 주기적 강제 변경은 오히려 더 약하고 예측 가능한 비밀번호를 만듭니다. 일정이 아니라 이유(유출·의심)가 변경의 트리거여야 합니다.
둘째, "복잡할수록 안전하다"는 절반의 진실입니다. 복잡함의 진짜 목적은 추측 방지보다, 공격자가 데이터베이스화한 목록에 들어 있지 않게 하는 것입니다. 복잡함보다 길이와 고유성이 더 중요합니다.
셋째, 진짜 위험은 재사용입니다. 한 서비스의 유출이 재사용된 모든 계정으로 번집니다. 비밀번호 관리 도구로, 재사용 없이 각 서비스마다 고유하고 강한 비밀번호를 쓰십시오.
넷째, 현대의 정답은 2채널 인증입니다. 비밀번호는 언젠가 유출될 수 있다고 가정하고, 유출되어도 안전한 구조를 만드는 것입니다. 모든 중요한 계정에 적용하되, 피싱에 강한 방식(하드웨어 키)을 우선하십시오.
다섯째, 백엔드 연결은 IP 화이트리스트를 쓰십시오. 허용된 출처만 받고 나머지를 거부하면, API 키가 유출되어도 침해로 이어지지 않습니다. 2채널 인증이 사람의 로그인에 한 일을, IP 화이트리스트가 시스템 간 연결에 합니다.
여섯째, 비밀번호를 완벽하게 만들기보다, 비밀번호 하나에 의존하지 않는 구조를 만드십시오. 이것이 비밀번호에 관한 모든 논의의 결론이며, 침해를 가정하는 원칙 2의 적용입니다.
이 장의 실행 항목
- 주기적 강제 변경을 폐기하십시오. 대신 이유가 있을 때(유출·의심) 바꾸십시오. (H.1)
- 길고 고유한 비밀번호를 쓰십시오. 복잡함보다 길이와 고유성이 중요합니다. 흔한 목록에 없는 것으로. (H.2)
- 비밀번호를 재사용하지 마십시오. 비밀번호 관리 도구로 각 서비스마다 고유한 비밀번호를 쓰십시오. (H.3)
- 모든 중요한 계정에 2채널 인증을 적용하십시오. 특히 이메일, 비밀번호 관리 도구, 금융, 업무 시스템. (H.4)
- 피싱에 강한 2채널 방식을 우선하십시오. 가능하면 하드웨어 보안 키를. (H.4, 7장)
- 백엔드·API 연결에 IP 화이트리스트를 적용하십시오. 허용된 출처만 받고 나머지를 거부하십시오. (H.5)
- 비밀번호 하나에 의존하지 않는 구조를 만드십시오. 유출을 가정하고 그래도 안전하게. (H.6, 원칙 2)
관련 장: 3장(피싱), 7장(공개키·하드웨어 키·접근 제한), 11장(자격 증명 스터핑), 12장(기본 거부), 보너스 2(이메일 계정 보호), 보너스 4(Zero Trust).