Googleアカウントでパスキーがデフォルトのログインオプションとして有効化
(blog.google)- Googleは個人向けGoogle Accountでパスキーをデフォルトのオプションとして提供し、パスワードなしログインへの移行をより簡単にした
- 次回のログインからパスキーの作成・使用を促すプロンプトが表示され、アカウント設定の「Skip password when possible」オプションがオンの状態で表示される
- パスキーは端末のロック解除に使う指紋、顔スキャン、PINでログインし、Googleはパスワードより40%速く、暗号化方式によりより安全だと見ている
- パスワードでのログインは当面維持され、望まないユーザーは「Skip password when possible」をオフにしてパスキーの使用を拒否できる
- YouTube、Search、Mapsではすでにパスキーが使われており、Uber・eBayも対応中で、WhatsApp互換性もまもなく提供される予定
個人向けGoogle Accountのログイン既定値の変化
- Googleは今年初めにパスキー対応を開始して以来、ユーザーの反応は前向きだったと見ている
- これで個人向けGoogle Account全体でパスキーがデフォルトのログインオプションとして提供される
- 次回のアカウントログイン時に、パスキーを作成して使用するよう促すプロンプトが表示される
- Google Accountの設定には「Skip password when possible」オプションがオンの状態で表示される
パスキーの利用方式とセキュリティ特性
- パスキーは、アカウントログイン時に端末のロック解除と同じ指紋、顔スキャン、PINを使用する
- Googleによれば、パスキーによるログインはパスワードより40%高速
- 暗号化方式に依存するためより安全で、フィッシング耐性も備える
- ユーザーはパスワードの数字や特殊文字を覚えなければならない負担を減らせる
パスワードとユーザーの選択権は維持
- Googleは新しい技術が定着するには時間がかかると見ており、パスワードはしばらく残り続ける可能性があると考えている
- ユーザーは引き続きパスワードでログインできる
- パスキーを望まないユーザーは「Skip password when possible」オプションをオフにすればよい
Google外へ広がるパスキー対応
- パスキーの提供開始以来、ユーザーはYouTube、Search、MapsなどのGoogleアプリでパスキーを使ってきた
- Googleは業界全体でパスキー導入が増えている流れを前向きに捉えている
- UberとeBayは、プラットフォームへのログインでパスワードを使わない選択肢を提供している
- WhatsApp互換性もまもなく提供される予定
パスワードなしログインに向けた次の段階
- Googleは他のオンラインアカウントでパスキーを使える場所を今後も案内していく予定
- 業界にパスキーへの移行を促し、パスワードの使用を減らし、最終的にはまれなものにしていく方向を進めている
- Googleアカウントのセキュリティ関連情報はmyaccount.google.com/saferで確認できる
1件のコメント
Hacker News のコメント
多くの人が言っているように、デバイスを失うと、暗号学的な認証を再び使えるようにするのは非常に難しい
先月、妻が iPhone のガラスを割って AppleCare で修理したのだが、Apple は「ガラス修理」が実質的に内部部品の交換と初期化を含むことを知らせてくれなかった
Apple の iPhone バックアップには、eSIM のような暗号学的な秘密情報は含まれない
結局 eSIM を有効化するにはメールが必要で、メールには MS Authenticator が必要で、MS Authenticator は SMS なしでは有効化できないというループにはまった
写真付きの身分証を大量に持って通信キャリアの店舗まで行き、eSIM を再発行してもらう必要があり、パスワードが正しいのに、何らかの携帯電話ハードウェアロックのせいで銀行口座までロックされた
解決には数日かかり、複数の機関に直接出向く必要があった。海外旅行中だったら完全に詰んでいただろう
時代は変わり、今やデジタルアイデンティティ全体が携帯電話の中のスマートカードになっている。そのスマートカードが SIM であれオンボード TPM チップであれ、失くしてしまえば、他人から見れば死んだも同然になる
Passkey はこの問題をはるかに悪化させる。物理 SIM であれば、ある携帯から別の携帯へ移すこともできるが、Passkey はベンダー間で移行できない
叫びながら逃げるべきだ。誇大広告を信じず、ベンダー各社が移行と復旧の解決策をきちんと出してくるまで待つべきだ
人々はパスワードを嫌うが、現実には多くの状況や脅威モデルでは、パスワードが最善の妥協点だ。
/dev/randomから 32 バイト以上取り出して好きな方式でエンコードすれば、この宇宙の中で誰も総当たりでは破れないし、パスワードマネージャーが再利用の問題も解決してくれるさらに、保存方法を自分で制御でき、安心できるだけの冗長バックアップを適用できるという利点もある
iPhone のバックアップには iCloud Keychain に保存された項目のバックアップが含まれ、別の Apple デバイスか復旧キーがあれば再びアクセスできる。デバイスのパスコードか復旧キーさえあれば、すべてを再度ブートストラップできる
eSIM は通信キャリアの持ち物なので特殊だが、そういうものは昔から、そして今後も、店舗と電話に縛られて面倒なものだ
私はだいたい 3 つ使っている。ワークステーションの Yubikey、携帯用の Yubikey、携帯電話。この 3 つで、メール用の Google と携帯電話用の Apple の両方を再開できる。残りは 1Password にあり、これらの手段を通じてアクセスできる
最悪の最悪の緊急事態でも、メールは何とか取り戻せる気がする。DNS プロバイダーで本人確認をして MX レコードを変更すれば、また対処できる。それでも日常生活に不可欠とまでは思わない。アクセスを失えば非常に不便だろうが、死刑宣告ではないはずだ
SMS と Signal の連絡先は他の場所にもあり、銀行口座のお金は小切手を書いて使える。会社関連のアカウントは、オフィスに直接現れれば入れる
ただし Passkey は一般的なコンピューター利用者には複雑すぎる可能性が高いと思う。残念ながら、「ログインのたびにメールリンクを送る」方式が、最もユーザーフレンドリーなパスワードレス認証に見える
Passkey を 1Password に入れる習慣も、気が休まるものではない。永遠に縛られると分かっているからだ。それでもサービスは気に入っているし、移行したくなったときには、少なくとも作り直すべきアカウント一覧はある
一番怖いのは、携帯電話のパスコードを忘れる状況だ。あるとき目が覚めた直後、とても悪いタイミングで注意がそれて、6 桁のパスコードがどうしても思い出せなかった。ワークステーションのロック解除にも同じコードを使っている。少し別のことに意識を向けたあと、筋肉記憶でかろうじて思い出した
本当に「今、脳卒中でも起こしたのか」と思う瞬間だった。今はそのパスコードを 1Password に保存しているので、ロック解除済みのデバイスが 1 つでもあれば記憶を呼び戻せる。かなり前のことで、認知症ではなさそうだし、単に奇妙な一時的現象だった
一方で、職場で使っていた最長 1 年有効のパスワードは全部完璧に覚えている。6 桁の数字を思い出せなければ、あまり役には立たないが
ということは、近いうちにパスワードも「Killed by Google」入りし、私のアカウントも一緒に入ることになりそうだ。私はログイン済みのデバイスを 1 台も残していない
もう残っている数少ない用途も、移行するにはとっくに遅すぎるくらいだ。避けられない状況になったとき、会社が私の業務アカウントの Passkeyをリセットできるのか気になる
これが正しい方向だとは思うものの、Google や iCloud アカウントからロックアウトされ、実際には取り戻す手段がなかったという恐ろしい事例をあまりにも多く見てきた
こう考えるのは自分だけではないと思うが、いつかおそらく自分のミスで Google から締め出され、自分のデジタル生活が終わる気がしている
民間企業が login.gov のようなログイン方式を提供し、ロックアウトされたときに USPS のように実際の人間と話せるようにしてくれるなら、喜んでお金を払う
https://mastodon.laurenweinstein.org/@lauren/111103819626952...
https://mastodon.laurenweinstein.org/@lauren/111211366080459...
if ではなく when の問題だ。データを大事にする人にとっては、バックアップと徹底した災害復旧計画が必須だ。どこかの会社が、自分に落ち度がなくても何かを台無しにするし、それは避けられない
残念ながら、失ったアカウントの一部の側面にはよい災害復旧の選択肢がないが、複数のアカウントを持ち、単一障害点を避ければ、ある程度は助けになる
ログインできる独立した手段を複数確保しておく必要がある。たとえばバックアップコードを印刷して、重要書類と一緒に保管する、といった方法だ
ただしこれでも、Google のポリシー変更によってアカウントからロックアウトされる状況までは防げないので、理想的には Google アカウントなしで耐える練習もしておくべきだ
Lauren Weinstein は、Passkey には欠陥があり、特に一般ユーザーにとって大きな頭痛の種になるだろうと警告している
https://mastodon.laurenweinstein.org/@lauren/111103819626952...
https://mastodon.laurenweinstein.org/@lauren/111211366080459...
プライバシー保護とベンダーロックインの問題をいったん除けば、Passkey は、2段階認証なしであらゆる Web サイトで同じ基本パスワードを使い回している人たちにとっては、ひどい代替手段ではない
しかし、実際に何かを保護するために依存し始めると、すぐに巨大な悪夢になる。しかもこれをパスワード＋2段階認証と同等のもののように扱っているので、さらに悪い
「見つけやすい」と言うが、実際には見つけられないようだ
https://mastodon.laurenweinstein.org/@lauren/111211489395997...
ユーザーがどうせ弱いサービス用パスワードを使う可能性が高いなら、なぜ弱いデバイスのパスコードが Passkey を避ける理由になるのか分からない
その場合、端末認証が破られれば、どのみちアカウントも侵害されたことになる
特に Google は現在、パスワードと Passkey のどちらか一方だけを選ばなければならない仕組みではない。端末に Passkey がなければ、パスワードログインのフローに戻れる
リスクと利点を比較するには、人々が実際にどれだけパスワードを使い回しているのか、2段階認証を使っているのか、すべてのアカウントアクセスをスマートフォンの画面ロックだけに依存しているのか、生体認証を使っているのか、アカウント復旧がどれほど必要なのか、などを知る必要がある
そのデータだけが議論を整理でき、各自が自分の状況に応じて異なる結論を出すことも可能にする
Google はこうしたデータの大半を持っている。自分たちの主張を裏付けるには公開すべきだ
1Passwordが最近Passkey対応を有効にしたが、1Passwordの外へエクスポートする方法がないと知って「驚いた」
1PUX形式のエクスポートにも、CSVにも含まれない
つまり文字どおりバックアップが不可能。1Passwordがダウンしたり、会社が閉鎖したり、似たようなことが起きると、Passkeyはそのまま消える。復旧する方法はまったくない
このトピックに関する最近の1Password Passkey AMA投稿を参照:
https://old.reddit.com/r/1Password/comments/16to6x7/hey_redd...
1Passwordが使えなくなる場合について言えば、パスワードとPasskeyはいずれもデバイスに同期される際にローカルにも保存される。何らかの理由で1Passwordにアクセスできなくなっても、保管庫内のすべての項目には引き続きアクセスでき、デバイス間同期だけができなくなる
Passkeyをデバイス間で移すというより、SSH鍵のようにデバイスごとに異なるPasskeyを生成し、関連サービスにすべて登録する構造だと考えるべき
もちろん、ユーザーが攻撃者のPasskeyを自分のアカウントに追加するようだまされる可能性はある
モバイルではこの問題を数年前に解決したが、メールはいまだにめちゃくちゃ。教訓は、絶対にロックインされるなということ
window.credentials呼び出しを横取りし、Yubikeyのような他の検証手段と1Passwordを併用したければ、設定に入ってPasskey機能全体をオフにしなければならないGoogle One Tapのプロンプトを横取りし、グローバルに無効化して自分たちのOAuthプロンプトを表示するやり方にも似ている。私はChrome拡張だけを使っているので、ネイティブアプリの体験が大きく違うのかは分からない
ユーザーの立場からすると、いまだに理解できない
家が火事になるなどして、Googleにログインしていたすべてのデバイスが壊れたらどうなるのか？どうやって再びアカウントにログインするのか？
古いスマートフォンを1台渡してSIMはうまく移せたが、Googleアカウントへのログインがどうしてもできなかった。Googleがひたすら「スマートフォンを使え」としつこく案内してきたため。ノートPCもメールからログアウトされていた
幸い、以前の出来事のために私がバックアップトークンを持っていたので解決できた。他の人たちはどうするのか分からない
鍵をM個の断片に分け、そのうちN個があれば再構成できるようにする。例えば3/8なら、8個の断片のうち3個だけあれば鍵を復元できる。各断片を信頼する人たちに預け、復旧時にそのうち少なくとも3人から断片を受け取って鍵をよみがえらせる
私がmultipasskeyというYCデモで実装したときは、信頼する連絡先を選ばせ、バックグラウンドで鍵の断片を彼らに送った。復旧が必要になったら彼らに要求し、十分な断片を受け取るとデバイス鍵を再構成した。デバイス鍵ができると、リモートサーバーから暗号化された鍵バックアップをダウンロードし、新品同様に復元される
2017/2018年にこのプロジェクトをmultipasskeyと呼び、動作するデモとしてYCに応募したが却下された。私の説明が下手だったのだろうと思う
技術者の立場では、友人にバックアップデバイスを預けるか、Apple/Microsoft/パスワードマネージャーのアカウントにもPasskeyを保存すべき、という意味だと推測する
だがGoogleはもっと詳しく説明すべき
そして電話番号は絶対に失ってはいけない。ユーザー名、パスワード、復旧用メールがあっても、SMSコードを受け取れないためGoogleアカウントに再び入れない
この移行期には、従来提供していた手段の代替としてPasskeyを提供する方式が推奨される。Googleや多くのサービス提供者がそうしている
ただし今挙げた質問は、Passkeyがなくても誰もが考えるべきアカウント復旧の問題。パスワードを忘れた、パスワードマネージャーにアクセスできない、2つ目の認証デバイスを失った場合にどうログインするか、計画しておく必要がある。Passkeyの導入がアカウント復旧の悩みを完全になくしてくれるわけではない
それでも、Passkeyがアカウント復旧においてより優れている特殊なケースがある。iCloudキーチェーンを使うAppleデバイスでGoogleアカウント用のPasskeyを作成すると、そのPasskeyはiCloudに同期される。すると家が燃えてすべてのデバイスを失っても、iCloudアカウントにアクセスできさえすれば、Googleアカウントや他のWebサイトのPasskeyを取り戻せる
もちろん「Apple iCloudアカウントへのアクセスを失ったら？」という質問は正当。だからアカウント復旧の問題が完全に消えるわけではないが、多くの場合Passkeyによってかなり軽減できる
ここにはシンプソンのパラドックスがある
平均的にはセキュリティを高められる。大多数のユーザーはパスワードの使い方が非常にひどいからだ
しかし、パスワードを安全に使っている熟練ユーザーにとっては、強制されるならセキュリティが急激に低下することになる
電話番号による二要素認証の強制も同じ効果がある。Big G の場合、電話番号による二要素認証の強制は、セキュリティを装った反匿名性ポリシーだ。今回の場合は、生体情報を確保しようとする試みに見える
電話番号は、ほとんどの人が持つ最良の長期的な身元情報であり、Google は数十億ユーザーのアカウント復旧を、とんでもない規模で支援しなければならない
多くの人はパスワードやデバイスを失うが、電話番号を失う人は非常に少ない
したがって、Google が自社プラットフォーム上で身元を付与し委任するために電話番号を使うのは筋が通っている。プライバシーには悪いが、ユーザーが自分で管理しなくてもよい第三者認証の「資格情報」としてデータを制御できるようにするため、セキュリティには非常に良い
それと、この部分は確信がないので、詳しい人に修正してもらえるとありがたい。弱いパスワード、使い回し、フィッシングに免疫のある熟練ユーザーだと仮定しても、セキュリティ上の利点が一つあると理解している。Google Passkey が漏えいしても、漏れるのは公開鍵だけであり、公開鍵ではログインできないので、漏えいがほとんど役に立たなくなる
Google が生体情報を収集していたなら、すでにそうしていただろうし、この機能とは無関係だ
このセキュリティモデルの非常に基本的な詳細は、iPhone が Secure Enclave を使い始めた時代から、ずっと前から真実だった。なぜこのサイトの人たちが、まったく理解していないことについてあれほど断定的に話すのか分からず、正直驚いている
Passkey は、サーバーにログインするときに SSH パスワードの代わりに SSH キーを使うのと道義的には同等で、それを Web サイトに適用したものだ。さらに客観的にも、「パスワードを安全に使う」という考えでは置き換えられない単純な事実がある。Passkey は文字どおりフィッシングに強い
これをもう推し進めるのは驚きだ。先週時点でも実装には粗い部分が十分残っていたので、自分の Workspace テナントでは無効化した
最もいら立つ点は二つあり、Advanced Protection がまだ Passkey をサポートしていないため当面 U2F を維持しなければならないことと、アカウントに U2F キーが設定されていると、Google がまずそれを Passkey として使うよう案内した後、Passkey ではないのでパスワードでログインしろと言ってくることだ
結果として、フィッシング耐性のある多要素認証を使っている人は、デバイスで多要素認証ステップを「記憶」させる機能を失う。Google が常にパスワードの前に U2F 認証要素を要求するからだ
これとは別に、小規模顧客数社へ Okta ベースのパスワードレスログインを展開する準備をしながら、セキュリティキーと Passkey を使った FIDO2 フローを、デバイス種別やプラットフォーム全般でかなりテストしてきた。認証フロー自体は全体的に気に入っているが、注意すべき落とし穴が多い
正常系を整理し、オンボーディング資料を作り、事業継続シナリオを文書化するのにかなりの時間を使った。個人のユースケースはある意味さらに難しく、単一の IdP ではなく各サービスを考えなければならない
複数の環境をサポートする必要があるなら、今の簡単な道は 1Password や Passkey をサポートする他のパスワードマネージャーに投資することだ。最も一貫したユーザー体験を提供し、ほとんどのプラットフォームで動作するが、Android 14 ではまだ問題がある
高権限アカウントには引き続きハードウェアキーを使う予定なので、管理者には FIDO2 キーのペアを渡す。それ以外の人には Yubikey を一つ渡し、デバイスへのアクセスを失ったり信頼できないデバイスからログインしなければならないときのバックアップにする。Android もここで問題だ。14 でもパスワードレス FIDO2 フローをサポートしていないように見える
興味深い方向だ。ただし、指紋や顔認識のような生体情報は、実際には「秘密」ではないという点は指摘しておく価値がある
ユーザーの認知や同意なしに観察されたり利用されたりし得るし、多くの面でパスワードというよりユーザー名のように振る舞う
指紋は、認証に使われる暗号学的な鍵ペアをロック解除するだけだ
私は Yubico Security Key を Passkey として使っており、6桁の PIN で保護されている。その PIN はデバイスローカルにのみ存在し、デバイスを物理的に持っている人がそのままログインできないようにするためのものだ。PIN を 10 回連続で間違えるとキーは消去される
PIN を入力するとキーがロック解除され、Google アカウントに入らせてくれるのはまさにそのキーだ
パスワードがあるほとんどのアカウントには、「会社に身元を証明すればリセットしてくれる」という安全装置がある。銀行のパスワードを覚えていなければ、銀行がリセットしてくれる経路がある、という具合だ
Google が管理するものには、問題を解決するために連絡する方法がまったくない。すでにすべての Google 製品で問題になっている
すべてのアクセスをGoogle が管理する扉の後ろに閉じ込めるのは、未来の悪夢を自分で準備することだ
まだ Bitwarden に Passkey を保存できないのが残念だ。それでも、このページ上部のメッセージによると、10月には入る予定のようだ
https://bitwarden.com/blog/bitwarden-passkey-management/