비밀번호

1. 개요#

비밀번호(영어: password)는 특정 계정, 시스템, 파일, 장치, 서비스 등에 접근하려는 사용자가 정당한 권한을 가지고 있음을 증명하기 위해 입력하는 문자열이다. 더 넓은 의미에서는 사람이 기억하거나 별도로 보관하고 있다가 인증 과정에서 제시하는 기억 기반 인증 정보를 가리킨다.

쉽게 말해, 비밀번호는 "이 계정의 주인이 나임을 증명하기 위해 내가 알고 있어야 하는 비밀 문장"이다. 현대의 디지털 환경에서는 운영체제 로그인, 이메일, 인터넷 뱅킹, SNS, 게임 계정, 클라우드 저장소, 사내 업무 시스템, 와이파이, 압축 파일, 암호화 지갑 등 거의 모든 곳에서 사용된다.

문제는 비밀번호가 너무 흔하게 쓰인다는 점이다. 사람이 기억해야 하는 계정은 점점 늘어나는데, 사람의 기억력은 그대로다. 그 결과 많은 사용자가 짧고 단순한 비밀번호를 쓰거나, 여러 사이트에서 같은 비밀번호를 재사용하거나, 비밀번호를 메모장·카카오톡 나에게 보내기·이메일 임시보관함 등에 저장하는 식으로 편의성을 택한다. 그리고 공격자는 바로 그 지점을 노린다.

비밀번호는 매우 오래된 인증 방식이지만, 아직도 가장 널리 쓰이는 인증 방식이다. 그래서 "비밀번호는 낡았다"는 말과 "비밀번호 관리는 여전히 중요하다"는 말은 동시에 참이다. 패스키, 생체 인증, 보안 키 같은 대체 수단이 보급되고 있지만, 현실의 수많은 서비스는 여전히 비밀번호를 기본 인증 수단으로 사용한다. 즉, 비밀번호는 당장 사라지지는 않을 것이며, 그렇기 때문에 제대로 이해하고 써야 한다.

2. 명칭#

한국어에서는 보통 비밀번호라고 부른다. 문맥에 따라 다음 표현도 사용된다.

표현	의미	비고
비밀번호	가장 일반적인 표현	웹사이트, 앱, 기기 잠금 등에서 사용
암호	비밀번호와 비슷하게 쓰이나, 암호학의 암호와 혼동될 수 있음	일상에서는 "암호를 입력하세요"라고도 많이 표현
패스워드	영어 password를 그대로 읽은 표현	기술 문서나 오래된 UI에서 자주 보임
패스코드	숫자 위주의 짧은 잠금 코드	스마트폰 잠금, 2차 인증 코드 등에서 사용
PIN	보통 숫자 기반 개인 식별 번호	카드, 스마트폰, 윈도우 로그인 등에서 사용
패스프레이즈	여러 단어로 이루어진 긴 비밀번호	기억하기 쉽고 길게 만들 수 있음

엄밀히 말하면 PIN, 패스프레이즈, 잠금 해제 코드, 계정 비밀번호는 서로 다른 맥락에서 쓰일 수 있다. 그러나 사용자가 "내가 알고 있어야 하는 비밀값"이라는 점에서는 같은 계열에 속한다.

3. 특징#

비밀번호의 핵심 특징은 다음과 같다.

• 비밀성: 타인에게 알려지면 안 된다.
• 기억 가능성: 사용자가 입력할 수 있어야 한다.
• 검증 가능성: 시스템은 사용자가 입력한 값이 맞는지 확인할 수 있어야 한다.
• 변경 가능성: 유출되었거나 추측 가능성이 있으면 바꿀 수 있어야 한다.
• 재사용 위험성: 같은 비밀번호를 여러 곳에서 쓰면 한 곳의 유출이 다른 곳의 침해로 이어진다.
• 인간 의존성: 사용자의 기억, 습관, 주의력에 크게 의존한다.

비밀번호는 본질적으로 공유 비밀이다. 사용자와 서비스가 같은 비밀값을 기준으로 인증한다. 물론 제대로 된 서비스는 비밀번호 원문을 저장하지 않고, 해시 처리된 값만 저장해야 한다. 그러나 사용자가 입력하는 과정에서는 여전히 비밀값이 서비스에 전달된다. 이 점에서 비밀번호는 피싱, 키로깅, 데이터베이스 유출, 재사용 공격에 취약하다.

4. 역사#

컴퓨터 분야에서 비밀번호는 초기 시분할 시스템과 함께 등장했다. 여러 사용자가 하나의 대형 컴퓨터를 함께 사용하던 시절, 각 사용자의 파일과 작업을 구분하고 보호하기 위해 로그인과 비밀번호가 필요해졌다.

대표적으로 MIT의 Compatible Time-Sharing System, 줄여서 CTSS는 컴퓨터 로그인에 비밀번호를 도입한 초기 사례로 알려져 있다. 당시의 비밀번호는 오늘날처럼 수십 개 사이트를 보호하기 위한 것이 아니라, 한 컴퓨터를 여러 사용자가 나누어 쓰는 환경에서 개인 파일과 사용 시간을 구분하기 위한 장치에 가까웠다.

이후 유닉스 계열 시스템에서는 비밀번호를 평문으로 저장하지 않고 해시 형태로 저장하는 방식이 도입되었다. 이는 비밀번호 원문을 그대로 저장했을 때 발생하는 치명적인 위험을 줄이기 위한 발전이었다. 다만 초기의 해시 방식은 오늘날 기준으로는 충분히 강력하지 않으며, 현대적인 시스템에서는 Argon2id, bcrypt, PBKDF2 같은 느린 비밀번호 해싱 알고리즘을 사용해야 한다.

인터넷이 대중화된 뒤에는 상황이 크게 바뀌었다. 사용자는 더 이상 한두 개의 시스템에만 비밀번호를 쓰지 않게 되었다. 이메일, 포털, 쇼핑몰, 은행, 게임, 커뮤니티, 회사 시스템, 클라우드, 모바일 앱마다 비밀번호가 필요해졌다. 이 시점부터 비밀번호 문제는 단순한 기술 문제가 아니라 인간의 기억력과 습관을 전제로 하는 보안 문제가 되었다.

5. 작동 원리#

가장 단순한 비밀번호 인증 절차는 다음과 같다.

1. 사용자가 아이디와 비밀번호를 입력한다.
2. 서비스는 입력된 아이디에 해당하는 계정을 찾는다.
3. 서비스는 입력된 비밀번호를 내부 방식으로 처리한다.
4. 저장된 값과 비교한다.
5. 일치하면 로그인에 성공하고, 일치하지 않으면 실패한다.

그러나 실제 보안 시스템에서는 비밀번호 원문을 그대로 저장하거나 비교하면 안 된다. 안전한 시스템은 대체로 다음과 같은 방식으로 동작한다.

1. 사용자가 비밀번호를 설정한다.
2. 서버는 비밀번호에 계정별 무작위 값인 솔트를 붙인다.
3. 서버는 Argon2id, bcrypt, PBKDF2 같은 비밀번호 해싱 알고리즘으로 해시를 만든다.
4. 서버는 비밀번호 원문이 아니라 해시 결과와 솔트, 알고리즘 설정값을 저장한다.
5. 사용자가 로그인할 때 입력한 비밀번호에 같은 절차를 적용한다.
6. 새로 계산한 해시와 저장된 해시가 일치하면 인증에 성공한다.

