▲

Bitwarden을 추천하지 않는다

 (マリウス.com)
1P by GN⁺ 1시간전 | ★ favorite | 댓글 1개
  • 수년간 자체 호스팅으로 사용해 본 결과 Bitwarden은 공식 서버의 무거움, 불투명해진 오픈소스 방향성, 낮은 클라이언트 품질, 반복된 보안 이슈 때문에 더 이상 추천하기 어려운 선택이 됨
  • 공식 Bitwarden server는 C# 백엔드와 MSSQL Express 중심의 무거운 구성인 반면, Rust 기반 비공식 호환 서버 Vaultwarden 은 더 단순하고 가벼워 소규모·중간 규모 배포에서 선호됨
  • 2024년 클라이언트에 들어간 @bitwarden/sdk-internal의 제한적 라이선스는 반발 뒤 GPLv3로 재라이선스됐지만, 무료·오픈소스 부분보다 SaaS 구독 중심으로 움직인다는 우려를 키움
  • Bitwarden 클라이언트에서는 금고 가져오기 실패, organization 금고와 individual 금고 간 항목 이동 부재, 평문 JSON 내보내기 우회책, 자동 업데이트로 인한 금고 접근 불능, 느린 UI와 불편한 자동 입력 UX가 누적됨
  • 단일 금고에 모든 자격 증명을 맡기기보다 전문·클라이언트 프로젝트, PII 계정, 비PII 계정, 인프라, 일회성 시크릿을 나눠 SaaS 비밀번호 관리자, KeePass 계열, HashiCorp Vault, pass 같은 도구로 구획화하는 편이 더 적합함

Bitwarden을 더 이상 추천하지 않게 된 배경

  • 거의 4년 전 hardened OpenBSD에서 LastPass처럼 자체 운영하는 방법을 공개하며 OpenBSD 인스턴스나 Raspberry Pi 베어메탈에 Vaultwarden을 올리고 Bitwarden 클라이언트 앱의 백엔드로 쓰는 구성을 다룸
  • 비슷한 접근을 수년간 직접 사용한 뒤, 이제는 Bitwarden 사용을 추천하지 않는다는 결론에 도달함
  • 핵심 문제는 공식 서버의 무거움, 오픈소스 방향성의 불투명함, 클라이언트 앱의 품질과 UX, 반복되는 보안 이슈, 단일 비밀번호 관리자에 모든 자격 증명을 맡기는 구조의 위험으로 정리됨

프리미엄 이중 라이선스 비밀번호 관리자

  • Wikipedia는 Bitwarden을 민감 정보를 저장하는 프리미엄 오픈소스 비밀번호 관리 서비스로 설명하며, Bitwarden, Inc.가 소유·개발한다고 소개함
  • Bitwarden은 공식 서버와 대부분의 플랫폼용 클라이언트 앱을 개발하고, 직접 호스팅을 원하지 않는 사용자를 위한 SaaS 제품도 제공함
  • 호스팅 제품의 가격은 경쟁 제품과 유사하지만 기능 차이가 있으며, 호스팅을 쓰든 자체 호스팅을 하든 클라이언트 앱은 동일함
  • Bitwarden은 2022년 PSG growth equity의 1억 달러 투자를 받았고 _Battery Ventures_도 참여함
  • 오픈소스를 유지하려는 비밀번호 관리자와, 1억 달러 투자 수익을 기대하는 투자자가 이사회에 있는 비밀번호 관리자는 다르며, 이 시점부터 제품이 사용자보다 투자자를 향해 움직이기 쉬워짐

공식 서버와 Vaultwarden의 대비

  • Bitwarden을 직접 호스팅하면 비교적 빨리 엔터프라이즈 소프트웨어 지옥에 들어간다는 평가가 나옴
  • 표준 Bitwarden server 배포는 무거운 C# 백엔드이며 _MSSQL Express_를 함께 제공하고, _PostgreSQL_이나 MariaDB 같은 Linux 친화적 데이터베이스와 함께 동작하지 않음
  • 배포 규모와 고가용성 요구사항에 따라 Kubernetes를 활용해야 할 수 있고, 이 경우 추가 오버헤드와 복잡성이 생김
  • 소규모·중간 규모 배포에서는 Vaultwarden을 선호하는 경우가 많음
    • Vaultwarden은 Rust로 작성된 비공식 Bitwarden 호환 서버임
    • 공식 Bitwarden server보다 단순하고 가벼워 관리자에게 큰 차이를 만듦
    • GitHub 스타 수가 공식 구현보다 약 3배로 보인다는 점은 Bitwarden의 기술적 사용자들이 현재 공식 스택의 방향을 어떻게 받아들이는지 생각하게 만듦
  • 1억 달러 Series B 투자를 받은 회사라면, 훨씬 성공적인 백엔드 구현을 만든 사람들을 공식 스택 최적화와 가속화에 합류시키는 선택을 검토할 수 있었음

