Bitwardenは勧めない

 (マリウス.com)
1 ポイント 投稿者 GN⁺ 2 시간 전 | 1件のコメント | WhatsAppで共有
  • 数年にわたってセルフホスティングで使ってみた結果、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 サブスクリプションであり、コミュニティは issue と翻訳を提供する役割にとどまる方向へ進んでいるように見える
  • 関連する批判として The freeware parts are bait もある

クライアントアプリが核心的な問題

  • バックエンドを除いても、Bitwarden の最大の問題は クライアントアプリケーション にあるとされる
  • うたわれている機能が期待どおりに動作せず、リリースから10年たっても基本機能が欠けており、同価格帯の代替製品と比べるとユーザーインターフェースも良くないという評価がある
  • Bitwarden が純粋な FOSS コミュニティの努力の産物であればこうした欠点を大目に見ることもできるが、ベンチャーキャピタルの出資を受けた企業である以上、同じ基準は適用しにくい
  • コミュニティが官僚的な手続きに縛られているように見える点も、Bitwarden がコミュニティ主導の取り組みというより企業製品であることを示している

保管庫移行の問題

  • 約1年前、独占的なプラットフォームではなく年額課金でオープンソースソフトウェアを支援したいという考えから、競合製品から Bitwarden へ移行しようとするユーザーを支援した
  • 既存のパスワードマネージャーから新しい Bitwarden アカウントへ保管庫をインポートする過程で問題が発生し、GitHub のバグレポート によれば、少なくとも1つの保管庫ではインポートを成功させるためにかなり技術的な回避策が必要だった
  • 移行・インポート機能は Bitwarden のマーケティング資料やドキュメントの各所で宣伝されており、すでに複数のユーザーが同じ問題を経験していた
  • それにもかかわらず、Bitwarden はその issue を処理する代わりに、コミュニティフォーラムで別の議論を立てるよう求めたと受け取られた
  • こうした 企業的な官僚主義 はオープンソースソフトウェアらしさにそぐわず、オープンソースソフトウェアでも有料製品でも、宣伝されている機能が実際には動作しない状況では正当化しにくい
  • 同じインポートを Bitwarden のプロプライエタリな代替製品で試したところ、問題なく動作した

ボールト間で項目を移動できない

  • 移行の問題は初回インポートだけに限られない
  • Bitwarden 内で organization ボールトと individual ボールトの間で項目を移そうとしても、現時点では選択した項目を別の場所へ移動する適切な機能がない
  • ログイン項目が数件なら複製して修正できるが、数百件の項目を整理したり、組織を離れたり、複数の組織を統合したりする状況では、繰り返し作業が過剰になる
  • Bitwarden サポートとコミュニティスレッドが勧める公式の回避策は、元のボールトを暗号化されていない JSONとしてエクスポートし、ファイルを修正したうえで対象ボールトへ再インポートする方法である
  • この手順では、500件を超える認証情報が ~/Downloads や Dropbox、OneDrive、iCloud のようなクラウド同期ディレクトリに平文で置かれうるというセキュリティ上のリスクが生じる
  • エクスポートにはファイル添付が含まれず、ゴミ箱内の項目、パスワード履歴、タイムスタンプも落ちる
  • SSH キーファイル、ライセンスキー、画像形式の復旧コードのような添付ファイルや、コンプライアンス・監査用のパスワード履歴に依存する組織にとっては受け入れがたい方法である
  • 認証情報の単一の信頼できる情報源であるべき製品が、10年目になっても500件の項目を完全に別のボールトへ移すボタンを提供していない点は、エンジニアリング上の優先順位を示している

クライアント更新で機能が壊れる問題

  • Bitwarden はユーザーへの事前通知なしにクライアント更新を配布し、その更新によってクライアント側でボールトにアクセスできなくなることがある
  • 旅行中、夜通し接続していたスマートフォンで F-Droid が Bitwarden を更新し、翌朝には銀行ログインに必要だった Bitwarden アプリからボールトへアクセスできなくなっていた
  • 原因の特定には時間がかかり、bitwarden/android issue と Vaultwarden の議論を通じて状況を確認した
  • Bitwarden バックエンドをホストしていた UPDC を持っていたため、より悪い事態は避けられた
  • クライアントとバックエンドの間で破綻するプロトコル変更のように見える更新を押し出すやり方は無責任に感じられ、オフラインモードでパスワードマネージャーを信頼しなければならないユーザーにとって、Bitwarden は信頼できないという結論につながった
  • その後、Bitwarden クライアントの自動更新を無効化し、すべてのパスワードの最新スナップショットを KeePassChi、KeePassXC、KeePassDX ベースのローカルバックアップとしてエクスポートした
  • この問題は、Bitwarden 社員の主張とは異なり、Vaultwarden 固有の問題ではないと見ている
    • bitwarden/android リポジトリには類似の報告が複数ある
    • 2025.12.x リリースの回帰では、ログイン後にマスターパスワードを2回要求され、アプリがクラッシュしたという報告がある
    • 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を含み、そのサブドメインを第三者が制御しているなら、認証情報を盗まれる可能性があった
    • 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秘密鍵はスマートフォンに同期される必要はないが、プログラムから呼び出せるコマンドラインツールからアクセスできる必要がある
  • 1つのソフトウェアやプラットフォームですべてを解決しようとするのではなく、認証情報の束をより適切に区画化するほうが合理的である
  • セキュリティの観点からも、パスワードのグループを異なるソフトウェアやサービスに分ければ、データ侵害時の影響範囲を減らせる