이때 핵심은 비밀번호 원문을 저장하지 않는 것이다. 비밀번호 원문을 저장한 서비스는 데이터베이스가 유출되는 순간 사용자 비밀번호 전체를 공격자에게 넘겨주는 것이나 다름없다. "관리자가 비밀번호를 알려줄 수 있다"는 서비스는 편리해 보일 수 있으나, 보안 관점에서는 매우 위험한 설계일 가능성이 높다. 정상적인 서비스라면 관리자가 사용자의 비밀번호 원문을 알 수 없어야 한다.

6. 비밀번호의 강도#

비밀번호의 강도는 공격자가 해당 비밀번호를 맞히기 얼마나 어려운지에 따라 결정된다. 흔히 특수문자, 대문자, 숫자가 많으면 강한 비밀번호라고 생각하지만, 현대적인 기준에서는 길이, 무작위성, 고유성, 유출 여부가 더 중요하다.

6.1 길이#

비밀번호는 길수록 일반적으로 강해진다. 가능한 경우 최소 12자 이상, 비밀번호만으로 로그인하는 중요한 계정은 15자 이상을 권장하는 기준이 널리 쓰인다. NIST SP 800-63B 최신판은 단일 인증 요소로 쓰이는 비밀번호에 대해 최소 15자를 요구하고, 다중 인증과 함께 쓰이는 비밀번호는 최소 8자를 요구한다.

중요한 점은 "짧고 복잡한 비밀번호"보다 "길고 예측하기 어려운 비밀번호"가 더 낫다는 것이다. 예를 들어 다음과 같은 비밀번호는 겉보기에는 복잡해 보여도 실제로는 약하다.

• P@ssw0rd!
• Qwer1234!
• Summer2026!
• CompanyName2026!
• 이름+생일+특수문자 조합

이런 비밀번호는 공격자가 자주 시도하는 패턴에 가깝다. 대문자 하나, 숫자 몇 개, 느낌표 하나를 붙이는 방식은 이미 너무 흔하다. 공격자는 이런 습관을 알고 있다.

6.2 무작위성#

무작위성은 비밀번호가 예측 가능한 규칙을 따르지 않는 정도를 말한다. 사람이 직접 만든 비밀번호는 대개 자신도 모르게 패턴을 따른다. 좋아하는 단어, 생일, 닉네임, 키보드 배열, 서비스 이름, 현재 연도, 느낌표 같은 요소가 들어간다.

반면 비밀번호 관리자가 생성한 무작위 비밀번호는 사람이 떠올리기 어려운 조합으로 만들어진다. 예를 들어 다음과 같은 형태다.

• 24자 이상의 무작위 문자열
• 대문자, 소문자, 숫자, 기호가 섞인 난수 기반 문자열
• 서비스마다 완전히 다른 값

무작위 비밀번호는 외우기 어렵지만, 비밀번호 관리자를 사용하면 외울 필요가 없다. 이것이 현대적인 비밀번호 관리의 핵심이다.

6.3 고유성#

비밀번호 보안에서 가장 치명적인 습관 중 하나는 재사용이다. 아무리 강한 비밀번호라도 여러 사이트에서 같은 값을 쓰면 위험하다. 한 사이트가 털리면 공격자는 그 아이디와 비밀번호 조합을 다른 사이트에도 넣어 본다. 이것을 크리덴셜 스터핑이라고 한다.

예를 들어 A 쇼핑몰에서 사용한 이메일과 비밀번호가 유출되었다고 하자. 공격자는 같은 조합으로 이메일, SNS, 게임, 클라우드, 은행, 커뮤니티 로그인을 시도한다. 사용자가 같은 비밀번호를 재사용했다면 피해는 연쇄적으로 확대된다.

따라서 중요한 원칙은 간단하다.

• 계정마다 다른 비밀번호를 쓴다.
• 특히 이메일 계정, 금융 계정, 클라우드 계정, 개발자 계정은 절대 재사용하지 않는다.
• 기억하기 어렵다면 비밀번호 관리자를 쓴다.

6.4 유출 여부#

아무리 길고 복잡한 비밀번호라도 이미 유출된 적이 있다면 사용하면 안 된다. 공격자는 과거 유출 데이터베이스를 바탕으로 로그인 시도를 자동화한다. NIST는 서비스가 새 비밀번호를 설정할 때 흔한 비밀번호, 예상 가능한 비밀번호, 이미 유출된 비밀번호 목록과 비교해 차단할 것을 요구한다.

즉, "내 비밀번호는 복잡하니까 괜찮다"가 아니라 "이미 유출된 적이 없는가"도 중요하다. 특히 유명한 약한 비밀번호에 숫자나 특수문자만 조금 붙인 형태는 피해야 한다.

7. 좋은 비밀번호의 조건#

좋은 비밀번호는 다음 조건을 만족한다.

조건	설명
길다	짧은 비밀번호보다 추측과 대입 공격에 강하다.
예측하기 어렵다	이름, 생일, 전화번호, 닉네임, 서비스명, 키보드 패턴을 쓰지 않는다.
계정마다 다르다	한 사이트의 유출이 다른 사이트로 번지지 않게 한다.
유출된 적이 없다	과거 유출 목록에 있는 비밀번호는 쓰지 않는다.
관리 가능하다	사람이 무리해서 외우기보다 비밀번호 관리자를 활용한다.
복구 수단도 안전하다	이메일, 휴대폰 번호, 보안 질문이 약하면 비밀번호가 강해도 뚫릴 수 있다.

현실적인 권장 방식은 다음과 같다.

• 비밀번호 관리자를 사용한다.
• 각 계정마다 16자 이상 또는 20자 이상의 무작위 비밀번호를 생성한다.
• 이메일, 금융, 클라우드, 개발자 계정은 특히 길게 설정한다.
• 가능한 모든 중요한 계정에 다중 인증을 켠다.
• 패스키를 지원하는 서비스에서는 패스키 사용을 검토한다.

8. 패스프레이즈#

패스프레이즈(영어: passphrase)는 여러 단어로 이루어진 긴 비밀번호를 말한다. 예를 들어 의미 없는 여러 단어를 조합하여 긴 문자열을 만드는 방식이다.

패스프레이즈의 장점은 길이를 쉽게 늘릴 수 있다는 점이다. 사람이 완전히 무작위인 24자 문자열을 외우기는 어렵지만, 여러 단어로 이루어진 문장은 비교적 기억하기 쉽다.

다만 패스프레이즈도 주의해야 한다. 유명한 문장, 노래 가사, 애니메이션 대사, 성경 구절, 명언, 인터넷 밈, 자기소개 문장처럼 이미 공개되어 있거나 추측 가능한 문장은 피해야 한다. "나는비밀번호를잊지않는다" 같은 문장은 길어 보이지만, 사람이 만든 문장이라 예측 가능성이 생긴다.

좋은 패스프레이즈는 다음 조건을 만족한다.

• 단어 선택이 무작위에 가깝다.
• 개인 정보와 관련이 없다.
• 유명 문구가 아니다.
• 충분히 길다.
• 서비스마다 다르다.

패스프레이즈는 비밀번호 관리자를 쓰기 어려운 환경에서 특히 유용하다. 예를 들어 비밀번호 관리자 자체의 마스터 비밀번호, 운영체제 로그인 비밀번호, 디스크 암호화 비밀번호처럼 직접 기억해야 하는 경우에 적합하다.