Bitwarden lite와 오픈소스 방향성

  • Bitwarden은 Vaultwarden을 공식 프로젝트로 받아들이기보다, Vaultwarden의 주요 개발자를 고용한 뒤 기존 백엔드의 더 가벼운 버전인 Bitwarden lite를 공개한 것으로 보임
  • Bitwarden lite는 여전히 _Microsoft_의 .NET 기반 서비스이며, Vaultwarden 인스턴스가 일반적으로 소비하는 RAM보다 3배 이상 필요해 보인다는 평가를 받음
  • Bitwarden의 오픈소스 성격은 지난 1년여 동안 더 흐릿해짐
    • 2024년 말 사용자들은 클라이언트에 새 의존성 @bitwarden/sdk-internal이 들어온 것을 발견함
    • 해당 라이선스에는 이 SDK를 Bitwarden이 아닌 소프트웨어, Bitwarden 비호환 구현, 다른 SDK 개발에 사용할 수 없다는 문구가 있었음
  • 오픈소스를 내세우는 제품에서 이런 라이선스 문구는 상당한 전환점으로 받아들여짐
  • 커뮤니티의 상당한 반발 이후 Bitwarden은 이를 “패키징 버그”라고 불렀고, 결국 SDK를 GPLv3로 재라이선스함
  • 기술적으로는 문제가 해결됐지만, 철학적으로는 무료·오픈소스 부분은 미끼이고 실제 제품은 SaaS 구독이며 커뮤니티는 이슈와 번역을 제공하는 역할에 머무르는 방향으로 보임
  • 관련 비판으로 The freeware parts are bait도 있음

클라이언트 앱이 핵심 문제

  • 백엔드를 제외해도 Bitwarden의 가장 큰 문제는 클라이언트 애플리케이션으로 꼽힘
  • 광고된 기능이 기대대로 동작하지 않고, 출시 10년이 지났는데도 기본 기능이 없으며, 비슷한 가격의 대안과 비교했을 때 사용자 인터페이스가 좋지 않다는 평가가 나옴
  • Bitwarden이 순수 FOSS 커뮤니티 노력이라면 이런 결함을 넘길 수도 있지만, 벤처 자본을 받은 회사이기 때문에 같은 기준을 적용하기 어려움
  • 커뮤니티가 관료적 절차에 묶이는 모습도 Bitwarden이 커뮤니티 노력이라기보다 회사 제품이라는 점을 드러냄

금고 마이그레이션 문제

  • 약 1년 전, 독점 플랫폼 대신 연간 구독으로 오픈소스 소프트웨어를 지원하려는 생각으로 경쟁 제품에서 Bitwarden으로 옮기려는 사용자를 지원함
  • 기존 비밀번호 관리자에서 새 Bitwarden 계정으로 금고를 가져오는 과정에서 문제가 발생했고, GitHub 버그 리포트에 따르면 적어도 하나의 금고는 가져오기를 성공시키기 위해 상당한 기술적 우회가 필요했음
  • 마이그레이션·가져오기 기능은 Bitwarden의 마케팅 자료와 문서 여러 곳에서 광고되고 있었고, 이미 여러 사용자가 같은 문제를 겪고 있었음
  • 그럼에도 Bitwarden은 해당 이슈를 처리하기보다 커뮤니티 포럼에 또 다른 논의를 열라고 요청한 것으로 받아들여짐
  • 이런 기업식 관료주의는 오픈소스 소프트웨어의 모습과 맞지 않으며, 오픈소스 소프트웨어와 유료 제품 모두에서 광고되는 기능이 실제로 동작하지 않는 상황에서는 정당화되기 어려움
  • 같은 가져오기를 Bitwarden의 독점 대안들로 테스트했을 때는 문제없이 동작했음

금고 간 항목 이동의 부재

  • 마이그레이션 문제는 초기 가져오기에만 한정되지 않음
  • Bitwarden 내부에서 organization 금고와 individual 금고 사이에 항목을 옮기려 해도, 현재까지 선택한 항목을 다른 곳으로 이동하는 제대로 된 기능이 없음
  • 로그인 항목이 몇 개라면 복제하고 수정할 수 있지만, 수백 개 항목을 정리하거나 조직을 떠나거나 여러 조직을 통합하는 상황에서는 반복 작업이 과도해짐
  • Bitwarden 지원과 커뮤니티 스레드가 권장하는 공식 우회책은 원본 금고를 암호화되지 않은 JSON으로 내보내고, 파일을 수정한 뒤 대상 금고로 다시 가져오는 방식임
  • 이 과정은 500개 이상의 자격 증명이 ~/Downloads나 Dropbox, OneDrive, iCloud 같은 클라우드 동기화 디렉터리에 평문으로 놓일 수 있는 보안상 위험을 만듦
  • 내보내기에는 파일 첨부가 빠지고, 휴지통 항목, 비밀번호 기록, 타임스탬프도 빠짐
  • SSH 키 파일, 라이선스 키, 이미지 형태 복구 코드 같은 첨부 파일이나 규정 준수·감사용 비밀번호 기록에 의존하는 조직에는 받아들이기 어려운 방식임
  • 자격 증명의 단일 진실 공급원이어야 하는 제품이 10년 차에도 500개 항목을 온전히 다른 금고로 옮기는 버튼을 제공하지 않는다는 점은 엔지니어링 우선순위를 드러냄

