실제 비밀번호 관리자는 실제로 이렇게 작동합니다

Source: Dev.to

대부분의 사람들은 매일 비밀번호 관리자를 사용하지만, 실제로 비밀번호를 어떻게 안전하게 보호하는지 이해하는 사람은 거의 없습니다.

이 글에서는 실제 프로덕션‑급 비밀번호 관리자가 어떻게 동작하는지(예: 1Password 혹은 Bitwarden에서 사용하는 핵심 아이디어) 를 Passwuts라는 프로젝트를 예시로 들어 설명합니다.

Why I Built Passwuts

비밀번호 재사용은 오늘날 가장 큰 보안 위협 중 하나입니다. 하나의 웹사이트가 해킹당하면, 재사용된 비밀번호 때문에 사용자는 자신이 이용하는 모든 서비스가 위험에 처하게 됩니다.

Passwuts는 다음을 통해 이를 해결합니다:

• 강력하고 고유한 비밀번호 강제
• 클라이언트‑사이드 암호화 사용
• 서버는 평문 자격 증명을 절대 볼 수 없음 보장

이는 진지한 비밀번호 관리자들이 채택하고 있는 보안 철학과 동일합니다.

High‑Level Architecture (Zero‑Knowledge Model)

Passwuts는 제로‑지식, 클라이언트‑우선 암호화 모델을 따릅니다:

• 🔐 마스터 비밀번호 클라이언트를 떠나지 않음
• 🔑 암호화 키는 PBKDF2 로 로컬에서 파생
• 🔒 비밀번호는 AES‑GCM 으로 암호화
• 🗄️ 서버는 암호문 + IV 만 저장

백엔드가 침해당하더라도 비밀번호는 안전합니다.

How Encryption Works (Step‑by‑Step)

1. 사용자가 마스터 비밀번호를 생성합니다.
2. PBKDF2 를 사용해 강력한 암호화 키를 파생합니다(입력값: 마스터 비밀번호 + 사용자 UID를 소금값으로).
3. 각 항목마다 무작위 IV 를 사용해 AES‑GCM 로 비밀번호를 암호화합니다.
4. 암호화된 데이터만 Firestore에 저장됩니다.

평문이 브라우저를 떠나는 일은 없습니다.

Vault Verification (Without Storing Passwords)

문제: 마스터 비밀번호를 저장하지 않고 어떻게 검증할까?

해결 – 검증자 패턴:

• 알려진 문자열(예: "vault-check")을 암호화합니다.
• 암호문을 vault 메타데이터 로 Firestore에 저장합니다.

잠금 해제 시:

1. 클라이언트가 저장된 암호문을 로컬에서 복호화합니다.
2. 복호화에 성공하면 비밀번호가 유효한 것입니다.

✅ 보안 ✅ 제로‑지식 ✅ 비밀번호 저장 없음

Browser Extension Architecture

브라우저 확장 프로그램은 웹 앱과 동일한 암호화 레이어를 재사용합니다:

• Firebase 인증
• 공유 내부 암호화 패키지 (@pm/crypto)
• 클라이언트‑사이드 암호화만 수행
• 백엔드에 비밀 로직 없음

이렇게 하면 플랫폼 간 동작이 일관됩니다.

What This Project Taught Me

• 🔍 암호화 실패는 대부분 오용에서 비롯되며, 수학 자체가 문제는 아닙니다.
• 🔄 IV/nonce 관리가 핵심입니다.
• 🧠 보안 UX는 암호학만큼 중요합니다.
• 🔐 제로‑지식 시스템은 모든 곳에서 규율을 요구합니다.

Final Thoughts

비밀번호 관리자는 마법이 아닙니다. 그들은 다음을 기반으로 신중하게 설계된 시스템입니다:

• 키 파생
• 인증된 암호화
• 안전한 클라이언트‑사이드 아키텍처

그 작동 방식을 이해하면 다음을 얻을 수 있습니다:

• 더 나은 엔지니어
• 더 안전한 사용자