9. 나쁜 비밀번호의 예#

다음 유형은 피해야 한다.

유형	예시	문제점
너무 짧은 비밀번호	123456, 000000, 111111	자동화된 추측 공격에 매우 취약하다.
키보드 배열	qwerty, asdf1234, qazwsx	공격자가 자주 시도하는 패턴이다.
흔한 단어	password, admin, iloveyou	유출 목록과 사전 공격에 자주 포함된다.
개인정보	이름+생일, 전화번호, 학번	주변인이나 유출된 개인정보로 추측 가능하다.
서비스명 포함	naver2026!, google123!	공격자가 서비스명 기반 변형을 시도할 수 있다.
연도만 바꾸는 방식	Password2024!, Password2025!, Password2026!	주기적 변경의 대표적인 실패 사례다.
같은 비밀번호 재사용	모든 사이트에 같은 비밀번호 사용	한 곳이 털리면 다른 곳도 위험해진다.

특히 "대문자 하나, 소문자 몇 개, 숫자 몇 개, 느낌표 하나" 형식은 더 이상 특별하지 않다. 많은 사용자가 같은 방식으로 비밀번호를 만들기 때문에 공격자도 그 패턴을 우선적으로 시도한다.

10. 공격 방식#

비밀번호를 노리는 공격은 다양하다. 공격자는 반드시 영화처럼 멋진 화면을 띄우고 해킹하지 않는다. 실제로는 유출된 목록을 자동으로 대입하거나, 사용자가 스스로 입력하도록 속이거나, 이미 감염된 기기에서 입력값을 훔치는 식의 현실적인 공격이 많다.

10.1 무차별 대입 공격#

무차별 대입 공격(영어: brute-force attack)은 가능한 모든 조합을 하나씩 시도하는 방식이다. 이론적으로는 모든 비밀번호를 언젠가 맞힐 수 있지만, 길고 복잡한 비밀번호는 가능한 조합이 너무 많아 현실적인 시간 안에 맞히기 어렵다.

다만 실제 공격은 순수한 무차별 대입만으로 이루어지지 않는다. 공격자는 흔한 비밀번호, 사전 단어, 유출된 비밀번호, 사람들의 변형 습관을 먼저 시도한다. 그래서 "문자 종류가 많다"보다 "예측 가능한 패턴을 피한다"가 중요하다.

10.2 사전 공격#

사전 공격(영어: dictionary attack)은 사전에 있는 단어, 흔한 문구, 자주 쓰이는 비밀번호 목록을 이용해 시도하는 공격이다. password, qwerty, dragon, football 같은 흔한 단어는 물론, 한국어 이름, 아이돌 이름, 애니메이션 캐릭터 이름, 회사명, 지역명, 학교명도 공격 목록에 들어갈 수 있다.

사전 공격은 단어를 그대로 넣는 것에서 끝나지 않는다. 공격자는 다음과 같은 변형도 시도한다.

• 단어 뒤에 숫자 붙이기
• 첫 글자만 대문자로 바꾸기
• a를 @로, o를 0으로 바꾸기
• 끝에 느낌표 붙이기
• 현재 연도 붙이기
• 서비스 이름과 단어를 조합하기

따라서 "단어 하나를 살짝 변형한 비밀번호"는 안전하지 않다.

10.3 크리덴셜 스터핑#

크리덴셜 스터핑(영어: credential stuffing)은 이미 유출된 아이디와 비밀번호 조합을 다른 서비스에 자동으로 넣어 보는 공격이다. 비밀번호 재사용이 위험한 가장 큰 이유다.

예를 들어 어떤 커뮤니티에서 이메일과 비밀번호가 유출되면, 공격자는 그 조합으로 쇼핑몰, 포털, 게임, 클라우드, 은행 등에 로그인을 시도한다. 사용자가 같은 비밀번호를 여러 곳에서 썼다면 공격은 성공한다.

이 공격을 막는 가장 좋은 방법은 다음과 같다.

• 서비스마다 다른 비밀번호 사용
• 비밀번호 관리자 사용
• 다중 인증 활성화
• 로그인 알림 확인
• 유출 의심 시 즉시 변경

10.4 피싱#

피싱(영어: phishing)은 사용자를 속여 가짜 로그인 페이지에 비밀번호를 입력하게 만드는 공격이다. 비밀번호가 아무리 길고 복잡해도 사용자가 가짜 사이트에 직접 입력하면 공격자는 그대로 가져간다.

피싱은 다음 형태로 나타날 수 있다.

• 은행을 사칭한 문자
• 택배 배송 조회를 가장한 링크
• 계정 정지를 알리는 이메일
• 회사 보안 점검을 가장한 로그인 페이지
• 게임 아이템 지급을 미끼로 한 가짜 사이트
• 클라우드 문서 공유 알림을 가장한 로그인 페이지

피싱에 강해지려면 주소창의 도메인을 확인하고, 의심스러운 링크를 누르지 않으며, 중요한 계정에는 패스키나 보안 키 같은 피싱 저항 인증 수단을 쓰는 것이 좋다. NIST는 비밀번호가 피싱 저항 인증 수단이 아니라고 명시한다.

10.5 키로깅#

키로깅(영어: keylogging)은 사용자가 키보드로 입력하는 내용을 훔치는 공격이다. 악성코드가 설치된 PC나 스마트폰에서는 사용자가 아무리 강한 비밀번호를 입력해도 그대로 탈취될 수 있다.

공용 PC, PC방, 감염된 기기, 출처 불명의 프로그램을 실행한 환경에서는 중요한 계정에 로그인하지 않는 것이 좋다. 특히 이메일, 금융, 클라우드, 개발자 계정은 신뢰할 수 없는 기기에서 로그인하지 않는 편이 안전하다.

10.6 사회공학#

사회공학(영어: social engineering)은 기술적 취약점보다 사람의 심리와 실수를 이용하는 공격이다. 공격자는 사용자를 속여 비밀번호를 말하게 하거나, 복구 코드를 넘기게 하거나, 원격 제어 프로그램을 설치하게 만들 수 있다.

예를 들어 다음과 같은 말은 의심해야 한다.

• "보안 점검을 위해 비밀번호를 알려 달라."
• "본인 확인을 위해 인증번호를 불러 달라."
• "계정이 정지되었으니 아래 링크에서 로그인하라."
• "원격으로 도와줄 테니 프로그램을 설치하라."
• "회사 관리자이니 임시 비밀번호를 알려 달라."

정상적인 관리자, 은행, 공공기관, 보안 담당자는 사용자의 비밀번호 원문을 요구하지 않는다.

10.7 데이터베이스 유출#

서비스 자체가 해킹되어 회원 정보 데이터베이스가 유출되는 경우도 있다. 이때 서비스가 비밀번호를 평문으로 저장했다면 피해는 치명적이다. 해시 처리를 했더라도 약한 알고리즘을 썼거나 솔트가 없거나 비용 인자가 낮으면 공격자가 오프라인에서 대량으로 추측할 수 있다.

따라서 사용자는 서비스마다 다른 비밀번호를 사용해야 하고, 개발자는 비밀번호를 안전하게 저장해야 한다.

11. 비밀번호 관리자#

비밀번호 관리자(영어: password manager)는 여러 계정의 비밀번호를 암호화하여 저장하고, 필요할 때 자동 입력하거나 생성해 주는 도구다. 현대적인 비밀번호 관리에서 사실상 필수 도구에 가깝다.