클라이언트 업데이트가 기능을 깨뜨리는 문제

  • Bitwarden은 사용자에게 사전 고지 없이 클라이언트 업데이트를 배포하고, 이 업데이트가 때때로 클라이언트 쪽에서 금고 접근 불능을 일으킬 수 있음
  • 여행 중 휴대폰을 밤새 연결해 둔 사이 _F-Droid_가 Bitwarden을 업데이트했고, 다음 아침 은행 로그인에 필요한 Bitwarden 앱에서 금고에 접근할 수 없었음
  • 원인 파악에는 시간이 걸렸고, bitwarden/android 이슈와 Vaultwarden 논의를 통해 상황을 확인함
  • Bitwarden 백엔드를 호스팅하던 UPDC를 가지고 있었기 때문에 더 나쁜 상황을 피할 수 있었음
  • 클라이언트와 백엔드 사이에 깨지는 프로토콜 변경으로 보이는 업데이트를 밀어 넣는 방식은 무책임하게 느껴졌고, 오프라인 모드로 비밀번호 관리자를 신뢰해야 하는 사용자에게 Bitwarden을 신뢰할 수 없다는 결론으로 이어짐
  • 이후 Bitwarden 클라이언트 자동 업데이트를 비활성화하고, 모든 비밀번호의 최신 스냅샷을 KeePassChi, KeePassXC, KeePassDX 기반 로컬 백업으로 내보냄
  • 이 문제는 Bitwarden 직원의 주장과 달리 Vaultwarden만의 문제가 아니라고 봄
    • bitwarden/android 저장소에는 유사한 보고가 여럿 있음
    • 2025.12.x 릴리스 회귀는 로그인 후 마스터 비밀번호를 두 번 요구하고 앱을 크래시시켰다는 보고가 있음
    • 2025.6.0 릴리스는 여러 사용자에게 시작 즉시 크래시를 일으켰다는 보고가 있음
  • Android 앱은 2024년에 _.NET MAUI_에서 네이티브 _Kotlin_으로 전면 재작성됐고, v2024.10.1 출시 이후 분기 릴리스마다 회귀가 계속 나타난다는 평가를 받음

사용자 경험과 데스크톱·모바일 앱 품질

  • Bitwarden은 휴대폰과 데스크톱에서 UI 측면으로 주관적으로 가장 나쁜 앱 중 하나였다는 평가를 받음
  • 수년간 사용했음에도 ungoogled-chromium 확장 프로그램이나 데스크톱·모바일 앱을 여는 것이 꺼려질 정도였음
  • Electron 기반 데스크톱 앱을 소스에서 빌드하는 것은 매우 번거롭고, 사전 빌드된 _Flatpak_은 Wayland에서 제대로 동작하지 않음
  • 클라이언트와 확장 프로그램은 오프라인 사용을 지원하지만, 오프라인 사용을 중심으로 설계된 것 같지는 않음
    • 모바일 앱이나 브라우저 확장을 열 때 백엔드에 접속하려는 듯한 지연이 발생함
    • 백엔드를 공개 인터넷에 두지 않는 구성에서는 이 지연이 몇 초에서 몇 분까지 이어질 수 있음
    • 금고 잠금 해제 시 동기화를 끄고 불필요한 대기를 막는 방법이 없어 보임
  • 브라우저 확장 프로그램의 Vault 로그인 목록도 불편함
    • 보통 다른 비밀번호 관리자는 목록 항목을 클릭하면 로그인 폼을 채움
    • Bitwarden에서는 목록 항목 전체를 클릭하면 상세 화면이 열리고, 오른쪽의 작은 Fill 버튼을 눌러야 자동 입력됨
    • 마우스 오버로 큰 목록 항목이 강조되지만 실제 자동 입력은 작은 버튼에만 묶여 있어 조작하기 어려움
    • 목록 항목 클릭은 자동 입력, 작은 버튼은 상세 열기로 동작하게 바꾸는 설정도 없어 보임
  • 유사한 문제가 Hacker News와 커뮤니티에서도 반복적으로 나타남
  • 2021년부터 커뮤니티 포럼에 남아 있는 항목별 간단한 편집 이력 같은 기능 요청도 처리되지 않았고, MSP 리셀러들도 “빙하처럼 느린 기능 개발”이라고 공개적으로 비판함

