パスキーとは？偽サイトでは2段階認証のコードが通り、パスキーは使えなかった。ウェブ職TVの動画で確認

出典: 世界中で情報漏洩が止まらない！防ぐ手立ては……

なかじさんが取り上げたのは、連日の情報漏洩ニュースです。GoogleやAIを仕事で使う私の側も、漏洩させる側になりうる。侵入経路がいくつもある中で、なかじさんは「防げない」とこう語りました。

なかじさん（4:14〜）

「ま、で、どうしたら防げるのかみたいな話で言うと、ま、結論はね、防げないっす、これは。」

「絶対に防げる方法があればね、誰も苦労しないんですけど。」

私は「防げない」に賛成です。そこで止まらず、どの守りがどこまで効くのかを確かめる。全部を防げるつもりで使うより、この立場でAIに委ねます。

私は、毎日のようにAIからログインを聞かれて、うんざりしていました。10月8日に、この問題を全部なくしたいと頼んだのもそのためです。守りを増やすほど、確認する仕事が自分に戻ってくる。だから、先に知りたいんです。どの守りが、どこまで効くのか。

なかじさんは動画の前半で、システムの弱点だけでなく、従業員や業務委託先のパソコンからも侵入されると説明しています。どこかが破られれば、情報に届くという話です。

そこでAI秘書の凛ちゃんに、実験用の架空の銀行を動かしてもらいました。動かしたのは、自分のパソコンの中だけです。架空のアカウントだけで検証しました。

比べたのは、IDとパスワードだけ、2段階認証、パスキーというログインの守り方。偽サイトへ入力した時、何が渡り、どこで止まるのか。

動画が示した守り方の違いを、私の側ではブラウザで動かして確かめました。名前を覚えるだけでなく、働く場面まで知って選びます。流出ニュースそのものの聞き分け方は、流出ニュースを公式発表・専門家の見立て・感想に分けて聞く方法（AI仙人さんの動画）に書いています。

→ 使う入口を書き出す

Googleや仕事のAIサービスなど、使っているログインを書き出します。それぞれを「ID・パスワードだけ」「2段階認証」「パスキー」に分け、現在の設定画面で確かめましょう。

2段階認証を入れたら、偽サイトでも大丈夫なのかな。ここで確かめたいのは、コードを自分で打ち込むタイプの2段階認証です。なかじさんは、IDもパスワードもコードも偽サイトへ入れた場合について、こう語りました。

なかじさん（6:56〜）

「やっぱりフィッシングサイトとかね、すごく今問題になってますけど、フィッシングサイトとかそういうところでIDパスワード入れてで、2段階認証のやつも自分で入れちゃったらそれはそのまんま向こうに送信されるわけで、で、それで入られちゃうんで、やっぱり弱いですよね。」

コードを自分で入れる型の2段階認証は、偽サイトから本物へそのまま転送されると通る。この動きを、架空の銀行で確かめました。

2段階認証は、IDとパスワードだけより良い守りです。でも「コードがあるから大丈夫」で止めると、入力する相手の違いを見落としてしまう。

AI秘書の凛ちゃんが、架空の銀行そっくりの偽サイトにID、パスワード、数字6桁のコードを入力しました。偽サイトの裏から、本物役の架空の銀行へ転送する形です。

すると、ログインが成立。偽サイト側の記録には、入力したコードが残りました。その持ち主側から、架空の残高のデータまで読めたんです。

入力したコードが、そのまま本物へのログインに使われてしまったんですよね。30秒ほどで変わるコードでも、有効な間に渡してしまえば、本物へ通りました。

→ コードの前にアドレス

数字のコードを入れる前に、ブラウザのアドレスでサイト名を確かめます。届いたリンクだけを頼りにせず、普段使うブックマークから開き直して、目的のサービスか確認しましょう。

コードを渡してしまうなら、パスキーではどうなるのか。私が見たいのは、偽サイトを人が見破れるかより、ブラウザが止めるかです。なかじさんは、使えるサービスではパスキーが必須だと、こう語りました。

なかじさん（8:50〜）

「パスキーって仕組み的にパスワードと違ってパスキーって自分の端末の外に出ないものなので」