CISA는 길고 무작위이며 고유한 비밀번호를 비밀번호 관리자로 생성하고, 다중 인증을 켤 것을 권고한다. NIST 역시 비밀번호 관리자와 자동 입력, 붙여넣기 사용을 허용해야 한다고 설명한다.

11.1 장점#

비밀번호 관리자의 장점은 다음과 같다.

• 계정마다 다른 비밀번호를 쉽게 만들 수 있다.
• 20자 이상의 무작위 비밀번호를 현실적으로 사용할 수 있다.
• 사용자가 모든 비밀번호를 외울 필요가 없다.
• 피싱 사이트에서 자동 입력이 되지 않아 이상 징후를 알아차릴 수 있다.
• 유출된 비밀번호나 재사용 비밀번호를 점검할 수 있다.
• 가족, 팀, 회사 단위로 안전하게 공유할 수 있는 기능을 제공하기도 한다.

11.2 단점과 주의점#

비밀번호 관리자는 강력한 도구지만, 만능은 아니다.

• 마스터 비밀번호가 약하면 위험하다.
• 마스터 비밀번호를 잊으면 복구가 어려울 수 있다.
• 기기가 악성코드에 감염되면 위험할 수 있다.
• 동기화 계정이 탈취되면 위험하다.
• 신뢰할 수 없는 비밀번호 관리자를 쓰면 오히려 위험하다.

따라서 비밀번호 관리자를 사용할 때는 다음을 지켜야 한다.

• 마스터 비밀번호는 길고 강한 패스프레이즈로 만든다.
• 비밀번호 관리자 계정에 다중 인증을 켠다.
• 복구 코드를 안전한 오프라인 장소에 보관한다.
• 운영체제와 브라우저를 최신 상태로 유지한다.
• 출처가 명확한 관리자를 사용한다.
• 공용 기기에서는 비밀번호 관리자에 로그인하지 않는다.

11.3 브라우저 내장 비밀번호 관리자#

크롬, 엣지, 사파리, 파이어폭스 같은 브라우저는 자체 비밀번호 저장 기능을 제공한다. 운영체제와 연동되는 경우도 많아 편리하다. 일반 사용자에게는 브라우저 내장 비밀번호 관리자도 비밀번호 재사용보다 훨씬 낫다.

다만 전문 비밀번호 관리자는 다음과 같은 추가 장점을 제공할 수 있다.

• 다양한 브라우저와 운영체제 간 일관된 동기화
• 가족·조직 공유 기능
• 보안 감사 기능
• 고급 2차 인증 지원
• 별도 보안 정책 설정
• 긴급 접근 기능

개인 사용자는 브라우저 내장 기능으로 시작해도 좋지만, 계정이 많거나 중요 계정이 많다면 전용 비밀번호 관리자를 검토할 만하다.

12. 다중 인증#

다중 인증(영어: multi-factor authentication, MFA)은 비밀번호 외에 다른 인증 요소를 추가로 요구하는 방식이다.

인증 요소는 보통 다음 세 가지로 나뉜다.

요소	의미	예시
지식 요소	사용자가 알고 있는 것	비밀번호, PIN
소유 요소	사용자가 가지고 있는 것	휴대폰, 보안 키, OTP 기기
생체 요소	사용자 신체 특성	지문, 얼굴, 홍채

비밀번호만 쓰면 지식 요소 하나에 의존한다. 다중 인증을 켜면 공격자가 비밀번호를 알아내더라도 추가 요소가 필요해진다. 그래서 계정 탈취 가능성을 크게 줄일 수 있다.

12.1 다중 인증의 종류#

대표적인 다중 인증 방식은 다음과 같다.

방식	설명	보안성
SMS 인증	문자로 인증번호를 받는 방식	없는 것보다는 낫지만 SIM 스와핑, 문자 탈취 위험이 있다.
이메일 인증	이메일로 코드를 받는 방식	이메일 계정이 털리면 함께 위험해진다.
TOTP 앱	인증 앱에서 시간 기반 코드를 생성하는 방식	일반적으로 SMS보다 안전하다.
푸시 인증	앱에서 로그인 승인 알림을 받는 방식	편리하지만 피로 공격에 주의해야 한다.
하드웨어 보안 키	USB, NFC, 블루투스 보안 키를 사용하는 방식	매우 강력하다.
패스키	공개키 기반의 비밀번호 없는 로그인 방식	피싱 저항성이 강하다.

12.2 다중 인증도 완벽하지 않다#

다중 인증은 강력하지만, 모든 공격을 막는 마법은 아니다. SMS 인증은 번호 이동 사기나 SIM 스와핑에 취약할 수 있고, 푸시 인증은 사용자가 실수로 승인할 수 있다. TOTP 코드도 실시간 피싱 사이트에 입력하면 탈취될 수 있다.

따라서 중요한 계정에는 가능하면 다음 순서를 고려한다.

1. 패스키 또는 하드웨어 보안 키
2. 인증 앱 기반 TOTP
3. 푸시 인증
4. SMS 인증
5. 이메일 인증

물론 어떤 다중 인증이든 비밀번호만 쓰는 것보다는 대체로 낫다. 다만 금융, 이메일, 클라우드, 개발자 계정처럼 중요한 계정은 피싱 저항성이 높은 방식을 우선하는 것이 좋다.

13. 패스키와 비밀번호의 관계#

패스키(영어: passkey)는 비밀번호를 대체하기 위해 만들어진 공개키 기반 인증 방식이다. 사용자는 비밀번호를 입력하는 대신 기기의 잠금 해제 방식, 예컨대 지문, 얼굴 인식, PIN 등을 이용해 로그인한다.

패스키는 일반적인 비밀번호와 달리 서버에 비밀번호 원문이나 공유 비밀을 보내지 않는다. 서비스에는 공개키가 등록되고, 사용자의 기기에는 개인키가 보관된다. 로그인할 때는 개인키로 서명하고, 서비스는 공개키로 이를 검증한다. 이 구조 때문에 패스키는 피싱과 크리덴셜 스터핑에 강하다. FIDO Alliance는 패스키가 피싱, 크리덴셜 스터핑, 원격 공격을 줄이는 데 도움이 된다고 설명한다.

다만 패스키가 보급되었다고 해서 비밀번호 관리가 곧바로 사라지는 것은 아니다. 많은 서비스가 아직 비밀번호를 요구하고, 패스키를 쓰더라도 복구용 비밀번호나 이메일 계정이 남아 있는 경우가 많다. 따라서 패스키와 비밀번호는 한동안 공존할 가능성이 높다.

14. 비밀번호 정책#

비밀번호 정책은 서비스가 사용자에게 요구하는 비밀번호 규칙이다. 과거에는 다음과 같은 정책이 흔했다.

• 최소 8자
• 대문자 포함
• 소문자 포함
• 숫자 포함
• 특수문자 포함
• 90일마다 변경
• 최근 사용한 비밀번호 재사용 금지
• 붙여넣기 금지

그러나 현대적인 보안 권고는 이런 방식의 일부를 비판한다. 특히 복잡도 강제와 주기적 변경 강제는 사용자를 괴롭히는 데 비해 보안 향상이 제한적일 수 있다. 사용자는 강제로 자주 바꾸라고 하면 Password2025!를 Password2026!으로 바꾸는 식의 예측 가능한 변경을 하기 쉽다.