Bitwarden CLI의 위험한 인터페이스

  • Bitwarden CLI도 사용자 인터페이스가 좋지 않다는 평가를 받음
  • bw 도구의 list 명령은 --show-credentials 같은 추가 플래그 없이도 비밀번호와 TOTP 코드를 포함해 모든 항목의 세부 정보를 출력함
  • bw list를 실수로 다른 곳에 파이프해 모든 자격 증명을 의도치 않게 노출할 수 있는 상황을 충분히 고려하지 않은 설계라는 비판을 받음
  • Bitwarden CLI가 _TypeScript_로 만들어진 터미널 도구라는 점도 문제로 꼽힘
    • 런타임과 의존성이 많음
    • JavaScript 스택은 CI 환경에서 무심코 실행하기에 더 이상 부담 없는 선택이 아니라고 평가됨

보안 이력

  • 비밀번호 관리자의 핵심 역할은 사용자를 안전하게 지키고 자격 증명을 안전하게 보관하는 것임
  • 2016년부터 이어진 제품으로서 Bitwarden은 실제 프로덕션에 배포된 보안 문제를 적지 않게 겪었다는 평가를 받음
  • 개별 사건 하나하나가 치명적이라는 뜻은 아니지만, 사후 대응 중심의 보안 태도, 당혹스러운 발견에 대한 “의도한 동작”식 반응, 보안 핵심 CLI의 Node.js 도구 체인 의존, 외부 연구자들이 미리 지적한 문제가 늦게 처리되는 패턴이 문제로 꼽힘

  • 2023년: KDF

    • 2023년 1월, LastPass 침해 직후 보안 연구자 _Wladimir Palant_는 Bitwarden의 광고된 _200,001_회 PBKDF2 반복이 실제로는 _100,000_회에 가깝다는 분석을 공개함
    • 이유는 추가 서버 측 반복이 로그인에 쓰이는 마스터 비밀번호 해시에만 적용되고, 금고 데이터를 보호하는 암호화 키에는 적용되지 않았기 때문임
    • 유출된 금고에 접근한 공격자는 서버를 완전히 우회할 수 있고, 실효 보안 수준은 LastPass와 같아진다는 평가가 나옴
    • 기본 클라이언트 측 반복 횟수도 당시 OWASP 권고보다 낮은 _100,000_회였고, 이 우려는 2020년부터 제기돼 있었음
    • Bitwarden은 결국 기본값을 _600,000_회로 올리고 Argon2 지원을 추가했지만, 초기 변경은 새 계정에만 적용돼 기존 사용자가 직접 KDF 설정을 바꿔야 했음

  • 2023년: Windows Hello 우회

    • 2023년 _RedTeam Pentesting_은 Windows 데스크톱 클라이언트 취약점 “Bitwarden Heist”를 공개함
    • 이 취약점은 CVE-2023-27706으로, 도메인 관리자 권한을 가진 공격자가 _Windows Hello_나 마스터 비밀번호 프롬프트 없이 로컬 DPAPI 저장소에서 금고 복호화 키를 추출할 수 있었음
    • 연구자들은 낮은 권한의 사용자 세션에서 실행되는 어떤 프로세스든 DPAPI에 금고 잠금 해제용 자격 증명을 요청할 수 있었다고 표현함
    • 수정은 최초 공개 후 몇 달 뒤 2023.4.0 버전에 포함됨

  • 2023년: 교차 출처 자동 입력

    • 같은 해 CVE-2023-27974가 공개됨
    • Bitwarden 브라우저 확장은 신뢰된 페이지에 포함된 교차 도메인 iframe에도 기본 도메인이 맞으면 자격 증명 입력을 제공했음
    • 예를 들어 trusted.com이 attacker.trusted.com iframe을 포함하고 해당 서브도메인을 제3자가 제어한다면 자격 증명을 훔칠 수 있었음
    • Bitwarden은 호환성 때문에 iframe을 이렇게 처리해야 하며, _“Auto-fill on page load”_가 기본으로 켜져 있지 않다고 답함
    • 해당 옵션을 켠 사용자에게는 작은 위안에 불과함

  • 2025년: DOM 기반 클릭재킹

    • 2025년 8월, 보안 연구자 Marek Tóth는 악성 페이지에서 한 번의 클릭으로 Bitwarden 브라우저 확장이 신용카드 정보와 개인정보를 자동 입력하게 만들 수 있는 DOM 기반 클릭재킹 공격 유형을 공개함
    • 취약점은 2025년 4월, 공개 4개월 전에 보고됐지만 Bitwarden은 이를 _“moderate severity”_로 분류함
    • 패치는 연구자의 엠바고가 끝난 당일 배포된 2025.8.2 버전에 포함됨

  • 2026년: Shai-Hulud

    • 글을 쓰기 며칠 전, 공식 Bitwarden CLI 클라이언트 2026.4.0이 진행 중인 Checkmarx 공급망 공격에서 침해됨
    • 영향을 받은 패키지 버전은 @bitwarden/cli2026.4.0으로 보이며, 악성 코드는 패키지에 포함된 bw1.js에 게시됨
    • 공격은 Bitwarden CI/CD 파이프라인의 손상된 GitHub Action을 활용한 것으로 보이며, 이 캠페인의 다른 저장소 피해 양상과 일치함
    • 악성 Bitwarden npm 패키지를 설치한 조직은 이를 자격 증명 노출과 CI/CD 침해 사건으로 다뤄야 함
    • 페이로드는 Bun 런타임을 다운로드하고, 2단계 Shai-Hulud 웜을 복호화한 뒤 _GitHub_와 npm 토큰, SSH 키, 셸 히스토리, AWS, GCP, Azure 자격 증명, GitHub Actions 시크릿, AI 도구가 쓰는 MCP 설정 파일까지 수집함
    • 훔친 데이터는 피해자 자신의 GitHub 계정에 공개 저장소를 자동 생성해 업로드하는 방식으로 유출됨
    • Bitwarden의 npm 배포 파이프라인은 약 19시간 동안 침해된 상태였고, 334명의 개발자가 악성 패키지를 내려받을 시간이 있었음
    • Bitwarden 공식 입장은 최종 사용자 금고 데이터가 접근되지 않았다는 점을 강조했지만, CI 파이프라인에서 bw를 실행한 사용자는 해당 머신에 있던 다른 비밀을 공격자에게 넘긴 셈임
    • bw가 Go나 Rust 생태계에서 흔한 단일 정적 링크 바이너리였다면 npm 형태의 폭발 반경은 존재하지 않았을 것이라는 평가가 나옴
    • Go와 Rust 생태계에서도 공급망 공격이 늘고 있지만, 성공적인 공격의 장벽은 여전히 더 높다고 평가됨

