대문자와 숫자, 특수문자를 하나씩 넣었다고 안전한 비밀번호가 완성되는 것은 아닙니다. 익숙한 단어 끝에 느낌표와 올해 연도를 붙이는 패턴은 사람이 기억하기 쉬운 만큼 공격자도 먼저 시험할 수 있습니다. 비밀번호의 강도를 이해하려면 길이뿐 아니라 얼마나 예측하기 어려운 방식으로 선택됐는지, 다른 서비스에서 재사용했는지, 서버가 어떻게 저장하는지를 함께 봐야 합니다.
길이는 후보 수를 곱해서 늘립니다
각 자리에서 26개의 영문 소문자를 독립적으로 똑같은 확률로 고른다고 가정해 봅시다. 길이가 8이면 가능한 문자열 수는 26의 8제곱인 208,827,064,576개입니다. 길이가 12이면 26의 12제곱인 95,428,956,661,682,176개입니다. 네 글자를 더했을 뿐이지만 후보는 26의 4제곱인 456,976배로 늘어납니다. 단, 이 계산은 사람이 좋아하는 단어나 규칙이 아니라 무작위 선택이라는 조건에서 성립합니다.
문자 종류를 늘리는 것도 후보 공간을 넓힐 수 있습니다. 그러나 사용자가 반드시 첫 글자만 대문자로 만들고 마지막에 느낌표를 붙인다면 실제 선택은 모든 가능한 조합에 고르게 퍼지지 않습니다. 공격자는 무작위 문자열을 처음부터 끝까지 차례로만 시도할 필요가 없습니다. 흔한 비밀번호와 유출된 목록, 사람의 변형 습관처럼 가능성이 높은 후보부터 시험할 수 있습니다. 눈에 복잡해 보이는 모양과 추측하기 어려운 선택은 다릅니다.
정보량을 비트로 표현할 때 무작위 후보가 N개라면 log₂N으로 나타낼 수 있습니다. 앞의 소문자 12자리 가정은 12×log₂26으로 약 56.4비트입니다. 하지만 실제 비밀번호를 보고 글자 수만 곱해 이 수치를 부여하면 안 됩니다. 유명한 문장이나 이름의 조합은 같은 길이의 무작위 문자열보다 훨씬 먼저 추측될 수 있습니다. 계산식의 입력은 보이는 문자 종류가 아니라 생성 과정의 선택 가능성입니다.
온라인 로그인과 유출된 해시 공격은 조건이 다릅니다
로그인 화면에서 비밀번호를 시도하는 공격은 서비스의 시도 제한과 추가 인증, 이상 탐지에 영향을 받습니다. 반면 데이터베이스에서 비밀번호 해시가 유출되면 공격자는 자신의 장비에서 후보를 계산해 비교할 수 있습니다. 이런 오프라인 추측에는 웹사이트의 로그인 횟수 제한이 그대로 적용되지 않습니다. 같은 비밀번호라도 어떤 공격 상황인지에 따라 시험할 수 있는 속도와 방어 수단이 달라집니다.
인터넷에서 비밀번호를 깨는 데 몇 초 또는 몇백 년이 걸린다는 표를 볼 때는 전제부터 확인해야 합니다. 해시 알고리즘과 비용 설정, 공격 장비, 후보 생성 방식이 빠져 있다면 개인의 안전 시간을 나타내는 값으로 쓰기 어렵습니다. 온라인 시도 제한을 가정한 계산과 매우 빠른 해시를 오프라인으로 시험하는 계산을 섞으면 큰 오해가 생깁니다. 특정 문자열을 넣었다고 정확한 유출 저항 시간이 측정되는 것도 아닙니다.
서버는 원문 대신 검증용 값을 저장해야 합니다
서비스가 비밀번호를 원문으로 저장하면 데이터 유출 때 곧바로 비밀번호가 드러날 수 있습니다. 일반적인 안전한 설계는 적절한 비밀번호 해시 함수를 이용해 검증용 값을 저장하고, 로그인 때 입력한 후보를 같은 방식으로 처리해 비교하는 것입니다. 해시는 원문으로 되돌리는 복호화 키를 사용하는 암호화와 다릅니다. 다만 되돌릴 수 없다는 표현이 추측과 비교도 불가능하다는 뜻은 아닙니다.
공격자는 가능한 비밀번호를 하나 골라 해시를 계산한 뒤 유출된 값과 일치하는지 시험할 수 있습니다. 따라서 비밀번호가 흔하면 해시로 저장했더라도 빠르게 후보가 맞을 수 있습니다. 해시가 있으면 무조건 안전하다는 결론도, 해시가 유출됐으니 원문이 이미 모두 밝혀졌다는 결론도 과장입니다. 비밀번호의 선택과 서버의 저장 방식이 함께 결과에 영향을 줍니다.
OWASP의 비밀번호 저장 지침은 Argon2id 같은 비밀번호 전용 해시 방식과 적절한 비용 설정을 안내합니다. 일반 데이터의 빠른 해시 계산에 적합한 함수를 그대로 한 번 적용하는 것과 목적이 다릅니다. 비밀번호 검증에는 공격자가 후보를 대량 시험하는 비용을 높이도록 시간과 메모리를 사용하게 하는 설계가 필요합니다. 구현자는 검증된 라이브러리와 최신 지침을 따라야 합니다.
솔트는 같은 비밀번호의 해시가 같아지는 것을 줄입니다
솔트는 비밀번호마다 별도로 생성해 해시 계산에 넣는 값입니다. 두 사람이 같은 비밀번호를 사용해도 서로 다른 솔트로 계산하면 저장된 값이 달라집니다. 공격자가 미리 계산해 둔 하나의 표를 모든 계정에 똑같이 적용하기 어렵게 하는 역할도 있습니다. 솔트는 보통 해시와 함께 저장할 수 있으며 비밀번호처럼 사용자만 아는 비밀이어야 하는 것은 아닙니다.
솔트가 있다고 약한 비밀번호가 강한 무작위 문자열로 바뀌는 것은 아닙니다. 공격자가 솔트와 해시를 얻었다면 특정 계정에 대해 흔한 후보를 시험할 수 있습니다. 솔트는 여러 계정을 한꺼번에 공략하는 계산의 재사용을 어렵게 하지만, 각 후보의 추측 가능성을 없애지는 않습니다. 그래서 솔트와 비용이 적절한 해시, 긴 고유 비밀번호를 함께 사용하는 것입니다.
| 요소 | 줄이는 위험 | 해결하지 못하는 문제 |
|---|---|---|
| 긴 무작위 비밀번호 | 후보 추측 가능성 | 피싱 사이트에 직접 입력하는 행동 |
| 서비스별 다른 비밀번호 | 다른 사이트 유출의 연쇄 피해 | 현재 기기의 악성 프로그램 |
| 솔트와 비밀번호 전용 해시 | 유출 뒤 대량 추측의 효율 | 너무 흔한 비밀번호의 모든 위험 |
| 추가 인증 | 비밀번호만으로 계정 탈취 | 모든 종류의 실시간 피싱과 세션 탈취 |
최신 지침은 복잡한 모양보다 길이와 차단 목록을 봅니다
미국 NIST의 SP 800-63B-4는 단독 인증 요소로 쓰는 비밀번호에 최소 15글자를 요구하고, 다중 요소 인증의 일부인 경우에는 최소 8글자를 허용할 수 있도록 구분합니다. 이는 해당 지침의 적용 대상 시스템에 대한 기준이며 모든 서비스의 실제 정책이 같다는 뜻은 아닙니다. 또한 대소문자와 숫자 등을 반드시 섞게 하는 추가 조합 규칙을 부과하지 말도록 합니다. NIST 지침의 조건을 함께 읽어야 합니다.
여기서 15글자가 모든 상황의 안전과 위험을 가르는 마법의 선이라는 해석은 피해야 합니다. 긴 문자열이라도 널리 알려진 문장이면 쉽게 추측될 수 있고, 무작위로 만든 더 긴 고유 비밀번호는 후보 공간을 더 넓힐 수 있습니다. 지침은 유출되거나 흔한 비밀번호를 막는 검사와 시도 제한 같은 다른 보호도 함께 다룹니다. 숫자 하나만 떼어 외우기보다 전체 설계의 일부로 이해하는 것이 좋습니다.
정기적으로 끝자리 숫자만 바꾸는 습관도 좋은 해결책이 아닙니다. NIST는 임의의 주기적 변경을 강제하지 않도록 하며, 침해 증거가 있을 때 변경하도록 구분합니다. 현재 유출이 확인됐거나 서비스가 변경을 요구하는 상황까지 비밀번호를 바꾸지 말라는 뜻은 아닙니다. 변경이 필요할 때는 기존 비밀번호의 간단한 변형보다 새로운 고유 값을 선택하는 편이 좋습니다.
서비스마다 다른 비밀번호가 중요합니다
공격자가 한 사이트에서 유출된 아이디와 비밀번호를 다른 서비스에 대입하는 방식은 복잡한 비밀번호에도 통할 수 있습니다. 같은 비밀번호를 재사용했다면 한 곳의 문제가 여러 계정으로 이어지기 때문입니다. 길이를 늘렸다는 사실이 재사용 위험을 없애지는 않습니다. 특히 이메일은 다른 계정의 복구 경로로 연결될 수 있어 고유한 비밀번호와 추가 보호를 적용할 필요가 있습니다.
모든 사이트의 긴 비밀번호를 사람이 외우기는 어렵습니다. 비밀번호 관리자는 고유한 값을 생성하고 저장하는 데 도움이 됩니다. CISA의 관리자 활용 안내는 기억 부담을 줄이는 방법을 설명합니다. 관리자의 기본 계정과 복구 수단은 특히 잘 보호해야 하며, 잠금과 업데이트 설정도 확인하는 것이 좋습니다.
직접 기억해야 하는 비밀번호라면 서로 무관한 단어를 충분히 무작위로 고른 암호문구를 고려할 수 있습니다. 좋아하는 명언이나 노래 가사를 그대로 쓰는 것은 길어도 무작위 선택이 아닙니다. 생성 규칙을 설명하는 예제에 나온 문구를 그대로 실제 비밀번호로 쓰지도 않아야 합니다. 공개된 예시는 이미 공격자가 알 수 있는 후보입니다. 자신의 값을 공개 입력창이나 확인되지 않은 강도 검사 사이트에 제출하는 것도 피하는 편이 좋습니다.
비밀번호 밖의 보호도 함께 사용합니다
추가 인증은 비밀번호만 유출됐을 때 계정을 지키는 데 도움이 됩니다. 다만 문자나 인증 앱의 코드를 사기 사이트에 직접 입력하면 실시간 피싱에 악용될 수 있습니다. 서비스가 지원하는 패스키 등 피싱 저항성이 있는 방식도 확인할 수 있습니다. 어떤 인증이든 복구 경로가 약하면 문제가 남을 수 있으므로 복구 이메일과 저장된 복구 코드도 관리해야 합니다.
비밀번호의 강도는 겉모양을 복잡하게 꾸미는 문제가 아닙니다. 예측하기 어려운 생성 방식과 충분한 길이, 서비스별 분리, 안전한 저장과 인증 절차가 함께 필요합니다. 사용자는 고유한 값을 만들고 관리하는 데 집중하고, 서비스 운영자는 적절한 해시와 시도 제한을 구현해야 합니다. 각자의 역할을 나눠 이해하면 길이 하나나 특수문자 하나에 안전을 과도하게 기대하지 않을 수 있습니다.