기술 보안 · 7분 읽기

올바른 생성기,
올바른 언어.

모든 비밀번호 생성기가 같은 것은 아닙니다 — 그리고 볼트가 어떤 언어로 작성되었는지는 단순한 엔지니어링 세부사항이 아닙니다. 엔트로피, 생성 모드, 그리고 Rust가 내부에서 왜 중요해지는지 살펴봅니다.

2026년 6월 발행 · 읽는 시간 7분

비밀번호 관리자가 “강력한 비밀번호를 생성한다”고 말할 때 두 가지 질문이 생깁니다. 정말 예측 불가능한가, 즉 무작위성의 품질은 어떤가, 그리고 표시된 뒤 메모리에서는 어떻게 되는가? 첫 번째는 생성 모드의 문제입니다. 두 번째는 애플리케이션을 구동하는 언어의 문제입니다. 이 글은 두 가지를 모두 다룹니다.

~100 bits
16자 랜덤 비밀번호(매우 강함)
~77 bits
6단어 Diceware passphrase (EFF)
12,9 bits
Diceware 단어 하나가 추가하는 엔트로피(7 776단어 목록)

01 / 기본엔트로피: 유일하게 중요한 척도

비밀번호의 강도는 체감되는 “복잡성”이 아니라 엔트로피로 측정됩니다. 공격자 입장에서의 불확실성을 bits로 나타낸 값입니다. 가능한 조합이 많을수록 brute-force 공격 비용은 폭발적으로 증가합니다. 전체 ASCII alphabet에서 뽑은 16자 비밀번호는 약 100 bits에 도달하며, “매우 강함”의 영역에 들어갑니다.

자주 잊히는 핵심이 있습니다. 엔트로피는 무작위성의 원천이 CSPRNG, 즉 암호학적으로 안전한 의사난수 생성기일 때만 의미가 있습니다. 일반적인 Math.random()은 예측 가능하며 나머지 모든 보안을 무너뜨립니다. 좋은 구현은 운영체제에서 엔트로피를 읽습니다. Unix에서는 /dev/urandom 또는 getrandom(2), Windows에서는 CNG를 사용합니다.

02 / 모드네 가지 생성기 계열

좋은 관리자는 “하나의” 생성기가 아니라 용도에 맞는 여러 모드를 제공합니다. 원칙은 이렇습니다. 기억하기 쉬움은 길이로 지불한다. 가장 밀도 높은 방식부터 가장 사람 친화적인 방식까지 네 가지 계열을 살펴봅니다.

순수 랜덤

j7$kQ!mP2#xR9vL@
16자에서 ~100 bits
문자당 밀도가 최대입니다. 볼트에 저장되고 기억해서 입력할 일이 없는 계정에 이상적입니다. 기본값으로 우선해야 합니다.

Passphrase (Diceware / EFF)

Granite-Bicycle-Phantom-Violet-9
6단어에서 ~77 bits
7 776단어 목록에서 무작위로 뽑은 단어들입니다. 화면에서는 길어 보이지만 몇 초 안에 기억할 수 있습니다 — 어디에도 적고 싶지 않은 마스터 비밀번호에 가장 적합한 선택입니다.

기억 가능 / 발음 가능

Crimson7!Falcon$Reef
중간 엔트로피
“단어-숫자-기호” 패턴으로, 소리 내어 읽거나 모바일에서 입력하기 쉽습니다. 받아들일 수 있는 타협이지만, 같은 길이에서는 엔트로피가 더 낮습니다. 기억하기 쉬운 것이 목표라면 passphrase가 여전히 더 낫습니다.

숫자 PIN

8392 4471
낮음 — 특정 용도
숫자만 허용되는 경우에 한정됩니다. 제한된 상황이 아니라면 피해야 합니다.

올바른 습관: 용도에 맞게 엔트로피 조정하기

속도 제한이 걸린 로그인 페이지로 보호되는 웹 계정에서는 공격자가 초당 몇백 번의 시도로 제한됩니다. 이런 경우 50 bits도 지질학적 시간 동안 버팁니다. 과도한 엔트로피가 의미 있는 것은 암호화 키나 crypto 지갑 seed처럼 오프라인 secret일 때입니다. 이 경우 공격은 대규모로 병렬화될 수 있습니다. 매우 높은 가치의 secrets에는 실제 물리적 주사위를 굴리는 것, 즉 본래 의미의 Diceware가 여전히 궁극적인 선택입니다. CSPRNG 품질이나 손상된 브라우저에 대한 모든 의존성을 제거하기 때문입니다.

03 / 내부 동작Rust가 판을 바꾸는 이유