앞으로의 접근: 나누고 격리하기

  • 모든 사용 사례와 설정에 완벽히 맞는 단일 비밀번호 관리자는 없다는 결론에 도달함
  • 개인 생활에서는 다른 사람과 금고나 개별 비밀번호를 공유할 필요가 없지만, 업무에서는 이런 일이 흔함
  • 은행 계좌나 보험 포털 로그인은 CLI 도구에서 사용할 필요는 없지만 여러 기기에서 접근 가능해야 함
  • 클라우드 스토리지 시크릿이나 배포용 SSH 개인 키는 휴대폰에 동기화될 필요는 없지만, 프로그래밍 방식으로 호출 가능한 명령줄 도구에서 접근해야 함
  • 하나의 소프트웨어나 플랫폼으로 모든 것을 해결하려는 대신, 자격 증명 묶음을 더 잘 구획화하는 편이 합리적임
  • 보안 관점에서도 비밀번호 그룹을 서로 다른 소프트웨어와 서비스로 나누면 데이터 침해 시 영향 범위를 줄일 수 있음

자격 증명 분류와 도구 선택

  • 그룹 A: 전문·클라이언트 프로젝트

    • 그룹 A는 플랫폼 로그인 등 전문·클라이언트 프로젝트 자격 증명임
    • 적절한 금고 공유, 클라이언트가 실제로 쓰는 도구와의 통합, SSO, 기업 기기의 브라우저 확장, 감사 로그를 제공하고 호스팅 부담을 없애는 SaaS 비밀번호 관리자를 사용함
    • 플랫폼은 독점 제품이라 평소라면 선호하지 않지만, 이 그룹의 범위가 클라이언트 작업으로만 제한되므로 트레이드오프를 수용함

  • 그룹 B: PII를 포함한 계정

    • 그룹 B는 은행 계좌, 온라인 쇼핑몰처럼 PII를 담은 계정의 자격 증명임
    • 이 계정들은 이미 이름, 주소, 생년월일, 결제 정보 같은 개인정보를 담고 있고, 해당 서비스들 자체가 정기적으로 유출되기도 하며 Have I Been Pwned에서도 확인 가능함
    • 비밀번호 관리자 침해가 공격자가 아는 정보를 의미 있게 확장하지는 않는다고 봄
    • TOTP와 Passkeys가 있는 상황에서는 여기서 중요한 것은 교차 기기 가용성, 신뢰성, 오프라인 기능임
    • 그룹 A와 자동으로 함께 침해되지 않도록 다른 벤더의 두 번째 별도 클라우드 기반 비밀번호 관리자를 사용하고, 다른 마스터 비밀번호와 다른 복구 메커니즘을 둠
    • 적어도 하나의 GrapheneOS 기기에서 모바일 앱을 실행할 예정이므로 _Google Play Services_에 의존하지 않고, 가능하면 오픈소스나 소스 공개 클라이언트를 제공하는 솔루션을 선호함

  • 그룹 C: PII가 없는 계정

    • 그룹 C는 인터넷 포럼, 웹사이트, 개인정보를 존중하는 서비스, PII를 보유하지 않는 계정들을 포함함
    • 이 그룹에는 클라우드 서비스가 필요 없고 원하지도 않음
    • KeePassChi, KeePassXC, KeePassDX를 사용하고, 데이터베이스 파일은 Syncthing으로 기기 간 동기화되는 폴더에 둠
    • 이 접근은 과거 Syncthing으로 탈중앙 Dropbox를 만드는 글에서도 다뤄짐
    • .kdbx 파일 자체가 암호화돼 있으므로, Syncthing이 침해되고 공격자가 파일을 얻더라도 쓸모 있는 정보를 얻으려면 KeePassChi/KeePassXC 암호화를 깨야 함
    • 모바일에서는 _Android_의 KeePassDX가 같은 파일을 문제없이 읽음

  • 그룹 D: 인프라

    • 그룹 D는 서버 로그인과 SSH 키 같은 인프라 자격 증명임
    • 개인 자격 증명은 그룹 C와 같은 방식으로 저장함
    • 스크립트, CI 작업, 원격 서버가 실제로 쓰는 자격 증명은 HashiCorp Vault를 사용함
    • HashiCorp Vault는 OpenBSD 설정에서 PKI 용도로 이미 운영하던 도구임
    • 단일 사용자에게는 다소 과하지만, 접근 정책, 자동화 에이전트용 토큰 기반 인증, 지원되는 경우 짧은 수명의 자격 증명, 감사 로그를 제공함
    • _Infisical_도 검토 중임

  • 그룹 E: 일회성 자격 증명

    • 그룹 E는 API 키, 개인 액세스 토큰, 명령줄에서만 사용하는 임의 시크릿임
    • 오래된 pass 유틸리티를 사용함
    • pass는 각 시크릿을 Git 저장소 안의 개별 GPG 암호화 파일로 저장함
    • 구조가 단순하고 감사하기 쉬우며 셸 스크립트와 dotfiles와 잘 맞음
    • Git 저장소는 _GitHub_가 아니라 자체 인프라에 있으며, 다른 머신에서 실제로 접근해야 할 때만 수동 동기화함

