先に結論です。AES-256-GCM が答えるのは「保存ファイルのパスワード欄が平文か」です。「誰がその鍵を持っているか」は答えません。Google は 2024年7月30日、Windows の DPAPI は他のユーザーとコールドブート攻撃を止め、今ログインしているユーザーとしてコードを実行できるプログラムは止めないと書いています。Chrome 127 はまず Cookie をアプリバインド暗号化へ移し、扉を「ユーザー」から「ブラウザのプログラム」へ狭めました。どちらの世代も、「この端末の任意のプログラムは読めない」ではありません。
検索意図に一文で答える
「ブラウザに保存したパスワードは暗号化されているから、マルウェアにも見えない」と検索する人が確かめたいのは、たいてい同じ一点です。保存を押したあと、このパソコン上の他のプログラムは平文を読めるのか。アルゴリズムの名前は、その問いに答えません。Google のセキュリティブログは、Windows 上の旧来の境界をそのまま書いています。Chrome は Cookie やパスワードのような機微なデータを、OS が用意するデータ保護 API（DPAPI）で守る。守る相手はシステム上の他のユーザーと、コールドブート攻撃です。今ログインしているユーザーとしてコードを実行できるプログラムは、その扉の外にいません。
想定している読者は二種類です。一つは、「ブラウザが暗号化して保存しているのだから、パスワードのディスク書き込みはもう見なくてよい」と確認している開発者と運用担当です。もう一つは、ここ数日のセキュリティ報道を見て、設定画面の「暗号化済み」が何を証明するのかを知りたい人です。他人の保存パスワードから平文を取り出す手順は書きません。パスワード生成の操作説明にもしません。確認してほしいのは、別々に照合できる三層です。暗号文が証明すること、鍵の保護方式が証明すること、そして 2026年9月25日の報告が証明していないこと。
ディスク上の AES-256-GCM が証明するのは、平文ではないこと
Chromium 系のブラウザは、保存したログインをこの端末のプロファイルへ書きます。比較的新しいパスワード欄は AES-256-GCM で包まれます。その保存ファイルをテキストエディタで開いても、サイトのパスワード原文は見えません。これは本当です。ここでの GCM の仕事は、対応する鍵がなければ 1 バイト変えても検証に失敗し、暗号文を、こっそり書き換えられる平文のようには扱えない、ということです。
ブラウザは次にログイン欄を開いたとき、そのパスワードを埋め戻さなければなりません。だからこの鍵は、本人だけが覚えているパスフレーズの中だけに置く設計にはなりません。この端末のブラウザが、ロックを外したセッションのあとで取り出せる必要があります。問いの中心は「アルゴリズムが強いか」から、「誰がシステムにこの鍵を要求できるか」へ移ります。アルゴリズムがどれだけ強くても、資格が「すでにログインしているこの Windows ユーザー」にあるなら、そのユーザーとして起動したプログラムはブラウザと同じ側に立ちます。
これが、「自分で持っているパスフレーズによるローカル暗号化」と同じ文ではない理由です。ファイルを、自分が入力したパスフレーズでブラウザ内の AES-256-GCM にかけるなら、クラウドも他のプログラムもその文字列を初期状態では持たず、ファイルを開けません。ブラウザのパスワード保存が目指しているのは自動入力です。鍵を使う資格は、この端末のブラウザ側に残します。同じアルゴリズム名を見ただけで、二種類の鍵の帰属を一つの話にまとめられません。
Google 自身が書いた境界
同じ 2024年7月30日の説明は、OS ごとの差も書いています。macOS はキーチェーン、Linux はシステムが用意するウォレット（kwallet や gnome-libsecret など）、Windows は DPAPI です。以下の「今ログインしているユーザーが起動したプログラム」という一文は、Google が Windows の DPAPI について書いたものです。すべての Mac へそのまま当てはめないでください。キーチェーンはシステムの確認を出せます。境界は「同じユーザーのプロセスなら黙って解ける」という対話と同じものではありません。
Windows では、DPAPI が鍵を、そのユーザーのログイン資格情報へ結びます。別の Windows アカウントが自分のプロファイルを開いても、シャットダウン後にディスクを持ち出し、自分のログオン情報を持たない人が開いても、初期状態では解けません。製品説明の「暗号化している」のうち、ここまでが一番はっきり成立する半分です。もう半分は、Google が明記した限界です。悪意のあるプログラムがすでに今のユーザーとして実行できるなら、ブラウザと同じシステム API へ鍵を要求できます。暗号化が壊れたのではありません。扉の位置が、もともと「他のユーザー」に引かれていて、「このユーザーの他のプロセス」には引かれていなかった、ということです。
だから「保存パスワードは AES-256-GCM なので、ローカルの悪意のあるプログラムは読めない」を確認するときは、分けます。前半は、保存ファイルが平文ではないことで支えられます。後半は、DPAPI のこの世代では Google の公開説明と逆です。別に証拠が要るのは、このブラウザがその種の秘密を次の扉へ移し終えたかどうかです。アルゴリズム名そのものではありません。
Chrome 127 は境界を「ユーザー」から「プログラム」へ狭める
同じ説明は続けて、Chrome 127 が Windows にアプリバインド暗号化を入れる、と書いています。データは「今のユーザーとして動く任意のプログラム」が解ける状態から、鍵をブラウザのプログラムの身元へ結び、システム側の部品が呼び出し元を信頼できるブラウザだと確認してから鍵を渡す状態へ移します。公式が書いた移行の順は、まず Cookie からです。パスワード、決済データ、その他の永続的なログイントークンは、その後の版で広げる対象であり、127 の公開当日にすべて移り終わったものではありません。
2026年に入ってからのフォレンジック側の公開記述（例：ElcomSoft の 2026年1月13日の説明）では、アプリバインドが有効な新しい Chrome と Edge のプロファイルに対し、旧来の「今のユーザーとして解く」だけを行う外部プログラムは失敗します。この新しい扉が止めるのは、ブラウザの外に立つ普通のプロセスです。ブラウザプロセスの内側までは外へ出していません。悪意のある拡張機能や、すでにブラウザプロセスの中で実行しているコードは、扉の中に残ります。アプリバインドが変えるのは呼び出し元の資格です。「AES-256-GCM と書いてあれば、メモリ上の自動入力もパスワードを見ない」ではありません。
だから、互いに置き換えられない文が二つあります。一つ目は「自分の Chrome は 127 より新しいから、保存パスワードは必ず移り終わっている」。公式は 2024年7月にパスワードを拡張対象と書いたので、バージョン番号でこの項目を自動的にチェックできません。二つ目は「ニュースではまだ旧来の解き方でパスワードを読んだ例があるから、アプリバインドは役に立たない」。それは、まだ旧境界に乗っている構成やデータがあること、またはその検体の記述が旧境界そのものであることまでです。「新しい境界が公開の文章で無効になった」ことの証明にはなりません。
| 見えている言い方 | 支えられる結論 | 支えられない結論 |
|---|---|---|
| パスワード欄は AES-256-GCM | 保存ファイルの中は平文のパスワードではない | この端末の任意のプログラムが読めない |
| Windows は DPAPI で鍵を包む | 他のユーザーと、コールドブート後のディスク持ち出しは初期状態で解けない | 今ログインしているユーザーが起動したプログラムは解けない |
| Chrome 127 のアプリバインドは、まず Cookie | 移行済みのデータでは、外部プログラムの旧来の復号が失敗する | この端末のパスワード欄が必ず移行済みである。プロセスの内側も読めない |
| パスワードマネージャーに一件ある | そのサイトは一度保存された | いま鍵の保護方式がどの世代か |
| 「パスワードを保存するか確認する」を切った | このあとの新しいログインは一覧へ入れなくてよい | すでに一覧にある記録が消えた |
9月25日の報告が証明できること
K7 Labs は 2026年9月25日、ある種の Windows プログラムの分析を公開し、その後数日で複数のセキュリティメディアが転載しました。報告によれば、そのプログラムは複数の Chromium 系ブラウザから保存パスワード、カード記録、閲覧履歴、セッションを読み、Firefox の履歴と Cookie も読みます。比較的新しいパスワード欄は AES-256-GCM で置かれ、鍵は Windows のユーザー単位のデータ保護で解きます。公開ページには被害台数はなく、配信がどこまで広がったかの数字もありません。
この記述は、前の節の旧境界と揃います。資格は「今のユーザー」にあり、同じログイン中のプログラムは扉の内側に立てます。AES-256-GCM が担うのは、欄が平文ではないことです。報告は「Chrome のアプリバインド暗号化をすでに回避した」とは書いておらず、「あなたの Chrome は必ず被害に遭った」へ置き換えられる被害台数も出していません。見出しのアルゴリズム名を「暗号化はもう効いていない」と読むのも、「だから自分の保存パスワードは絶対に安全」と読むのも、報告が書いていないところまで進んでいます。
報告が思い出させる、混ざりやすいもう一つの材料があります。セッションと保存パスワードは別です。セッションが持ち出されると、攻撃者はしばらくの間、すでにログイン済みの状態をそのまま使えます。元のサイトでパスワードを変えて無効になるのは、次のパスワードログインです。すでに発行されたセッションが同時に消えるとは限りません。セッションを扱うなら、アカウントの端末またはセッション一覧からログアウトするか、サイトが自ら失効するのを待ちます。これは「保存パスワードの暗号化が強いか」とは別の話です。パスワード変更が、すでに渡したセッションや相手側で登録された認証手段を同時に消すとは限らない、という照合は、パスキーを口実にした電話の記事にあります。二つの話を一つのスイッチにまとめないでください。
ニュースが本当かを確かめるために、自分の保存パスワードを解かないでください。本物のネットバンキング、メール、クラウドコンソールのパスワードで実験もしないでください。下の照合が見るのは、設定に保存記録があるか、保存の確認がまだオンか、だけです。平文を表示すること、保存データ全体を書き出すことは、この記事の照合の範囲外です。
その場で照合する。一覧を見て、データベースは解析しない
スローガンもニュースの見出しも、このブラウザの設定の代わりにはなりません。捨ててよいテスト用サイトのアカウントを一つ用意すれば足ります。次の四歩は今のブラウザの中で終わり、プロファイルのディレクトリをコピーする必要はありません。
- ブラウザ内蔵のパスワードマネージャーを開きます（設定の「パスワード／自動入力」、またはアドレスバーからそのブラウザのパスワード管理ページ）。見るのはサイトの一覧だけです。メール、ネットバンキング、クラウドコンソール、ソースコードのホスティングがそれぞれ一行あるか。平文の表示は押さず、書き出しもしません。
- 「パスワードを保存するか確認する」か、それに相当するスイッチを見つけます。これが、次のログインを再び一覧へ入れるかを決めます。切っても、すでに存在する記録は消えません。消すなら一覧で一件ずつ外すか、ブラウザが用意している保存パスワードの消去を使います。
- 「このブラウザについて」を開き、公式の更新をまだ受け取っていることを確認し、バージョン番号を控えます。バージョン番号は、パスワード欄がアプリバインドへ移ったことの証明にはなりません。設定画面も DPAPI やアプリバインドという語を印刷しません。そのためにプロファイル内の鍵の接頭辞を掘らないでください。
- このパソコンが、出どころの分からないプログラムをすでに動かしていると思うなら、この端末で「パスワードを表示」を押さないでください。まだ信頼できる別の端末へ移り、重要なサイトで他のセッションをログアウトし、パスワードを替えます。サイトごとにパスワードを使い回しません。この一歩が扱うのは影響です。この端末で保存パスワードを解いて「本当に読めるか見てみる」ことではありません。
バージョン番号は、鍵がどの世代かを答えない
Chrome 127 は、アプリバインドが Cookie を覆い始めた版です。「すべての保存パスワードがこの日に保護方式を変えた」版ではありません。130、140、それ以上を見ても分かるのは、メジャーバージョンがその起点より後だということまでです。パスワード欄が移り終わったかは、公式説明が「その後の版」という範囲を残しており、画面も保護方式の世代を出しません。バージョン番号を確認メモへ写すなら、横には「これでは保存パスワードがアプリバインド済みだと断定できない」と書きます。チェックを一つ入れる場所ではありません。
保存の確認が、一覧へ入れるスイッチ
多くのパスワードが一覧へ入る理由は、どこかの暗号化ページが「同期でアップロードした」からではありません。ログイン成功後にブラウザが保存するかを聞き、人が保存を押したからです。そのあと、その記録は上で話した扉の内側に落ちます。この端末にだけ現れたパスワードを生成し、保存を断れば、それはパスワードマネージャーの新しい一行にはなりません。保存を断ったことは、ページのスクリプトがパスワードを送り出していない証明にはなりません。それは Network で別に照合します。証明できるのは、その文字列をブラウザの保存パスワード一覧へ渡さなかったことだけです。
「暗号化済み」を読み過ぎる四つの場面
一つ目は、AES-256-GCM を「悪意のあるプログラムは読めない」と読むことです。このアルゴリズムが示すのは、欄が平文ではないこと、そして鍵がなければ暗号文を書き換えられないことです。鍵を DPAPI で今のユーザーへ包んでいるなら、Google はすでに書いています。そのユーザーとして動くプログラムは、保護の外にいません。アルゴリズム名と扉の位置は、別の二文です。
二つ目は、「Windows のログインパスワードがある」を「保存パスワードはマルウェアから安全だ」と読むことです。ログインパスワードの仕事は、別のアカウントとコールドブート後のディスク持ち出しが DPAPI を解けないようにすることです。プログラムが自分のログイン後に動いているなら、それが使うのはすでにロックの外れたこのユーザー環境です。ログインパスワードは引き続き設定します。それが答えるのは、もう一つの扉です。
三つ目は、「バージョンが 127 より新しい」を「保存パスワードも Cookie もアプリバインド済みで、プロセスの内側も見えない」と読むことです。公式が書いた起点は Cookie で、パスワードは拡張対象です。アプリバインドが止めるのは、ブラウザの外からの旧来の復号です。拡張機能と、すでにブラウザプロセスの中で実行しているコードは、この扉のおかげで突然見えなくなるわけではありません。
四つ目は、「サイトごとに違うパスワードを使っている」を「保存データ全体を読まれても大丈夫」と読むことです。違うパスワードが止められるのは、一つのサイトから漏れたあと、同じ文字列で自分のメールとクラウドコンソールを試されることです。止められないのは、プログラムがパスワードマネージャーの保存記録を一度に読むことです。二つの対策は、どちらもやる価値があります。防ぐ失敗は同じ種類ではありません。
よくある質問
パスワードマネージャーに暗号化済みと出ていたら、この端末の他のプログラムは読めませんか？
その読み方はできません。暗号化済みは、ディスク上のパスワード欄が平文ではないことまでです。Windows の DPAPI のこの世代について、Google は他のユーザーとコールドブート攻撃を止め、今ログインしているユーザーとして動くプログラムは止めないと書いています。Chrome 127 からのアプリバインドはまず Cookie を覆い、移行済みデータに対する外部プログラムの旧来の復号は失敗します。ブラウザプロセスの内側は、依然として読めます。画面の「暗号化済み」という表示は、この端末のパスワード欄がどの世代に乗っているかを教えません。
Chrome 127 のアプリバインド暗号化は、悪意のあるプログラムも保存パスワードを解けない、という意味ですか？
そうではありません。2024年7月30日の説明は、パスワードと決済データを、その後の版で広げる対象として書いています。アプリバインドは資格を「今のユーザー」から「システム側の部品が認めたブラウザのプログラム」へ狭めます。これで説明できるのは、旧来のユーザー復号だけを歩く外部プログラムが、移行済みのデータで失敗する理由です。プロセス内側のコードが扉の外へ出されたことや、このブラウザの保存パスワードが一件残らず移行済みであることは、説明しません。
9月25日の報告は、自分の Chrome のパスワードが任意のプログラムに読まれる、という意味ですか？
その結論へ直接置き換えられません。報告が記述しているのは、ある種の Windows プログラムが複数の Chromium 系ブラウザの保存パスワード、カード、履歴、セッション、および Firefox の履歴と Cookie を読み、パスワード欄は AES-256-GCM、鍵はユーザー単位のデータ保護を通る、ということです。被害台数はなく、その検体がアプリバインド暗号化を回避したとも書かれていません。自分のブラウザがどの世代に乗るかは、保存一覧と更新が続いているかで見ます。この報道のアルゴリズム名で代用しません。
サイトのパスワードを変えたあと、すでに保存されたセッションも一緒に無効になりますか？
必ず一緒、ではありません。パスワード変更が無効にするのは、次にその文字列でログインすることです。すでに発行されたセッションは、アカウントの端末一覧で他のセッションをログアウトするか、サイトが失効させるまで残ることが多いです。同じ種類のプログラムは、セッションと保存パスワードを一緒に持ち出します。一箇所のパスワードだけ変え、他のセッションをログアウトしないなら、扱っているのはパスワードであり、セッションではありません。
開いてすぐ使える生成で、「一覧へ入れない」を一度照合する
「パスワードが画面に出たこと」と「パスワードがブラウザのパスワード保存へ入ったこと」が同じ一歩ではない、と見たいなら、FastPwd の パスワード生成 を開きます。登録は不要です。ランダムモードは初期値の 16 文字で、捨ててよいパスワードを一つ作ります。ブラウザが保存の確認を出したら、保存しないを選びます。パスワードマネージャーへ戻ったとき、さっきのテスト用サイトが新しい一行になっていないはずです。FastPwd 自身はパスワード保管庫を持たず、ブラウザの保存パスワード一覧へ代わりに書き込みません。
生成は crypto.getRandomValues を使います。長さは 6〜128 文字、初期値は 16 文字、8 文字未満では安全性が低いと示します。結果は初期状態ではアップロードしません。開発者ツールの Network を開き、ログを保持にチェックし、文字列全体でリクエスト行とリクエスト本文を検索します。業務リクエストにこの文字列は出ないはずです。この一歩が証明するのは、「今回は HTTP の本文としてタブを出なかった」ことまでです。この端末の悪意のあるプログラムがページやクリップボードを読めないことは証明しません。このパソコンがすでに信頼できないなら、別の端末で生成し、別の端末でログインします。
生成したあと、この文字列が公開の高頻度一覧にある弱いパスワードに似ているかを見るなら、別の捨ててよいテスト文字を取り、パスワード強度チェック で照合します。対象のパスワードはアップロードしません。当たらなかったことは、ウェブのどこにも出ていない証明にはなりません。当たったことは、ありふれていすぎる、ということまでです。これから使う本物のパスワードを検査欄へ貼らず、ブラウザの保存パスワードを書き出して検査へ持っていかないでください。
このパスワードを一度だけ別の人へ渡す必要があるなら、サーバーのログに残るチケット本文へ貼らず、ワンタイムリンク へ切り替えます。サーバーが一時保存するのは暗号文だけ、鍵はリンクの # の後ろ、作成も閲覧もアカウントは不要です。形は s.html?id={id}#{key} です。その経路が答えるのは「どう一度渡すか」です。「ブラウザにすでに保存された古いパスワードを安全にする方法」ではありません。古い記録はパスワードマネージャーで消し、信頼できる端末で替えます。
関連記事
ページ上の「ローカル、アップロードしない」は、カナリアを Network で検索して照合します。ブラウザのローカル暗号化で、平文が端末を出ていないことを確認する。パスワードを変えても、すでに発行されたセッションが同時に消えるとは限らない話は、『パスキーを今すぐ更新しろ』という電話が、パスキーではなくセッションを盗む理由。ローカルの弱いパスワード一覧がよくある弱いパスワードを捕まえ、全ウェブの照会にはできない話は、ローカルの弱いパスワード一覧が証明できること、それが全ウェブ照会ではない理由。