「サービスとかサイトがあるんだったらもうパスキー認証は必須だと思っていいかなと思います。」

「パスキーは必須」と言える理由は、偽サイトでは使えず、何も渡らないこと。その拒否は、人が怪しいと気づかなくても、ブラウザが勝手にやってくれます。

安心して委ねるには、信頼できる仕組みが先。間違ったページを開いても、本物向けの鍵を使わせない。ここが、入力したコードを転送できた時との違いです。

AI秘書の凛ちゃんが、パスキー登録後に偽サイトへ移り、本物の銀行向けのパスキーを要求しました。ブラウザが「このサイトでは使えない」と止めました（エラー名はSecurityError）。

偽サイト自身の名前で要求した場合も、使えるパスキーがなく、何も渡りませんでした。本物のページでは、同じパスキーでログインできました。つまり、渡す先を人の目で見分ける役を、ブラウザが引き受けます。

本物のサーバーは、パスキーの署名のほかに、どのページから来た操作か、今回のログイン用に出した確認用の値と合っているか、サイトの名前が一致しているかも調べました。

サイトの識別名と開いているページのドメインをブラウザが照合する、MDNのパスキー要求の仕様（PublicKeyCredentialRequestOptions）どおりです。

10月6日、YouTubeの許可を取り直す時、AIの作業に使っているアプリのブラウザではパスキーが使えないと考えて、AI秘書の凛ちゃんがChromeを指定して許可画面を開き直しました。パスキーを使える場所は、使うブラウザによって変わります。

今回の銀行は仮想の認証器での再現で、実機やクラウド同期は検証に含みません。それでも、この環境では偽サイトで止まり、本物で通る違いが出ました。

→ 対応している所から登録

使っているサービスのセキュリティ設定を開き、パスキーに対応しているものを選びます。登録案内に沿って設定し、普段使う端末とブラウザでログインできる所まで確かめましょう。

パスキーが偽サイトを拒否しても、乗っ取りの話は終わりません。なかじさんは、パスキーを使っていた会社の広告アカウントが乗っ取られた例を紹介し、入れていても完全に安全ではないと、こう語りました。

なかじさん（7:09〜）

「あの、パスキー対応するみたいな企業も増えてたりしますけど、でもパスキー入れててもそれで[完全に安全]かっていうとね、そんなことないんですよね。」

［　］は、字幕の誤変換を直した部分です。

「パスキーを入れていても完全ではない」。偽サイトで止まるところまで見た上で、この一言の中身を確かめます。

私が委ねるAIに求めるのは、わからないことを憶測しないこと。動画の広告アカウントの件は、どうやって入られたのか私には分かりません。だから、次の実験と同じ話だとは言いません。私がやったのは、ひとつだけです。ログイン後の証を渡したら、どうなるか。

AI秘書の凛ちゃんが、架空の銀行へパスキーでログインしました。その後、ログイン済みの証であるセッションCookieを、別のブラウザにコピー。

すると、認証なしで架空の残高のデータが読めました。新しいブラウザで、パスキーを使い直す必要がなかったんです。

一方、証のない別のブラウザでは、銀行は「ログインが必要」（401）と返して、残高を見せませんでした。同じ操作でも、証があるかどうかで結果が変わった。

パスキーで入った事実が、コピー後の証まで守ってくれるわけではなかった。だから私は、入口の設定と一緒に、ログインした状態がどこへ残るかも確かめます。

→ 残る場所を見つける

普段ログインしたままにしているブラウザを1つ決め、そこでログインしたままのサービスを5つまで、名前だけメモします。AIツールに連携を許可しているサービスも名前だけ。パスワードや証の中身は書きません。

Googleアカウントで入れるサービスが増えるほど、その入口から届く先も増えます。AIとの会話や仕事のファイルも、その先にある。なかじさんは、Googleアカウントの乗っ取りが他のサービスに及ぶことを、こう語りました。

なかじさん（9:54〜）

「それSNSもそうだし、ま、そのさっきのね広告のやつもそうだしそのいろんな例えばAI系のサービスとかもそうですけど例えば[ChatGPT]とかにGoogleアカウントとか入れるようにしてたらそれはGoogleアカウントで[乗っ取られたら]そこにも入られるわけで今までのログとか全部持ってかれます。」