단일 금고에서 여러 도구로 전환한 결론

  • 단일 금고 세계에서 온 사용자에게는 움직이는 부품이 많고 과한 구성처럼 보일 수 있음
  • 수년간 Bitwarden을 만능 솔루션으로 써 본 결과, one size fits all은 실제로는 one size fits poorly였다는 평가에 도달함
  • 자격 증명을 여러 도구로 나누는 작업은 처음 예상보다 훨씬 덜 고통스러웠고, 각 도구가 특정 작업에 더 잘 맞았기 때문임
  • 어떤 도구 하나가 침해되더라도 폭발 반경은 전체 자격 증명이 아니라 하나의 시크릿 범주로 제한됨

최종 판단

  • 수년간 Bitwarden을 자체 호스팅한 뒤, 제품은 처음 기대했던 방향에서 점점 멀어졌다고 봄
  • Raspberry Pi에 간신히 맞는 엔터프라이즈 우선 아키텍처, 반쪽짜리 가벼운 백엔드 시도, SDK 라이선스 논란, 느린 기능 처리 속도, 수년간 고쳐지지 않은 UX 문제, 애초에 배포되지 말았어야 할 보안 이슈들이 함께 “모두를 위한 오픈소스 비밀번호 관리자”라는 서사와 맞지 않는 그림을 만듦
  • 대안들이 보편적으로 더 낫거나 문제가 없다는 뜻은 아님
  • 비밀번호 관리자는 본질적으로 어렵고, 이 영역의 모든 플레이어는 각자의 문제를 갖고 있음
  • 모든 자격 증명을 단일 소프트웨어 하나에 얼마나 많이 신뢰하고 있는지, 그리고 그 베팅이 여전히 올바른지 엄격히 살펴봐야 하며, 이 경우에는 더 이상 올바른 선택이 아니었다는 결론에 도달함

관련 논의

함께 보면 좋은 글 β