좋은 비밀번호를 생성하는 것은 작업의 절반입니다. 나머지 절반은 그것을 방치하지 않는 것입니다. 표시되거나 복호화된 뒤 비밀번호는 RAM에 존재합니다 — 그리고 바로 여기서 애플리케이션의 언어가 결정적이 됩니다.

Microsoft는 자신들이 마주치는 보안 취약점의 70 %가 buffer overflow, use-after-free 같은 메모리 버그라고 보고했습니다. Google도 Chrome과 Android에서 같은 비율을 관찰했습니다. Rust는 ownership과 borrowing 모델을 통해 garbage collector 없이 바로 이런 결함 유형을 컴파일 시점에 제거합니다.

Google의 수치는 명확합니다. Android의 메모리 취약점은 2019년 223건에서 2024년 50건 미만으로 떨어졌고, 처음으로 전체의 20 % 아래로 내려갔습니다. 새로운 Rust code는 기존 C/C++ code보다 메모리 결함 밀도가 최대 1000× 낮고, rollbacks는 4× 적으며, 리뷰 시간은 25 % 줄었습니다.

1. Garbage collector 없는 메모리 안전성. Java나 Python 같은 언어도 memory-safe이지만, garbage collector는 비결정적으로 메모리를 해제합니다. secret이 memory dump나 cold-boot 공격에 노출된 채 무기한 남아 있을 수 있습니다. Rust는 데이터가 더 이상 사용되지 않는 순간 결정적으로 메모리를 해제합니다.

2. zeroize를 통한 명시적 삭제. Rust는 해제된 메모리가 덮어써진다고 보장하지 않습니다. zeroize crate가 이 빈틈을 메웁니다. secret을 Zeroizing으로 감싸면, scope를 벗어나는 정확한 순간에 zero로 덮어쓰는 것을 보장합니다 — compiler가 최적화로 제거할 수 없는 volatile write를 통해서입니다.

3. Crypto의 올바른 사용을 강제하는 type system. Rust의 엄격한 type system은 민감한 데이터가 어떻게, 몇 번 사용될 수 있는지 제한할 수 있습니다. 예를 들어 한 번만 사용할 수 있는 key를 모델링하고, compiler가 재사용을 거부하게 만들 수 있습니다.

메모리에서의 자동 삭제use zeroize::Zeroizing;

fn unlock_vault(master: &str) {
    let dek = Zeroizing::new(derive_key(master));
    // ... déchiffrement du coffre ...
}   // `dek` est écrasé par des zéros ici, automatiquement
Google에서 Rust 도입은 Android 메모리 결함 비중을 76 % (2019)에서 24 % (2024)로 낮췄으며, 업계 기준(~70 %)보다 훨씬 낮습니다.

기술적 정직함: Rust는 마법 지팡이가 아니다

unsafe code와 third-party dependencies는 여전히 공격 표면입니다 — Google도 실제 배포 전에 Rust parser의 unsafe block에서 취약점(CVE-2025-48530)을 수정한 바 있습니다. 메모리 안전성은 계층이지 목적 그 자체가 아닙니다. Argon2id 같은 강력한 KDF, zero-knowledge architecture, auto-locking, MFA 같은 defense in depth와 결합되어야 합니다.

Garbage-collected 언어

  • 비결정적 메모리 해제
  • Secrets가 알 수 없는 시간 동안 메모리에 남음
  • 명시적 삭제가 어렵거나 불가능
  • Dumps와 cold-boot에 노출

Rust

  • 결정적 해제 (ownership)
  • zeroize를 통한 즉시 삭제
  • buffer overflow와 use-after-free 없음
  • Crypto errors를 컴파일 시점에 포착

04 / 핵심 요약비밀번호 관리자에게 요구해야 할 것

비밀번호 관리자를 선택하거나 평가할 때는 네 가지 구체적인 질문을 던지세요.

Checklist

  • 1. 생성기가 system CSPRNG에 기반하며, 엔트로피를 bits로 표시하는가?
  • 2. 마스터 비밀번호를 위한 Diceware/EFF passphrase mode를 제공하는가?
  • 3. 생성이 서버를 거치지 않는 local (client-side) 방식인가?
  • 4. 민감한 core가 memory-safe language로 작성되어 있으며 secrets를 명시적으로 삭제하는가?

교육 목적의 정보 콘텐츠입니다. 인용된 통계(Google/Android, Microsoft, Diceware/EFF)는 위에 나열된 sources에서 가져온 것입니다. Rust code examples는 설명을 위해 단순화되었습니다.

안전한 생성. 오래가도록 설계된 볼트.

High-entropy passwords, 기억 가능한 passphrases, 그리고 메모리 안전성을 위해 설계된 core.

우리의 접근 방식 보기