Vault, 왜 쓰는가 — 비밀번호 관리자의 개념과 작동 원리
귀찮은 계정 관리와 토큰, 2FA 관리
업무와 더불어, 실생활에서 우리는 굉장히 많은 계정들을 만들고, 로그인한 상태로 사용합니다. 게임 계정부터 쿠팡 계정, 깃허브 계정, 언젠가 스쳐 지나간 쇼핑몰 계정 등 여러 이유로 계정을 만들고, 로그인 해서 사용하죠.
거기에 더불어, 개발자라면 사내 시스템 계정이나 DB 접속 정보, API 키 등 다양한 정보를 추가적으로 관리하게 됩니다. 아무래도 모든 계정에 다른 비밀번호를 설정하고 기억하긴 어렵기 때문에 한 비밀번호를 많이 사용하게 되는데, 다른 계정이 털리면 이러한 특징 때문에 다른 계정도 줄줄이 털리게 됩니다. 이러한 해킹 기법을 Credential Stuffing이라고 합니다.
내 신원 정보의 금고, Vault
위의 문제들을 해결하는 방법 중 하나가 Vault를 사용하는 방법이 있습니다. 대표적인 서비스로는 1Password, Bitwarden이 있죠.
Vault란, 자격증명(Credential) 혹은 민감 정보(ex: 신용카드 번호)를 암호화된 상태로 저장하고, 인증된 주체에게만 복호화해 정보를 제공하는 저장소라고 이 글에서는 칭하겠습니다. 사전적인 정의 중 위와 비슷한 Vault의 뜻은 은행에 있는 단단한 금고를 의미합니다.
Vault의 구성요소
위의 정의를 다시 살펴보면, 내가 저장해둔 정보들은 암호화되어 있다고 하였죠. 그리고 사용하려면 복호화를 해야 한다고 하였습니다. Vault의 핵심 구성요소는, 암호화와 복호화 이 두 가지에 있습니다.
[ 마스터 비밀번호 ] ──(KDF)──> [ 마스터 키 ]
│
├─> 볼트 암·복호화
│
[ 암호화된 볼트 ]
│
┌─────────┴─────────┐
로컬 저장 서버 동기화
(암호문 그대로)
- 마스터 비밀번호(Master Password): 사용자가 유일하게 기억하는 비밀번호. 모든 것의 출발점.
- 볼트(Vault): 항목들이 담긴 암호화된 데이터 덩어리.
- 항목(Item): 로그인 정보, 보안 메모, 카드, ID 문서, TOTP 시드, SSH 키 등.
- 동기화(Sync): 여러 기기에서 같은 볼트를 쓰기 위한 장치. 중요한 건 서버로 올라가는 것이 언제나 암호문이라는 점.
한 곳에 모으면 오히려 위험한 거 아냐?
설명을 듣다 보면, 한 곳에 모으는 게 오히려 위험한 것 아닌지 의문이 들 수 있는데요. Vault는 이 문제를 해결하기 위해 KDF(키 유도) 방식을 사용합니다.
키 유도(Key Derivation)
마스터 비밀번호는 그 자체로 암호화 키가 되지 않습니다. KDF(Key Derivation Function)를 거칩니다.
master_key = KDF(master_password, salt=email, iterations=N)
- PBKDF2-SHA256: 오랜 표준. 반복 횟수로 비용을 올립니다. Bitwarden의 기본값은 60만 회입니다.
- Argon2id: 현재 권장되는 방식. 반복 횟수뿐 아니라 메모리 사용량을 요구해 GPU/ASIC 병렬 공격에 훨씬 강합니다. Bitwarden에서 선택 가능합니다.
KDF의 목적은 단순합니다. 공격자가 마스터 비밀번호를 무차별 대입할 때 한 번의 시도가 비싸지게 만드는 것입니다. 초당 100억 번 시도할 수 있던 것을 초당 수천 번으로 떨어뜨립니다.
보안은 '못 뚫게' 만드는 게 아니라 '뚫을 가치가 없게' 만드는 것
여기서 짚고 갈 게 있습니다. KDF는 공격을 막지 못합니다. 느리게 만들 뿐입니다.
사실 이건 보안 전반에 해당하는 이야기입니다. 절대 뚫리지 않는 시스템은 없습니다. 보안의 실질적인 목표는 방어가 아니라 비용 부과입니다. 공격자가 들이는 시간과 연산 자원이 얻어낼 것의 가치를 넘어서는 순간, 그 공격은 일어나지 않습니다. 은행 금고도 마찬가지죠. 용접기로 며칠 자르면 열립니다. 다만 그동안 경찰이 옵니다.
마스터 비밀번호를 길게 만들라는 조언도 같은 맥락입니다. 8자리는 며칠이면 뚫리지만 4단어 패스프레이즈는 현존 하드웨어로 수백 년이 걸립니다. 뚫는 게 불가능해서가 아니라, 뚫을 때쯤엔 의미가 없어서 안전한 겁니다.
이 관점을 가지고 나머지를 읽으면, 아래 나오는 모든 장치들이 결국 같은 이야기를 하고 있다는 게 보입니다.
Zero-Knowledge란
서버는 이런 것들을 절대 보지 못합니다.
- 마스터 비밀번호 (평문으로 전송되지 않음)
- 마스터 키 (클라이언트에서만 존재)
- 볼트 내용 (암호문만 받아서 저장)
암·복호화는 전부 클라이언트(브라우저 확장, 앱)에서 일어납니다. 서버는 의미를 알 수 없는 blob을 보관하고 동기화만 중계하는 역할입니다.
그래서 이 구조에서는 "서비스 제공자를 신뢰한다"가 전제 조건이 아닙니다. Bitwarden이나 1Password 직원이 마음먹고 DB를 열어봐도 암호문뿐입니다.
1Password의 Secret Key
1Password는 여기에 한 겹을 더합니다. 계정 생성 시 128비트 Secret Key를 발급하고, 이것과 마스터 비밀번호를 함께 키 유도에 사용합니다(2SKD, Two-Secret Key Derivation).
Secret Key는 서버로 전송되지 않고 사용자 기기에만 저장됩니다. 결과적으로:
- 서버 데이터가 통째로 유출되어도, Secret Key 없이는 볼트를 열 수 없습니다.
- 마스터 비밀번호가 약해도 실질적인 브루트포스가 불가능해집니다.
- 대신 새 기기 등록 시 Secret Key가 필요합니다 → 편의성과의 트레이드오프.
Bitwarden은 이 계층 없이 마스터 비밀번호 + KDF에 의존합니다. 대신 오픈소스 감사 가능성과 셀프호스팅이라는 다른 축의 신뢰를 제공합니다.
실제로 서버가 털리면 — LastPass 사례
2022년 LastPass 침해 사건은 이 구조가 어디까지 막아주고 어디부터 막아주지 못하는지 보여준 사례입니다.
- 공격자가 암호화된 볼트 백업 전체를 탈취했습니다.
- 볼트 본문은 여전히 암호문이었습니다 → Zero-Knowledge는 작동했습니다.
- 그러나 URL 등 일부 메타데이터가 암호화되지 않은 상태였습니다 → 어떤 서비스를 쓰는지 노출되었습니다.
- 그리고 KDF 반복 횟수가 낮게 설정된 오래된 계정들은 오프라인 브루트포스의 표적이 되었습니다.
교훈은 명확합니다.
- 마스터 비밀번호의 강도가 최종 방어선입니다. 아키텍처가 좋아도 마스터 비밀번호가
password123이면 소용없습니다. - 메타데이터도 암호화 범위에 포함되어야 합니다.
- KDF 설정은 최신 권장값으로 유지해야 합니다.
Vault는 무적의 금고가 아닙니다. 다만 털리는 데 드는 비용을 비현실적으로 올려놓은 금고입니다. 그리고 그 비용의 상당 부분을 결정하는 게 사용자가 정한 마스터 비밀번호입니다.
Vault를 쓰면 그럼 뭐가 좋아?
1) 고유하고 긴 비밀번호를 "공짜로" 얻습니다.
기억할 필요가 없으니 40자 랜덤 문자열을 써도 부담이 없습니다. 크리덴셜 스터핑이라는 공격 경로 자체가 성립하지 않게 됩니다.
(스크린샷: 사이트별로 서로 다른 비밀번호가 저장되어 자동으로 채워지는 화면)
이런 식으로 특정 사이트마다 다른 비밀번호를 설정해두고, 자동으로 채워지게끔 구성이 가능합니다.
2) 피싱 저항 — 의외로 가장 저평가된 기능
Vault의 자동완성은 도메인을 매칭해서 동작합니다. naver.com 항목은 naver-login.co 같은 유사 도메인에서 자동으로 채워지지 않습니다. 사람 눈은 속지만 Vault는 속지 않습니다. 자동완성이 안 되는 순간이 곧 경고 신호가 됩니다.
3) 비밀번호 외의 것들도 한 곳에
2FA 백업 코드, API 토큰, 라이선스 키, 여권 번호, Wi-Fi 비밀번호. 어디에 둬야 할지 애매했던 것들의 정해진 자리가 생깁니다.
4) 안전한 공유
팀 계정 비밀번호를 슬랙 DM으로 보내는 관행이 사라집니다. 공유 볼트나 만료 기한이 있는 일회성 링크로 대체됩니다. 조직 관점에서는 퇴사자 접근 회수가 가능해진다는 점이 더 큽니다.
5) 감사와 알림
약한 비밀번호, 재사용된 비밀번호, 유출 DB에 포함된 비밀번호를 자동으로 찾아줍니다. (1Password의 Watchtower, Bitwarden의 Vault Health Reports)
잠깐, 2FA 코드도 Vault에 넣어도 될까?
대부분의 Vault는 TOTP(6자리 인증 코드) 생성 기능을 제공합니다. 그런데 여기서 자연스러운 반문이 나옵니다. 비밀번호와 2FA를 같은 곳에 두면 그게 2FA가 맞나?
엄밀히 말하면 아닙니다. 두 요소가 같은 금고에 있으면, 금고가 열리는 순간 둘 다 나옵니다. 2FA의 원래 취지인 "서로 다른 요소를 분리한다"가 깨지는 거죠.
다만 실제로 방어하려는 위협이 무엇인지를 봐야 합니다. TOTP를 Vault에 넣어도 피싱과 크리덴셜 스터핑은 여전히 막힙니다. 유출된 비밀번호만으로는 로그인할 수 없으니까요. 막지 못하는 건 "볼트 자체가 뚫린 경우"인데, 그건 이미 모든 게 끝난 상황입니다.
현실적인 절충안은 이렇습니다.
- 일반 계정: Vault에 TOTP를 넣어도 무방합니다. 편의성 이득이 크고, 어차피 2FA를 아예 안 켜는 것보다 훨씬 낫습니다.
- 최상위 계정 (주 이메일, 금융, 클라우드 콘솔, Vault 계정 본인): 별도 앱이나 하드웨어 키로 분리하세요. 여기가 뚫리면 복구 경로 자체가 사라집니다.
도입하게 되면 장단점?
필자는 1Password, Bitwarden을 전부 사용해 보았는데요. 개인적으로 느낀 장단점은 아래와 같습니다.
1Password
장점
- Secret Key가 키 유도 자체에 함께 들어가기 때문에, 마스터 비밀번호를 탈취당하거나 서버 데이터가 통째로 유출되어도 볼트를 열 수 없습니다.
- 꽤 깔끔한 UX와 Chrome 확장 지원, 앱도 있습니다! → 특정 웹사이트에서 Vault에 저장해둔 계정/비밀번호를 자동으로 Fill in 해줍니다.
- SSO 연동 가능.
단점
- 사악한 가격.
- Secret Key를 또 어딘가 보관해둬야 하기 때문에, 잃어버리지 않을까 노심초사 걱정하게 됩니다. 저는 Emergency Kit를 개인 웹하드에 보관해뒀었습니다. 다만 이건 최선은 아닙니다. 웹하드 계정이 뚫리면 방어선 하나가 사라지니까요. 종이로 출력해 물리적으로 보관하는 게 정석이고, 클라우드에 둔다면 최소한 그 계정만큼은 하드웨어 키로 잠가두시는 걸 권합니다.
Bitwarden
장점
- 저렴한 가격. 무료 티어도 무제한 항목·무제한 기기 동기화를 지원해서 실용적입니다.
- 1Password에 있는 웬만한 기능은 여기도 있습니다.
- Chrome 확장 지원, 앱 지원.
- 오픈소스라 코드를 직접 검증할 수 있고, 원하면 셀프호스팅도 가능합니다.
단점
- 직관적이지 않은 UX. 자동완성이 복잡한 로그인 폼에서 종종 실패합니다.
- 마스터 비밀번호가 사실상 단일 방어선입니다. Bitwarden도 2FA를 지원하긴 합니다. 다만 이건 로그인 단계의 방어라서, 서버에서 암호화된 볼트가 통째로 유출된 상황에서는 도움이 되지 않습니다. 그 시점부터 공격자는 오프라인에서 무제한으로 시도할 수 있고, 남는 방어선은 마스터 비밀번호의 강도와 KDF 설정뿐입니다. 앞서 본 1Password의 Secret Key는 키 유도 자체에 들어가기 때문에 이 오프라인 공격을 무의미하게 만듭니다. 층위가 다릅니다. → Bitwarden을 쓴다면 마스터 비밀번호를 반드시 길게 만들고, KDF를 Argon2id로 바꾸는걸 권장합니다. 설정에서 몇 초면 됩니다.
그래서, 뭘 쓰면 되나
보안 자체로는 둘 다 충분합니다. 양쪽 다 AES-256, Zero-Knowledge 구조, 외부 감사를 갖췄고, 마스터 비밀번호를 충분히 길게 만들면 실질적인 차이는 크지 않습니다.
실무에서 선택을 가르는 건 대체로 이 질문입니다. 마스터 비밀번호의 강도를 내가 통제할 수 있는가. 개인이라면 본인이 잘 만들면 그만이니 Bitwarden으로 충분하고, 조직에 배포해야 한다면 통제할 수 없는 변수라 1Password의 Secret Key가 값을 합니다.
어느 쪽이든, 안 쓰는 것보다는 압도적으로 낫습니다. 지금 열 곳에서 돌려쓰고 있는 그 비밀번호보다 나쁜 선택지는 없거든요.
시작한다면 순서는 이렇습니다.
- Vault를 하나 정해 설치합니다. 고민되면 Bitwarden 무료로 시작하세요.
- 강력한 마스터 비밀번호를 만듭니다. 복잡도보다 길이입니다. 4~6단어 패스프레이즈를 권합니다.
- Vault 계정 자체에 2FA를 겁니다.
- 브라우저에 저장된 비밀번호를 가져오고, 브라우저 저장 기능은 끕니다.
- 중요도 순으로 비밀번호를 교체합니다. 이메일 → 금융 → 클라우드/개발 계정 → 나머지.
- 감사 리포트를 돌려 재사용·유출된 비밀번호를 확인합니다.
- 복구 코드를 오프라인에 보관합니다.
댓글
댓글을 불러오는 중...