NIST는 비밀번호에 대해 대문자·소문자·숫자·기호 조합 같은 추가 구성 규칙을 강제하지 말고, 주기적 변경도 요구하지 말라고 설명한다. 다만 유출 또는 침해 증거가 있으면 변경을 강제해야 한다.

14.1 좋은 비밀번호 정책#

좋은 비밀번호 정책은 다음과 같다.

항목	권장 방향
최소 길이	비밀번호 단독 인증은 15자 이상, MFA와 함께 쓰는 경우도 최소 8자 이상
최대 길이	최소 64자 이상 허용
문자 허용	공백, 기호, 가능한 경우 유니코드 허용
복잡도 규칙	대문자·숫자·특수문자 강제보다 길이와 유출 차단을 중시
유출 비밀번호 차단	흔한 비밀번호, 유출 비밀번호, 서비스명 포함 비밀번호 차단
주기적 변경	임의의 정기 변경은 강제하지 않음
붙여넣기	비밀번호 관리자 사용을 위해 허용
비밀번호 힌트	인증 전 접근 가능한 힌트는 금지
보안 질문	비밀번호 선택 과정에서 지식 기반 보안 질문 사용 지양
로그인 시도 제한	과도한 실패 시 속도 제한, 지연, 추가 검증 적용

14.2 나쁜 비밀번호 정책#

나쁜 비밀번호 정책의 예는 다음과 같다.

• 최대 12자까지만 허용한다.
• 특수문자를 일부만 허용한다.
• 공백을 허용하지 않는다.
• 붙여넣기를 막는다.
• 30일마다 무조건 바꾸게 한다.
• 비밀번호 힌트를 공개적으로 보여 준다.
• 보안 질문으로 "어머니의 성함은?" 같은 정보를 요구한다.
• 비밀번호 일부 글자만 입력하게 한다.
• 비밀번호를 평문 이메일로 보내 준다.
• 관리자가 사용자의 비밀번호를 확인할 수 있다.

특히 최대 길이가 지나치게 짧은 서비스는 문제가 있다. 사용자가 비밀번호 관리자로 만든 긴 무작위 비밀번호를 쓸 수 없게 만들기 때문이다.

15. 비밀번호 저장#

개발자와 서비스 운영자에게 가장 중요한 원칙은 다음과 같다.

비밀번호를 평문으로 저장하지 말 것.

비밀번호는 암호화해서 복호화할 수 있게 저장하는 것도 적절하지 않다. 일반적으로 비밀번호는 복호화가 아니라 검증만 가능하면 된다. 따라서 비밀번호는 느린 단방향 해싱 알고리즘으로 처리해야 한다.

OWASP는 비밀번호를 평문으로 저장하지 말고 Argon2id, bcrypt, PBKDF2 같은 강한 느린 해싱 알고리즘으로 보호해야 하며, 각 비밀번호에는 고유한 솔트를 추가해야 한다고 권고한다.

15.1 해시와 암호화의 차이#

해시와 암호화는 다르다.

구분	해시	암호화
목적	원본을 되돌리지 않고 검증	원본을 숨겼다가 필요 시 복원
복호화 가능성	일반적으로 불가능해야 함	키가 있으면 가능
비밀번호 저장에 적합한가	적합함	일반적으로 부적합
예시	Argon2id, bcrypt, PBKDF2	AES, ChaCha20 등

비밀번호 저장에는 복호화 가능한 암호화보다 단방향 해싱이 적합하다. 서비스는 사용자의 비밀번호를 다시 보여 줄 필요가 없기 때문이다. 사용자가 비밀번호를 잊으면 "찾기"가 아니라 "재설정"을 해야 한다.

15.2 솔트#

솔트(영어: salt)는 각 비밀번호마다 추가되는 무작위 값이다. 솔트의 목적은 같은 비밀번호라도 서로 다른 해시 결과가 나오게 하는 것이다.

예를 들어 두 사용자가 같은 비밀번호를 사용하더라도 솔트가 다르면 저장된 해시는 달라진다. 이는 레인보우 테이블 같은 사전 계산 공격을 어렵게 만든다.

솔트는 비밀일 필요는 없지만, 계정마다 고유하고 충분히 무작위여야 한다. 같은 솔트를 모든 사용자에게 쓰는 것은 좋지 않다.

15.3 페퍼#

페퍼(영어: pepper)는 솔트와 달리 서버 쪽에서 별도로 보관하는 비밀값이다. 데이터베이스만 유출된 경우 공격을 더 어렵게 만들기 위해 사용될 수 있다.

다만 페퍼는 운영 복잡성을 높인다. 키 관리, 회전, 백업, 장애 대응을 제대로 설계하지 않으면 오히려 문제가 생길 수 있다. 페퍼는 비밀번호 해싱을 대체하는 것이 아니라 보조 방어 수단으로 보아야 한다.

15.4 느린 해싱 알고리즘#

비밀번호 저장에는 빠른 해시 함수가 아니라 느린 해싱 알고리즘이 필요하다. SHA-256, SHA-512 같은 일반 해시 함수는 빠르기 때문에 파일 무결성 확인에는 좋지만, 비밀번호 저장에는 적합하지 않다. 공격자도 빠르게 대량 추측을 할 수 있기 때문이다.

대표적인 비밀번호 해싱 알고리즘은 다음과 같다.

알고리즘	특징	비고
Argon2id	메모리 사용량과 시간 비용을 조절할 수 있는 현대적 알고리즘	신규 시스템에서 우선 검토할 만함
bcrypt	오랫동안 검증된 알고리즘	널리 지원되지만 입력 길이 제한 등에 주의 필요
PBKDF2	오래된 표준 기반 알고리즘	규제 환경에서 쓰이기도 하나 충분한 반복 횟수 필요
scrypt	메모리 비용을 요구하는 알고리즘	일부 시스템에서 사용

중요한 것은 알고리즘 이름만이 아니다. 비용 인자, 메모리 사용량, 반복 횟수, 라이브러리 구현, 마이그레이션 정책이 함께 중요하다.

16. 개발자가 지켜야 할 원칙#

웹 서비스나 앱을 만드는 개발자는 다음 원칙을 지켜야 한다.

16.1 입력과 전송#

• 로그인 페이지는 HTTPS를 사용한다.
• 비밀번호를 URL 쿼리 문자열에 넣지 않는다.
• 로그에 비밀번호를 남기지 않는다.
• 오류 추적 도구에 비밀번호가 전송되지 않게 한다.
• 비밀번호 입력란은 적절한 자동완성 속성을 사용한다.
• 사용자가 비밀번호 관리자를 쓸 수 있게 한다.
• 붙여넣기를 막지 않는다.
• 필요하면 비밀번호 표시 버튼을 제공하되, 기본값은 숨김으로 둔다.

16.2 저장#

• 평문 저장 금지
• 단순 SHA-256 저장 금지
• 계정별 고유 솔트 사용
• Argon2id, bcrypt, PBKDF2 등 검증된 비밀번호 해싱 알고리즘 사용
• 비용 인자를 주기적으로 상향 검토
• 알고리즘과 비용 인자를 저장해 향후 마이그레이션 가능하게 설계
• 비밀번호 변경 시 기존 세션 처리 정책 마련
• 관리자도 사용자 비밀번호 원문을 볼 수 없게 설계

16.3 인증 흐름#