［　］は、字幕の誤変換を直した部分です。

入口から、その後ろのサービスへつながる。私は、AIにログインを任せるほど、保存先を決めて数える必要があると考えます。

第4章では、ログイン後の証をコピーすると入れました。証の置き場所が多いほど、盗まれうる場所も多くなります。便利に入れることと、証の置き場所を把握することを、セットにします。

第1章で書いたログインの問題を、10月8日に、全部なくしたいとAI秘書の凛ちゃんに頼みました。10月9日に入れたのは、一度ログインして保存したものを、繰り返し私に聞かない仕組みです。使う直前に、開きたい画面を開いて、正しいアカウントで入れているかを毎回確かめる形です。

10月11日に、AI秘書の凛ちゃんが私のログインの一覧を数えました。登録されたサービスは60件です。このうち、保存したログインで開けると確かめ済みなのは8件。確かめきれていないのが44件で、内訳は、まだ開いて見ていないのが38件、開いてみたけれどログイン済みか判定できなかったのが6件です。残りの8件は、ログイン待ちか期限切れ、保存待ちでした。ログインを置いている場所は、種類で数えて16でした。60件のうち、Googleのログインで入っているものが何件かは、数えていません。認証情報の数え方は、パスワードを変える意味と、認証情報の台帳の数え方（西尾素己さんの動画）にも書きました。

秘密の言葉の扱いも決めています。同じ10月9日に、LINEの連携で使う秘密の言葉を、Macの保管庫（Keychain）に入れました。AIには言葉そのものを見せず、決まった窓口が代わりに答える形です。

LINEの連携の作業でAIが残した記録（約5万トークン分）を調べたところ、LINEの秘密の言葉と、AIの連携に使う鍵（APIキー）の値は、どちらも0回でした。AIにパスワードを見せない方法は、1PasswordでAIにパスワードを見せない使い方（堀口英剛さんの動画）にあります。

この秘密の言葉では、AIに値を見せない形にできました。認証情報を画面へ出さず、AIにも読ませない。この形が、私が委ねる土台です。

動画が扱った乗っ取りの広がりに対し、私は保存先も数えました。入口と保存先、両方を把握して使います。

→ Googleで入る先を数える

Googleアカウントの設定にある、Googleでログインしているサービスの一覧を開き、件数を書き出します。メモするのは名前と件数だけ。パスワードや証の中身は書き込まずに確認しましょう。

最後になかじさんが挙げたのは、ITリテラシーでした。組織の誰かが引っかかれば侵入され、研修だけで守られるとも限らない。なかじさんは、この状況でできることについて、こう語りました。

なかじさん（14:41〜）

「ま、無理というかもうこれね、結局やれることって、え、ITリテラシーを高めるというぐらいしかないかなとは思いますね。」

「ITリテラシーを高める」に賛成です。私はそれを、気をつけなくても止まる所を増やすために使います。知って終わりにせず、ログインの設定を変える所まで。

今回、AI秘書の凛ちゃんが動かした架空の銀行では、結果はこうなりました。

表を見ると、守りが効いたのは「入力を増やした所」ではなく、「ブラウザが相手を確かめた所」でした。分かれ目は、そこです。

動画が示した「リテラシーを高める」を、私はこの設定と保存先の確認につなげます。試した回数は各2回と少なく、仮想の認証器での結果。でも、守る場所の違いは見えました。

→ 今日、設定を開く

使っているGoogleアカウントのセキュリティ設定で、パスキーの状態を確かめます。対応するログインをパスキーへ替え、続けて保存済みのログインを数える。この順で、実際の設定を見直しましょう。

私なら、使っているログインを、ID・パスワードだけ、2段階認証、パスキーに分けます。パスキーが使えるものから替え、対応していないものは最低でも2段階認証にする。替えた後も、パスワードやコードで入れる入口が残っていないか、設定画面で確かめます。

そこから、ログインした状態を保存している場所も数える。架空の銀行では、パスキーが偽サイトを拒否しても、コピーした証では入れました。今日の手は、Googleアカウントのセキュリティ設定を開くことです。