認証情報の分類とツール選定

  • グループA: 専門・クライアントプロジェクト

    • グループAは、プラットフォームへのログインなど、専門業務・クライアントプロジェクト用の認証情報である
    • 適切な保管庫共有、クライアントが実際に使っているツールとの統合、SSO、企業端末向けブラウザー拡張、監査ログを提供し、ホスティング負担をなくすSaaS型パスワードマネージャーを使う
    • そのプラットフォームは独占的な製品なので普段なら好まないが、このグループの範囲はクライアント業務にのみ限定されるため、そのトレードオフを受け入れる

  • グループB: PIIを含むアカウント

    • グループBは、銀行口座やオンラインショップのように PII を含むアカウントの認証情報である
    • これらのアカウントには、すでに氏名、住所、生年月日、決済情報などの個人情報が含まれており、当のサービス自体も定期的に漏えいしていて、Have I Been Pwned でも確認できる
    • パスワードマネージャーの侵害が、攻撃者の知る情報を有意に増やすことにはならないと見ている
    • TOTP と Passkeys がある状況では、ここで重要なのはデバイス間での可用性、信頼性、オフライン機能である
    • グループAと自動的にまとめて侵害されないよう、別ベンダーの第二の独立したクラウド型パスワードマネージャーを使い、別のマスターパスワードと別の復旧メカニズムを用いる
    • 少なくとも1台の GrapheneOS 端末でモバイルアプリを動かす予定なので、Google Play Services に依存せず、可能であればオープンソース、またはソース公開クライアントを提供するソリューションを好む

  • グループC: PIIのないアカウント

    • グループCは、インターネットフォーラム、Webサイト、プライバシーを尊重するサービス、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 だったという評価に至った
  • 認証情報を複数ツールに分ける作業は、当初の予想よりはるかに苦痛が少なく、それぞれのツールが特定の仕事により適していた
  • どれか1つのツールが侵害されても、被害範囲は認証情報全体ではなく、1つのシークレット分類に限定される

最終判断

  • 長年 Bitwarden をセルフホストしたのち、この製品は当初期待していた方向から次第に離れていったと見ている
  • Raspberry Pi にかろうじて収まるエンタープライズ優先アーキテクチャ、中途半端な軽量バックエンドの試み、SDKライセンス論争、遅い機能対応速度、何年も修正されないUXの問題、そもそもリリースされるべきではなかったセキュリティ問題が重なり、「みんなのためのオープンソースパスワードマネージャー」という物語とは一致しない姿になっている
  • だからといって、代替製品が普遍的に優れているとか、問題がないという意味ではない
  • パスワードマネージャーは本質的に難しく、この分野のすべてのプレイヤーはそれぞれ問題を抱えている
  • すべての認証情報を単一のソフトウェア1つにどれほど信頼して預けているのか、そしてその賭けが今なお正しいのかを厳しく見直すべきであり、このケースではもはや正しい選択ではないという結論に達した

関連議論

関連記事

1件のコメント

 
GN⁺ 2 시간 전
Lobste.rs の意見

  • タブを切り替えた後に出る JavaScript を無効にしろ というフラッシュメッセージもうっとうしいし、変わるタブタイトルもうっとうしい
    デフォルトで JavaScript を無効にはしない。壊れるサイトが多すぎるからだ
    普段行くサイトの大半は広告ブロッカーで十分で、NoScript は一部の行儀の悪いサイトにしか使わないが、このサイトもその一覧に入ったようだ

    • インターネットで文章を読むのに 任意コード実行 がデフォルトで期待されているという点は本当に嫌だ
      共感はするが、誰かが何かしなければならない。言う通り、この1サイトよりもあらゆる場所で JavaScript を有効にしておく利便性のほうが大きいが、いつかその利便性が臨界点を超えるだろう
    • 職場でそのサイトが “steve ballmer nude pics” を「面白い」<title> として表示して以来、わざと避けている
    • 単純にその 文体 が好みではない
    • 言いたいことはわかるし、実際デフォルトで JavaScript を有効にしているので同意する
      ただし行儀の悪いサイトに例外は与えず、履歴から消して二度と行かないようにしている
      同時に著者側の意図も理解できる。単に荒らしたいのではなく、「そう、これはひどい行為だ。でも Web では どんなサイトでもデフォルトで こういうことや、もっとひどいことができるというのは本当におかしくないか？」と言いたいように見える
      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 構成しか使ってこなかったが、そのうちの1つの指摘は正しそうだ
      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 を使うのがよい