• 로그인 실패 횟수에 대한 속도 제한 적용
• 단순 계정 잠금만으로 서비스 거부 공격이 발생하지 않게 설계
• 크리덴셜 스터핑 탐지
• 비정상 로그인 알림
• 새 기기 로그인 알림
• 민감 작업 시 재인증 요구
• 2차 인증 설정 지원
• 패스키 지원 검토

16.4 비밀번호 재설정#

비밀번호 재설정은 로그인만큼 중요하다. 재설정 절차가 약하면 비밀번호가 아무리 강해도 소용없다.

좋은 비밀번호 재설정 정책은 다음과 같다.

• 재설정 링크는 충분히 긴 무작위 토큰을 사용한다.
• 재설정 토큰은 짧은 유효 기간을 가진다.
• 재설정 토큰은 한 번만 사용할 수 있어야 한다.
• 재설정 토큰도 안전하게 저장한다.
• 비밀번호 변경 후 사용자에게 알림을 보낸다.
• 이메일 계정 탈취를 고려해 민감 계정은 추가 검증을 요구한다.
• 보안 질문만으로 비밀번호를 재설정하지 않는다.

16.5 오류 메시지#

로그인 실패 메시지는 공격자에게 불필요한 정보를 주지 않아야 한다.

나쁜 예:

• "존재하지 않는 아이디입니다."
• "비밀번호가 틀렸습니다."
• "이 이메일은 가입되어 있습니다."

좋은 예:

• "아이디 또는 비밀번호가 올바르지 않습니다."
• "입력한 정보로 로그인할 수 없습니다."

다만 사용성도 중요하다. 무조건 모든 정보를 숨기면 사용자가 문제를 해결하기 어렵다. 보안과 사용성 사이에서 적절한 균형이 필요하다.

17. 사용자가 지켜야 할 원칙#

일반 사용자는 다음 원칙만 지켜도 대부분의 비밀번호 사고를 크게 줄일 수 있다.

1. 비밀번호 관리자를 사용한다.
2. 계정마다 다른 비밀번호를 쓴다.
3. 중요한 계정은 16자 이상 또는 관리자가 생성한 긴 무작위 비밀번호를 쓴다.
4. 이메일 계정은 최우선으로 보호한다.
5. 다중 인증을 켠다.
6. 패스키를 지원하면 사용을 검토한다.
7. 공용 PC에서 중요한 계정에 로그인하지 않는다.
8. 의심스러운 링크에서 로그인하지 않는다.
9. 유출 알림을 받으면 즉시 비밀번호를 바꾼다.
10. 복구 이메일과 전화번호도 안전하게 관리한다.

특히 이메일 계정은 모든 계정의 복구 허브가 되는 경우가 많다. 이메일이 털리면 다른 사이트의 비밀번호 재설정 링크를 공격자가 받을 수 있다. 따라서 이메일 계정은 매우 긴 고유 비밀번호와 강한 다중 인증을 적용해야 한다.

18. 상황별 권장 설정#

18.1 개인 사용자#

개인 사용자는 다음 구성을 권장한다.

• 비밀번호 관리자 사용
• 모든 계정에 고유 비밀번호 사용
• 이메일, 금융, 클라우드, SNS, 쇼핑몰 우선 점검
• 중요한 계정에 MFA 적용
• 패스키 지원 서비스에서는 패스키 등록
• 복구 코드 오프라인 보관
• 사용하지 않는 계정 삭제 또는 비밀번호 변경

18.2 학생#

학생은 학교 계정, 이메일, 클라우드, LMS, 장학금·학사 시스템, 개발자 계정 등을 주의해야 한다.

• 학교 이메일 비밀번호 재사용 금지
• 과제용 GitHub 계정 보호
• 클라우드 드라이브 공유 권한 확인
• PC방이나 공용 컴퓨터에서 자동 로그인 금지
• 졸업 후에도 학교 이메일이 복구 수단으로 남아 있는지 확인

18.3 직장인#

직장인은 개인 계정보다 회사 계정의 피해 파급력이 더 클 수 있다.

• 회사 계정과 개인 계정 비밀번호 분리
• 업무용 비밀번호를 개인 메신저에 저장하지 않기
• VPN, 메일, 그룹웨어, 클라우드 계정 MFA 적용
• 퇴사자 계정 비활성화 확인
• 공유 계정 사용 최소화
• 비밀번호 공유가 필요하면 조직용 비밀번호 관리자 사용

18.4 개발자#

개발자는 일반 사용자보다 더 큰 권한을 가진 경우가 많다. GitHub, 클라우드 콘솔, 서버 SSH, 데이터베이스, 패키지 저장소 계정이 털리면 공급망 공격으로 이어질 수 있다.

• GitHub, GitLab, npm, PyPI, Docker Hub 계정 MFA 적용
• SSH 키에 패스프레이즈 설정
• API 키를 코드 저장소에 올리지 않기
• .env 파일 관리 주의
• 비밀번호와 토큰을 로그에 남기지 않기
• 개인 프로젝트와 회사 프로젝트의 계정·키 분리
• 클라우드 루트 계정은 별도 보호
• 장기 토큰보다 짧은 수명의 토큰 사용 검토

18.5 관리자#

시스템 관리자는 사용자에게 무리한 규칙을 강제하기보다 실제 공격을 막는 정책을 설계해야 한다.

• 긴 비밀번호 허용
• 비밀번호 관리자 사용 허용
• 붙여넣기 허용
• 유출 비밀번호 차단
• MFA 적용
• 로그인 속도 제한
• 비정상 로그인 탐지
• 패스키·보안 키 지원
• 비밀번호 재설정 절차 강화
• 비밀번호 원문 접근 불가 구조 유지

19. 비밀번호 변경 시점#

비밀번호는 무조건 자주 바꾸는 것이 능사가 아니다. 다음 상황에서는 반드시 바꾸는 것이 좋다.

• 서비스에서 유출 사고가 발생했다.
• 같은 비밀번호를 다른 사이트에서도 사용했다.
• 피싱 사이트에 입력했을 가능성이 있다.
• 공용 PC나 감염 의심 기기에서 로그인했다.
• 로그인 알림에 모르는 위치나 기기가 보인다.
• 가족, 친구, 동료에게 알려 준 적이 있다.
• 퇴사, 팀 이동, 외주 종료 등으로 공유 권한이 바뀌었다.
• 비밀번호가 너무 짧거나 흔한 패턴이다.

반대로 아무 이유 없이 30일 또는 90일마다 강제로 바꾸게 하면 사용자는 예측 가능한 변형을 만들 가능성이 높다. 그래서 최신 권고는 유출이나 침해 근거가 있을 때 변경을 요구하는 방향에 가깝다.

20. 비밀번호 유출이 의심될 때#

비밀번호 유출이 의심되면 다음 순서로 대응한다.

1. 해당 계정의 비밀번호를 즉시 변경한다.
2. 같은 비밀번호를 사용한 다른 계정도 모두 변경한다.
3. 이메일 계정의 로그인 기록을 확인한다.
4. 계정 복구 이메일, 전화번호, 연결된 기기를 확인한다.
5. 알 수 없는 세션을 로그아웃한다.
6. 다중 인증을 켠다.
7. 복구 코드를 새로 발급한다.
8. 금융 계정이라면 거래 내역을 확인한다.
9. 악성코드 감염 가능성이 있으면 기기를 점검한다.
10. 중요한 자료가 있는 계정은 고객센터에 문의한다.

