セキュリティ
ブラウザがボールトではないことの証明。
ChromeとFirefoxはパスワードを保存し、その後、ユーザーとして実行されているあらゆるプログラムにそれを渡します。これはバグではなく、仕様です。ここにその証明を示します。平易な言葉での説明と、コードでの説明です。
平易な言葉での説明
ブラウザの「パスワードマネージャー」は、コンピューターへのログインというたった1つのロックによってのみ保護されています。ノートパソコンにサインインすると、ブラウザは保存されたすべてのパスワードを即座に読み取ることができます。つまり、あなたのアカウントで実行されている他のあらゆるものも同じように読み取れるということです。
悪意のあるダウンロード。怪しいブラウザゲーム。クローンしたプロジェクトに含まれた1つの汚染されたパッケージ。それが実行された瞬間、つまり常にそうであるようにログインしている状態で、ファイルを開くほどの時間で、ブラウザが保存したすべてのパスワードが読み取られます。解除すべきマスターパスワードはありません。解除するものがないからです。ブラウザはユーザーのために自動的にロック解除するように作られており、マルウェアは「ユーザー」として普通に要求するだけです。
これは理論上の話ではありません。一般ユーザーがアカウントを奪われる最も一般的な方法です。このマルウェアには「インフォスティーラー（情報窃取型マルウェア）」というありふれた業界名さえあります。それほど日常的な手口だからです。パスワード、保存されたカード情報、セッションCookie。気づかないうちにコピーされ、持ち去られます。
解決策は単純明快です。パスワードは、コンピューター上の他のものが持っていないものでロックすべきであり、そもそもマシン上に保存すべきではないということです。
証拠付きの説明
私たちの言葉を鵜呑みにする必要はありません。ChromiumとFirefoxはオープンソースであり、読み取りパスは文書化された標準的で短いものです。パスワードがどこにあり、どのように取り出されるかを正確に示します。
Chrome（およびすべてのChromiumブラウザ）
Chromeはログイン情報をSQLiteデータベース（Login Data、loginsテーブル、password_value列）に保存し、AES-256-GCMで暗号化します。AES鍵はLocal Stateに存在し、OSによって「保護」されています。WindowsではDPAPI、macOSではログインキーチェーン、Linuxではgnome-keyring/kwallet（または平文）です。
ご自身で確認してください。コードは公開されています。ラップされた鍵にタグを付ける定数についてChromiumを検索してください：os_crypt内のkDPAPIKeyPrefix。鍵はDPAPIでラップされ、タグ付けされて保存され、その後、あなたからは何も保護しない単一の呼び出しでアンラップされます。
const char kDPAPIKeyPrefix[] = "DPAPI";
CryptUnprotectData(&intermediate, /*ppszDataDescr=*/nullptr,
/*pOptionalEntropy=*/nullptr, nullptr, nullptr, 0, &output);第二のシークレットも、パスワードも、プロンプトもありません。CryptUnprotectDataは、セッション内で実行されているあらゆるプロセスに鍵を渡します。これこそがDPAPIが文書化している脅威モデルそのものです。ユーザーとして実行されるものは、ユーザー自身なのです。攻撃者の作業はたった3行です。Local Stateから鍵を読み取り、アンラップし、Login Dataのすべての行をAES-GCMで復号します。インフォスティーラーマルウェアは、何年もまさにこれを行ってきました。
「デバイス上の暗号化」もあなたを救わない
Googleの解決策は、同期されたボールトを暗号化する6桁のPINです。2026年5月、Phishuの研究者たちは、その保護がいかに脆弱かを示しました。説得力のある偽のGoogleサインイン（中間者フィッシング）によってセッションとPINがキャプチャされると、そのPINが同期されたアカウントのすべてのパスワードとパスキーのマスターキーそのものになります。それを使えば、攻撃者は自身のデバイスをあなたのGoogle「セキュリティドメイン」に参加させ、ボールト全体が直接同期され、たった1ステップで完全に乗っ取られます。
設計上の欠陥：Googleは、すでに所有しているデバイスからの承認なしに、6桁のPINだけでデバイスを参加させることができます。
Firefox
Firefoxはログイン情報をlogins.jsonに、鍵をkey4.dbに保持し、NSSの「Secret Decoder Ring」によって復号します。これもオープンソースです：security/nss/lib/pk11wrap/pk11sdr.c。プライマリパスワードを設定している場合、鍵はそれでシールされます。
デフォルトでは設定されていないため、鍵は空の文字列でシールされており、保存された「password-check」値によって、空のパスワードで復号できることが確認されます。プロファイルから2つのファイル（key4.dbとlogins.json）をコピーし、NSSまたはオープンソースのfirepwd.pyを指定すれば復号されます。鍵がドアにテープで貼り付けられているロックは、ロックとは言えません。
すべてのブラウザのパスワードストアは同じ構造をしています。シークレットは作業場所に存在し、すでにログインしているセッションによってロック解除されます。自身のコンピューター上の他のプロセスが解除できる暗号化は、実際にアカウントを空にする脅威、つまりユーザーとして実行されるコードからは保護してくれません。
Clavitorがこのように読み取られない理由
Clavitorはマシン上にボールトを保持しません。Login Dataも、key4.dbも、Local State内の鍵も存在しません。ユーザーとして実行されるプロセスがスクレイピングできるものはディスク上に何もありません。
復号鍵はOSのログインでシールされていません。Touch ID、Face ID、またはYubiKeyといったハードウェアタップから導出され、ブラウザ内で計算され、単一の要求に使用された後、破棄されます。資格情報は、要求した瞬間にアクセス範囲を限定したAPI経由で取得され、キャッシュされることはありません。ユーザーとして実行されるマルウェアが見つけるのは、空っぽの棚だけです。
これこそが、「デバイス上で暗号化されている」ことと「デバイス上に全く存在しない」ことの違いです。
パスワードをブラウザに預けるのはやめましょう。
Clavitor拡張機能はブラウザと同じように入力を行いますが、ボールトはノートパソコンが読み取れない場所に保持します。