▲
GN⁺ 1시간전  [-]
Lobste.rs 의견들

  • 탭을 바꾼 뒤 뜨는 JavaScript 끄기 플래시 메시지도 짜증나고, 바뀌는 탭 제목도 짜증남
    기본으로 JavaScript를 끄지는 않을 것임. 너무 많은 사이트가 깨지기 때문임
    평소 가는 사이트의 대부분은 광고 차단기로 충분하고, NoScript는 몇몇 못된 사이트에만 쓰는데 이 사이트도 그 목록에 들어간 듯함

    • 인터넷에서 글을 읽는 데 임의 코드 실행이 기본값으로 기대된다는 점은 정말 싫음
      공감은 하지만 누군가는 뭔가 해야 함. 말한 것처럼 이 사이트 하나보다 모든 곳에서 JavaScript를 켜두는 편의가 더 크지만, 언젠가는 그 편의가 임계점을 넘게 될 것임
    • 사무실에서 그 사이트가 “steve ballmer nude pics”를 “웃긴” <title>로 띄운 뒤로는 일부러 피하고 있음
    • 그냥 그 문체가 취향이 아님
    • 무슨 말인지 알겠고, 실제로도 기본으로 JavaScript를 켜두기 때문에 동의함
      다만 못된 사이트에 예외를 주지는 않고, 방문 기록에서 지우고 다시 안 가려고 함
      동시에 저자 쪽 의도도 이해됨. 단순히 트롤링하려는 게 아니라 “그래, 이건 못된 짓이다. 그런데 웹에서는 어떤 사이트든 기본적으로 이런 일이나 훨씬 더 나쁜 일을 할 수 있다는 게 말이 되나?”라고 말하려는 것처럼 보임
      JavaScript 덕분에 직업 경력 대부분이 가능했지만, 텍스트나 이미지뿐인 페이지가 아무 경고나 힌트 없이 임의 코드를 실행하고 CPU·대역폭·기타 자원을 무제한으로 쓸 수 있다는 건 꽤 미친 일이라고 봄

  • KeePassXC에도 찜찜한 부분이 있음
    AI 도구 사용이 비밀번호 관리자에 원하지도 필요하지도 않은 기능을 추가하는 속도를 높일까 걱정됨. 지금은 주로 버그 수정에 쓰이는 것 같지만, 대부분의 버그를 고치고 나면 다음이 뭔지는 뻔함. 유혹이 너무 큼
    최근에는 “인라인 첨부 뷰어에서 더 많은 파일 형식 지원(이미지, HTML, Markdown), 텍스트 파일 첨부 편집 기능”을 추가했는데, 그런 코드를 비밀번호 관리자 안에 넣고 싶지 않음. 텍스트 편집기도 있고 파일을 보는 앱도 있음
    1Password와 치열하게 경쟁 중이니 가능한 최고의 사용자 경험에 집중하면 됨. 아직 KeePassX? KeePassChi? ChiPass? 개발자들을 신뢰할 준비도 안 됐음

  • 거의 모든 곳에서는 자유·오픈소스 소프트웨어를 선호하지만, 비밀번호 관리자는 한동안 1Password를 써왔음
    이 분야만큼은 돈을 아끼지 않기로 했고, 구독 모델 덕분에 회사의 사업 모델이 무료 티어에서 업셀링하는 게 아니라 실제로 작동하는 제품을 파는 쪽이라고 판단했음
    오픈소스였으면 좋겠지만, 그와 별개로 기기 간 동기화는 안정적이고 브라우저 확장도 문제없이 제 역할을 함

    • 예전에는 1Password의 오랜 팬이었고 10년 넘게 썼음
      내 데이터를 자기들 서버에 저장하는 대신 직접 동기화 수단을 가져오는 방식을 사실상 막았을 때가 마지막 한계였음
      당시 Apple이 아닌 클라이언트도 별로였고, 비 Apple 플랫폼을 점점 더 많이 쓰게 된 것도 영향을 줬음. 최근 몇 년간 그쪽은 개선된 것 같지만 다시 시도해보진 않았음
      떠난 이유는 돈 때문이 아니었음. 지금은 데이터 저장을 직접 호스팅하는 VaultWarden으로 하면서도 Bitwarden에 돈을 냄
      자유·오픈소스를 선호하긴 하지만, 이런 도구에서는 데이터가 어디에 저장되는지 통제할 수 있는지가 절대 기준임
    • 특정 상황에서는 아직도 동기화가 실패함
      Android 기기 말고 다른 곳에서 자격 증명을 바꾸면, 그 뒤 Android에서 처음 1Password를 사용할 때 새 값이 동기화되기 전에 예전 자격 증명을 채워 넣음
      첫 로그인은 실패하고, 이유를 깨닫고 두 번째로 시도하면 그사이 동기화가 끝났을 때 성공함. 매번 짜증남

  • Bitwarden에 대한 반대 논거에는 대체로 동의하지만, 제기된 문제 중 상당수는 그리 큰 문제가 아니고 일부는 VaultWarden이나 GrapheneOS 같은 맞춤 구성에서 비롯된 것 같음
    Bitwarden을 5~6년 정도 써왔고, 겪은 유일한 문제는 브라우저 확장 UI 개편 뒤 한동안 느렸던 것 정도였음. GitHub 릴리스에서 예전 버전 확장으로 내리고 몇 달 쓰는 식으로 해결했음
    그렇게 긴 글을 썼다면 전환할 SaaS 대안도 실제로 언급해줬으면 좋았음. 독자가 직접 조사하면 자기에게 맞는 SaaS 비밀번호 관리자를 고를 수 있어 결과적으로 나을 수도 있지만, 그래도 성가심
    무료 호스팅, 오프라인 지원, 클라우드 자동 동기화, 자동 입력 단축키가 있는 브라우저 확장, 모바일 앱을 제공하는 다른 비밀번호 관리자, 가능하면 오픈소스 대안이 있으면 들어보고 싶음
    조금 찾아보니 대안을 찾는 사람에게는 Proton Pass가 위 조건을 모두 만족하는 듯함. 언젠가 시도해보겠지만 지금은 Bitwarden이 잘 맞음

    • 공식 Bitwarden 구성만 써왔는데, 그중 한 지적은 맞아 보임
      Bitwarden 안에서 항목을 정리하는 건 거의 제정신이 아님
      조직 사이에서 항목을 옮기도록 열을 끌어다 놓는 정도만 있어도 훌륭할 텐데, 지금은 제한된 시스템만 남아 있음
      돈 내고 쓰는 소프트웨어에서 실제 해결책이 직접 관리 도구를 만드는 것뿐이라는 게 웃김
    • Firefox에서는 아직도 엄청 느려서, 확장을 버리고 데스크톱 앱을 쓰게 됨
    • 명령줄 관련 문제는 rbw로 모두 해결됨
      비교적 최근에 발견했고 완전히 갈아탔음

  • pass “표준 UNIX 비밀번호 관리자”도 좋음. 10년 넘게 써왔음
    https://www.passwordstore.org/

  • Bitwarden을 쓰고 있어서 이 글이 그만 쓰도록 설득하고 더 나은 접근을 제안해주길 기대했음
    그런데 이렇게 긴 글을 쓸 시간을 들였는데도 아주 사소한 불만 외에는 없고, 훨씬 나은 제안도 없다면 오히려 Bitwarden에 대해 더 안심하게 됨

    • 거의 실망스러울 정도임
      Bitwarden은 패스키로 저장소 잠금 해제를 구현함. 기억해야 했던 마지막 암호구였음
      대안이라면 적어도 그 정도는 해야 함

  • Bitwarden 사용자로서 추천함
    저렴하고 필요한 기능을 다 제공하며, 자유·오픈소스 소프트웨어임
    비밀번호 관리 솔루션 5개, 명령줄 도구 4개, 마스터 비밀번호 3개를 쓸 시간은 없음. Bitwarden은 꽤 훌륭함
    1Password에서는 완전히 사악한 기운이 풍겨서 엮이고 싶지 않음

    • Chrome, 자체 호스팅 KeePass 동기화, Firefox를 거쳐 이제 Bitwarden에 왔음
      전환하고 가족과 공유하기에는 확실히 가장 쉬웠음. 구독료도 아주 쌈

  • Bitwarden처럼 자격 증명 공유를 지원하는 다른 오픈소스 솔루션이 있나?
    15년 넘게 KeePass/KeePassXC를 써왔지만, 개발자가 아닌 팀원이나 가족과 자격 증명 묶음을 공유해야 할 때는 Bitwarden보다 나은 해법을 찾지 못했음
    Bitwarden을 좋아한 적은 없지만, 자격 증명 저장소와 공유·동기화 측면에서는 늘 가장 덜 나쁜 선택지였음

    • 얼마 전에 Passbolt[0]를 찾았음
      Bitwarden처럼 기업용 느낌이 나지만 흥미로워 보임. 실제로 좋은지는 모르겠지만 Bitwarden 대안이 될 수는 있어 보임
      [0]: https://www.passbolt.com/
    • 모든 비밀번호는 마음에 드는 다른 비밀번호 관리자로 옮기고, 공유 자격 증명만 Bitwarden을 계속 써도 됨

  • 한동안 keepassXC와 keepassDX를 쓰고 있음. 이름들이 정말 바보 같음
    언젠가 ChiPass로 옮기게 되길 기대 중임

  • GPG라면… 아마 자기 자신에게 RSA로 암호화하는 방식일 듯?
    age를 쓰는 게 좋음

답변달기