여기서 가장 중요한 것은 같은 비밀번호를 쓴 다른 계정까지 함께 바꾸는 것이다. 공격자는 한 계정만 노리지 않는다.

21. 보안 질문#

보안 질문은 "어머니의 성함은?", "초등학교 이름은?", "첫 반려동물의 이름은?" 같은 질문에 답하게 하는 방식이다. 과거에는 비밀번호 복구 수단으로 많이 사용되었다.

그러나 보안 질문은 문제가 많다.

• 답이 공개 정보일 수 있다.
• 가족이나 지인이 알 수 있다.
• SNS에서 추정 가능하다.
• 사용자가 잊을 수 있다.
• 표기 방식이 달라질 수 있다.
• 공격자가 사회공학으로 알아낼 수 있다.

NIST는 비밀번호 선택 과정에서 지식 기반 인증이나 보안 질문을 요구하지 말라고 설명한다. 보안 질문은 편리해 보이지만, 실제로는 약한 비밀번호 하나를 더 만드는 것과 비슷할 수 있다.

22. 공용 기기에서의 비밀번호#

공용 기기에서는 중요한 계정 로그인을 피하는 것이 좋다. 불가피하게 사용해야 한다면 다음을 지킨다.

• 자동 로그인 체크 해제
• 비밀번호 저장 거부
• 사용 후 로그아웃
• 브라우저 기록과 쿠키 삭제
• 2차 인증 알림 확인
• 로그인 후 계정의 활성 세션 확인
• 가능하면 일회성 코드나 제한된 권한의 계정 사용

PC방, 학교 공용 PC, 도서관 PC, 회사 공용 장비는 키로거, 브라우저 확장 프로그램, 세션 탈취 위험이 있을 수 있다. 특히 관리자 권한이 없는 환경에서는 사용자가 보안 상태를 완전히 확인하기 어렵다.

23. 모바일 기기와 비밀번호#

스마트폰은 비밀번호 관리의 중심이 되었다. 인증 앱, 패스키, SMS, 이메일, 비밀번호 관리자, 생체 인증이 모두 스마트폰에 몰려 있는 경우가 많다. 따라서 스마트폰 자체의 보안이 중요하다.

• 화면 잠금 설정
• 6자리 이상의 PIN 또는 강한 잠금 방식 사용
• 생체 인증 사용
• 운영체제 업데이트
• 출처 불명 APK 설치 금지
• 분실 시 원격 잠금과 초기화 설정
• 알림 내용 잠금화면 노출 제한
• SIM 스와핑 방지를 위한 통신사 보안 설정 확인

스마트폰 잠금 PIN이 너무 약하면, 비밀번호 관리자와 인증 앱까지 위험해질 수 있다. 000000, 123456, 생일, 전화번호 뒷자리 같은 값은 피해야 한다.

24. 기업 환경에서의 비밀번호#

기업 환경에서는 개인의 실수 하나가 조직 전체의 사고로 이어질 수 있다. 따라서 기업은 단순히 "비밀번호를 복잡하게 하라"고 교육하는 수준을 넘어 구조적 대책을 마련해야 한다.

24.1 권장 정책#

• SSO 도입
• MFA 의무화
• 관리자 계정 별도 관리
• 권한 최소화
• 퇴사자 계정 즉시 회수
• 공유 계정 최소화
• 조직용 비밀번호 관리자 제공
• 유출 비밀번호 탐지
• 크리덴셜 스터핑 방어
• 로그인 이상 징후 탐지
• 보안 키 또는 패스키 도입 검토
• 비밀번호 재설정 절차에 신원 확인 강화

24.2 피해야 할 정책#

• 주기적 변경만 강제하고 MFA는 없는 정책
• 모든 직원에게 같은 초기 비밀번호 지급
• 부서 공유 계정을 장기간 사용
• 엑셀 파일에 비밀번호 목록 저장
• 메신저로 비밀번호 공유
• 퇴사자 계정 방치
• 관리자 계정과 일반 계정 동일 비밀번호 사용
• 장애 대응용 공용 최고권한 계정 상시 사용

기업 보안의 핵심은 "사용자가 완벽하게 행동할 것"을 기대하지 않는 것이다. 사용자가 실수해도 피해가 제한되도록 설계해야 한다.

25. 비밀번호와 암호화#

비밀번호는 암호화와 관련이 깊지만, 같은 개념은 아니다.

비밀번호는 인증을 위한 비밀값이고, 암호화는 정보를 읽을 수 없게 변환하는 기술이다. 다만 비밀번호는 암호화 키를 보호하거나 생성하는 데 사용될 수 있다. 예를 들어 압축 파일 암호, 디스크 암호화 비밀번호, 암호화 지갑 시드 보호 비밀번호 등이 있다.

이 경우 비밀번호를 잊으면 복구가 불가능할 수 있다. 일반 웹사이트 비밀번호는 이메일로 재설정할 수 있지만, 로컬 암호화 파일이나 암호화폐 지갑은 서비스 운영자가 대신 복구해 줄 수 없는 경우가 많다.

따라서 암호화에 쓰이는 비밀번호는 다음 조건을 갖추어야 한다.

• 매우 길고 강해야 한다.
• 백업되어야 한다.
• 타인에게 노출되면 안 된다.
• 잊어버리면 어떤 일이 생기는지 이해해야 한다.
• 복구 문구와 함께 안전하게 보관해야 한다.

26. 비밀번호와 생체 인증#

지문, 얼굴, 홍채 같은 생체 인증은 비밀번호보다 편리하다. 하지만 생체 인증은 보통 비밀번호를 완전히 대체한다기보다, 기기 내부의 비밀키나 저장된 인증 정보를 사용하기 위한 잠금 해제 수단으로 쓰인다.

생체 인증의 장점은 다음과 같다.

• 입력이 빠르다.
• 어깨너머 훔쳐보기에 강하다.
• 사용자가 외울 필요가 없다.
• 패스키와 결합하면 편리하고 강력하다.

단점도 있다.

• 유출되면 바꾸기 어렵다.
• 기기 성능과 센서 품질에 영향을 받는다.
• 법적·물리적 강제 상황에 대한 논의가 있다.
• 상처, 마스크, 조명, 습기 등 환경 영향을 받을 수 있다.

그래서 생체 인증을 쓰더라도 기기의 PIN이나 패스프레이즈는 강하게 설정해야 한다. 생체 인증 실패 시 PIN으로 풀 수 있다면, 실제 보안 수준은 결국 PIN에도 의존한다.

27. 비밀번호에 대한 오해#

27.1 특수문자를 넣으면 무조건 안전하다#

아니다. "Password1!"처럼 특수문자가 있어도 흔한 패턴이면 약하다. 특수문자 자체보다 길이, 무작위성, 고유성이 중요하다.

27.2 자주 바꾸면 무조건 안전하다#

아니다. 유출이나 침해 근거가 있을 때 바꾸는 것은 중요하지만, 이유 없이 자주 바꾸게 하면 사용자가 예측 가능한 변형을 만들 가능성이 커진다.

27.3 비밀번호 관리자는 위험하니 쓰면 안 된다#

비밀번호 관리자는 하나의 중요한 보관소가 되므로 신중히 써야 한다. 그러나 사람이 수십 개의 강한 고유 비밀번호를 외우는 것은 현실적으로 어렵다. 검증된 비밀번호 관리자를 강한 마스터 비밀번호와 MFA로 보호하는 편이 재사용보다 훨씬 낫다.

27.4 2차 인증을 켰으니 비밀번호는 약해도 된다#

아니다. 다중 인증은 강력한 추가 방어선이지만, 약한 비밀번호를 정당화하지 않는다. 특히 SMS나 푸시 인증은 우회 가능성이 있으므로 기본 비밀번호도 강해야 한다.

27.5 내 계정은 털릴 가치가 없다#

아니다. 공격자는 반드시 유명인이나 부자만 노리지 않는다. 일반 계정도 스팸 발송, 사기, 게임 아이템 탈취, 클라우드 자료 접근, 지인 대상 피싱, 다른 계정 복구에 악용될 수 있다.

27.6 비밀번호를 종이에 적으면 무조건 나쁘다#

상황에 따라 다르다. 모니터에 붙여 두는 것은 위험하지만, 비밀번호 관리자 복구 코드나 마스터 패스프레이즈 힌트를 봉투에 넣어 금고에 보관하는 것은 합리적인 백업 전략일 수 있다. 온라인에 평문으로 저장하는 것보다 물리적으로 안전한 오프라인 보관이 나을 때도 있다.

28. 실전 예시#

28.1 매우 나쁜 예#

• 12345678
• qwer1234
• password
• 이름+생일
• 전화번호 뒷자리
• 회사명2026!
• 서비스명+느낌표

28.2 그나마 나아 보이지만 여전히 위험한 예#

• P@ssw0rd2026!
• Seoul1234!
• MyName!1999
• Github!2026
• Dragon_Fire_01

이런 비밀번호는 복잡해 보이지만, 사람의 흔한 패턴을 따른다.

28.3 좋은 방향#

• 비밀번호 관리자가 생성한 20자 이상의 무작위 비밀번호
• 계정마다 완전히 다른 비밀번호
• 직접 외워야 하는 경우에는 길고 무작위적인 패스프레이즈
• 중요한 계정에는 MFA 또는 패스키 사용

직접 외워야 하는 비밀번호라면, 여러 개의 무작위 단어를 조합한 긴 패스프레이즈가 현실적인 선택이 될 수 있다. 다만 유명 문장, 가사, 작품 대사, 자기소개 문장은 피해야 한다.

29. 비밀번호 점검 체크리스트#

다음 항목에 하나라도 해당하면 비밀번호 관리 방식을 개선할 필요가 있다.

점검 항목	위험도
여러 사이트에서 같은 비밀번호를 쓴다	매우 높음
이메일 계정 비밀번호를 다른 곳에서도 쓴다	매우 높음
비밀번호가 10자 미만이다	높음
이름, 생일, 전화번호가 들어간다	높음
서비스 이름이 들어간다	높음
매년 숫자만 바꾼다	높음
비밀번호를 메모장 파일에 저장한다	높음
비밀번호를 메신저에 보내 두었다	높음
MFA를 전혀 쓰지 않는다	중간 이상
비밀번호 관리자를 쓰지 않는다	계정 수가 많을수록 위험
복구 이메일이 오래된 계정이다	중간 이상
로그인 알림을 확인하지 않는다	중간

30. 권장 우선순위#

비밀번호 보안을 한 번에 완벽하게 바꾸기는 어렵다. 다음 순서로 개선하면 현실적이다.

1. 이메일 계정 비밀번호를 강하고 고유하게 바꾼다.
2. 이메일 계정에 MFA를 켠다.
3. 비밀번호 관리자를 설치한다.
4. 금융, 클라우드, SNS, 쇼핑몰, 게임 계정 순서로 고유 비밀번호를 설정한다.
5. 재사용된 비밀번호를 모두 제거한다.
6. 중요한 계정에 MFA 또는 패스키를 켠다.
7. 복구 이메일과 전화번호를 최신 상태로 정리한다.
8. 사용하지 않는 계정을 삭제하거나 잠근다.
9. 유출 알림과 로그인 알림을 확인한다.

이 순서에서 이메일 계정이 가장 앞에 오는 이유는 간단하다. 대부분의 계정 복구가 이메일을 통해 이루어지기 때문이다. 이메일이 털리면 다른 계정의 비밀번호 재설정도 공격자에게 넘어갈 수 있다.

31. 관련 개념#

31.1 인증#

인증은 사용자가 누구인지 확인하는 절차다. 비밀번호는 인증 수단 중 하나다.

31.2 인가#

인가는 인증된 사용자가 무엇을 할 수 있는지 결정하는 절차다. 로그인에 성공했다고 해서 모든 권한을 가져서는 안 된다.

31.3 세션#

세션은 로그인 후 사용자의 인증 상태를 유지하는 방식이다. 세션 쿠키가 탈취되면 비밀번호를 몰라도 로그인된 것처럼 행동할 수 있으므로 세션 보안도 중요하다.

31.4 토큰#

토큰은 인증이나 API 접근에 사용되는 문자열이다. API 키, 액세스 토큰, 리프레시 토큰 등이 있다. 토큰은 비밀번호와 비슷하게 취급해야 하며, 코드 저장소나 로그에 노출되면 안 된다.

31.5 OTP#

OTP는 일회용 비밀번호다. 한 번만 쓰거나 짧은 시간 동안만 유효하다. 비밀번호의 보조 수단으로 많이 사용된다.

31.6 패스키#

패스키는 공개키 기반의 비밀번호 없는 인증 방식이다. 피싱 저항성이 강하고 사용성이 좋아 차세대 로그인 방식으로 주목받고 있다.

32. 한계#

비밀번호의 근본적인 한계는 다음과 같다.

• 사용자가 기억해야 한다.
• 사용자가 속으면 직접 입력할 수 있다.
• 재사용되기 쉽다.
• 유출되면 다른 곳에도 악용될 수 있다.
• 서비스가 잘못 저장하면 대량 피해가 발생한다.
• 강한 비밀번호를 요구할수록 사용성이 나빠질 수 있다.
• 복구 절차가 약하면 우회될 수 있다.

따라서 현대 보안은 비밀번호 하나에 모든 것을 의존하지 않는 방향으로 가고 있다. 비밀번호 관리자, 다중 인증, 패스키, 보안 키, 이상 로그인 탐지, 세션 보호, 권한 최소화가 함께 필요하다.

33. 결론#

비밀번호는 낡았지만 여전히 중요하다. 가장 안전한 방향은 "사람이 모든 비밀번호를 외우는 것"이 아니라, 비밀번호 관리자를 사용하여 계정마다 길고 무작위인 고유 비밀번호를 만들고, 중요한 계정에는 다중 인증이나 패스키를 적용하는 것이다.

비밀번호 보안의 핵심은 복잡한 규칙을 억지로 외우는 것이 아니다. 핵심은 다음 네 가지다.

1. 길게 만든다.
2. 무작위로 만든다.
3. 재사용하지 않는다.
4. 혼자 쓰지 말고 MFA 또는 패스키와 함께 쓴다.

비밀번호는 자물쇠라기보다 열쇠에 가깝다. 같은 열쇠로 집, 차, 회사, 금고, 사물함을 모두 여는 사람은 없다. 디지털 세계에서도 마찬가지다. 계정마다 다른 열쇠를 쓰고, 중요한 문에는 보조 잠금장치를 더해야 한다.

34. 같이 보기#

• 인증
• 다중 인증
• OTP
• 패스키
• 피싱
• 사회공학
• 암호화
• 해시 함수
• 정보보안
• 계정 탈취
• 크리덴셜 스터핑