ritou です。
先日、こちらのイベントで(リモートで)お話ししてきました。
大学ICT推進協議会2024年度年次大会
OpenIDファウンデーション・ジャパン エバンジェリストを名乗ってOpenID Connectの話ではなくパスキーの話をしました。最近よくありますね。
今回はユーザー向けの「パスキーの啓蒙」もとい「安全なユーザー認証の啓蒙」について考えていたことをお話させていただきました。
その資料をベースに色々付け足したら長編になってしまいました。お時間がある方に見ていただけるとありがたいです。
(今後、ユーザー認証を安全にしていくために)パスキーへの移行を見据えたユーザーの準備についてお話しします。
みなさんご存知の通り、パスキー認証に注目が集まっています。
パスキー認証は他の認証方式とどう異なるのかを認識するため、初めにユーザー認証の変遷について整理しましょう。
オンラインサービス、特にコンシューマー向けで使われている認証方式というのは、脅威と対策の繰り返しにより変化してきました。
まずは「パスワード認証のみ」が使われていたところから、「他の認証方式との組み合わせによる2要素/2段階認証」が登場したところまでを見てみます。
パスワード認証の現状についてはよく知られているところでしょう。
サービスに対する脅威はいろいろありますが、その中で「第3者によりリモートで行われる不正ログインの脅威と対策」に注目が集まりました。ほとんどのユーザーはパスワード認証にて求められる要件を満たせていません。サービスもパスワードの安全な管理が求められますが、たびたびパスワードの漏洩という事案が発生しました。そのような状況において、基本的な実装に不備がないサービスでさえも他のサービスから漏洩したパスワードなどによる各種攻撃を受けるリスクがあります。
そこで知られることになったのが「認証要素」という概念です。
「認証の3要素」と呼ばれたもののうち、パスワード認証は知識情報を利用する認証方式です。
パスワードを第3者に知られてしまうと、突破されてしまいます。
レガシーなフィッシングサイトではユーザーの識別子とパスワードの組み合わせを狙うものでした。
そこで、知識情報以外を利用する認証方式と組み合わせる方式が出てきました。
代表的なものとして、パスワード認証の後にSMSなどで送られたOTPを入力したり、Google Authenticatorなどで生成されたTOTPを入力するものがあります。
攻撃者はレガシーなフィッシングサイトによりパスワードのみを取得して後から不正ログインを試みても、追加認証のところで止められます。
所持情報を利用する認証方式を突破するためにはデバイス、アプリなどの特定環境にアクセスできる必要があります。
このように、従来のフィッシングサイトなどで取得したパスワードを利用するリモートの不正ログインに対する対策として、2要素/2段階認証と呼ばれるスタイルが広まりました。
攻撃者も黙ってはいません。
2要素/2段階認証を利用しているユーザーに対してフィッシングサイトがユーザーと正規のサービスをつなぐ立ち位置となり、ユーザー認証を中継する形で最終的に正規のサービスから発行されたログインセッションを狙う攻撃(MiTM, AiTM)が出てきました。
というか、前からあったものが使われるようになったという感じです。
厳密にはセキュリティキーのように、この後紹介するFIDO認証のようにこの攻撃が通用しない認証方式もありました。
ただ、一般的に使われていたメール/SMS OTPやTOTP、認証アプリに通知が来て許可のような方式ではこの攻撃を防ぐことが困難です。
この辺りから、パスワードレス認証の概念が出てきました。
他の認証方式と組み合わせても安全性が保てないパスワード認証をあえて利用せず、都度ログイン用URLを送るメールリンク方式やEmail/SMS OTPのみでログインできるサービスが出てきました。
2要素/2段階認証からの「引き算」をすることで、サービス側の開発運用コストを下げることができ、パスワード認証に関連する攻撃を受けることがありません。
しかし、裏返しとして所持情報を利用する認証方式自体の課題に対して注目が集まりました。メールを受信するための認証強度、SMSを受信するために必要なSIMカードに関する課題などですね。
そんな中、これまでとは全く別の仕組みであるFIDO認証に注目が集まり、現在のパスキー認証へと続きます。
FIDO認証をすっ飛ばしてパスキー認証の特徴として、次の3点があります。
- 公開鍵暗号方式の署名生成/検証の仕組みを認証機能に適用 : パスワードの管理や通信内容と比べての安全性向上
- 利用するユーザーの検証についてはデバイス単位のローカル認証を利用 : 「ロック解除して利用する」という、モバイル端末のアプリ利用と同じ方法、ちょっと似たUXによる利便性向上
- ブラウザがサービスが認証要求時に指定したドメイン(オリジン)と現在アクセスしているものの一致を検証 : 中継型フィッシング攻撃にも有効なフィッシング耐性
こうやってパスキー認証に触れると「パスキーはデバイス毎に保存されるんでしょ？無くして詰んだことがあるからもう使いたくないんや」みたいな反応が見られます。
もちろんパスキーでも詰んでしまうことはあり得るのですが、この部分が「FIDO」から「パスキー」への進化におけるポイントです。
FIDO認証ではデバイスのセキュアな領域にクレデンシャルが保存される、という堅牢性が売りの一つでした。
当然ながら新しいデバイスを利用する際にクレデンシャルの再登録が必要になります。
対応サービスが増えれば増えるほど、機種変更時の作業が重くなるとしたら普及は難しいでしょう。
かといって最初から複数デバイスやらセキュリティキーとの組み合わせなど、ユーザー側で冗長な構成にするというのも大変です。
それに対してパスキー認証ではクレデンシャルの保存場所としてパスワードマネージャーを利用します。
パスワードマネージャーがクレデンシャルを同期していれば、新しいデバイスを使い始める際にもこれまで通りオンラインサービスが利用できます。
安全性が下がるのでは？という意見はごもっともですが、「最強の認証方式」ではなくより現実的に一般ユーザーが利用しやすいところに持ってきたと捉えるのが良いでしょう。
すでに長くなりましたが、ここまでの話は明日発売される「Software Design 2025年1月号」の「第1特集 認証技術の最前線 パスワードレス認証「パスキー」のしくみと実装」の1,2章で取り上げています。宣伝です。是非ご覧ください。
gihyo.jp
次に、パスキー認証の啓蒙について考えてみましょう。
パスキー認証の啓蒙にはざっくり言って3つのフェーズに分類できるでしょう。
まずはサービスの開発者に使ってもらうフェーズです。「パスキー認証とはこういうものです、先行実装しているサービスはこの辺りです。」を説明した上で「とりあえず使ってみて良かったら自サービスでもやってみないか？」という内容です。
Chrome for Developersから出されて評判の良い動画もこの辺りですね。
www.youtube.com
そして、サービスの開発者に実装してもらうフェーズです。いわゆるWebAuthn APIの使い方、既存のユーザー認証機能というかID管理機能への組み込み方と言ったところにフォーカスし、対応サービスを増やしてもらおうという取り組みです。
来年1月に発売される「パスキーのすべて」という本の表紙を見る限り、この辺りの内容も含まれそうです。
そしてユーザーに使ってもらうフェーズです。「いろんなところでパスキー認証使えるよ。安全な仕組みなので使ってみてね。」みたいなところです。
現状、どこまで進んでいるかというと2つ目の開発者に導入を促すフェーズでしょう。
パスキー認証を利用するためにサービスが呼び出すブラウザAPIであるWebAuthn APIの仕様は、現在も策定が続けられています。
より安全で使いやすくなるための進化が続いているということです。
このような枯れていない技術を導入するということで、サービスの開発者は一度導入したら良いわけではなく最新の情報を取得しつつ更新していく必要があります。頑張っていきましょう。
前置きが長すぎてしまいましたが、「ユーザー向けにはどう啓蒙していったら良いの？」というのが今回の話のメインです。
今回は「ユーザーへのパスキー認証の啓蒙」というより「認証をより安全にするためのユーザーへの啓蒙」という観点で見ていきます。
そのために、まずは保護すべきユーザーの解像度をあげましょう。
過渡期と言われている現在、パスキー認証を導入するサービスが増えてきました。
その導入スタイルとしては、パスワード認証とTOTPの組み合わせのような「2要素認証、2段階認証と同等の扱い」としてのオプショナルな導入と、特定機能やパスキー登録ユーザーに対して必須化するようなサービスも出てきました。
どうしてもネガティブな反応に注目してしまうもので、前者に対しては「パスキー認証に対応してるのにパスワード認証は使えるんかい！」、後者は「パスキーってなんなんだ。設定しようとしてもうまくいかん」といったより厳しい反応が見られます。
今後「パスキー認証のみで利用できるサービス」が出てきた時に、運用していくのはなかなか困難な道のりになりそうだなというところです。
このような現状において、パスワード認証のみを使うユーザー、別の認証方式を組み合わせて使っている(使わせられている)ユーザー、パスキー認証を使うユーザーのようにいくつかの状態があり得ます。
「パスキー認証使ってください」と言って使ってくれる人はそれはそれでいいのですが、そういう人だけではないことが現状の反応を見ていれば明らかです。
現在、パスキー認証を使ってないユーザーはパスキー認証を使うまでは中継型フィッシングなどのリスクがある状態のまま放置でいいのでしょうか？
現在パスキー認証を使ってないユーザーも保護しつつ、パスキー認証に移行してもらうような啓蒙ができるのが理想的です。が、そんなことできるのでしょうか？
キーワードは「パスワードマネージャーの利用促進」です。
「パスキー全然わからん」となる理由はいくつか考えられますが、ここでは「新しいものを覚えるハードル」に注目します。
「パスワードを記憶して入力するパスワード認証」と「システムにより管理するパスキーを使うパスキー認証」の違いについて、開発者むけでもこれだけ丁寧な説明が繰り返されている状況で、一般のユーザーに「細かい話はできないけど良いものだと伝えて使ってもらう」ハードルはとても高いでしょう。
そこで、この2つの間に「システムにより管理するパスワードを使うパスワード認証」を加えてみます。
まずはパスワード認証のまま、これまで記憶していたパスワードをパスワードマネージャーで管理し、ドメインなどの判定を元にした自動入力を利用しましょう、その次に「管理対象をパスワードからパスキーにしてみましょう」という啓蒙ができます。
これにより、これまでのように「全く別物」として捉えるのではなく「段階的に変化したもの」と捉えられるのではないかと考えています。
「管理対象をパスワードからパスキーに」という部分を説明します。
一旦、パスワードマネージャーについて特徴とそれに対する懸念点も合わせて認識しましょう。
パスワードマネージャーを使うことで推測困難なパスワードを作成可能ですが、サービス側で許容している文字種文字数などが決められるものなので限界はあります。英数8文字とか言われてしまうとうーむとなってしまうわけですね。
サービス単位のパスワード管理、自動入力という機能は、フィッシング耐性を考えるにあたってとても重要です。
パスワードマネージャーはパスワードを送信した際、アクセスしているドメインに対して一緒に送られたユーザー名やメールアドレスと共に管理されます。そして、そのドメインと完全一致、部分一致など独自のロジックによって自動入力の対象となるかが決められます。
そして、フィッシングサイトなどでドメインが一致せず自動入力が動かなかった場合でも、ユーザーがパスワードマネージャーからパスワードをコピペしようと思えばできます。
「サービスが十分に安全なパスワード文字列を利用可能にし、ログイン画面のドメインなどパスワードマネージャーとの親和性の良い構成とし、さらにユーザーがパスワードマネージャーの挙動を完全に信用する」という前提条件が揃わないとフィッシング耐性を持てないわけです。
また、異なるデバイス間での同期の話もあります。
このパスワードマネージャーがパスキー認証をサポートした場合、どうなるでしょうか。
推測困難なパスワードを生成可能、という部分についてパスキー認証においては公開鍵暗号方式における秘密鍵、公開鍵のペアといった扱いになるでしょう。もちろん同じ秘密鍵が生成されまくったら大変なことになりますが、この辺りは信用していいでしょう。サービス側で指定する部分としては、署名生成に利用可能なアルゴリズムを指定する仕組みとなっています。
サービス単位の管理と自動入力に対応する部分で言うと、パスキー認証では管理対象のドメイン(オリジン)はサービスが指定します。
そして、パスワードマネージャーを使ったパスワード認証ではパスワード文字列そのものをコピペするとフィッシングサイトに渡せてしまいますが、パスキー認証で同様の挙動、つまり現在アクセスしているドメイン(オリジン)とは異なるサービスに対する署名付きデータをフィッシングサイトが手に入れることは困難です。
こう整理すると、パスワードマネージャーを使う前提において「パスワード認証が進化したものがパスキー認証」と捉えられます。
パスワードマネージャーを利用しているユーザーに対し、パスワード認証からパスキー認証へアップグレードを促進する機能がいくつか用意されています。
Passkey Autofillという仕組みは移行促進のための機能ではないですが、既存のパスワード自動入力と同等のUI/UXでパスキー認証を利用可能です。
Google Password Managerではパスワードを保存しているサービスのうち、パスキー認証に対応しているサービスについてパスキー使ってみないか？と利用を促進する機能が用意されています。
AppleのパスワードアプリではPasskey Auto Upgradeと呼ばれる機能をサポートしています。
このような「システム管理されているパスワード認証」から「パスキー認証」への移行を促進する仕組みにより、ユーザーに負担をかけずに「記憶で管理されているパスワード認証」から「パスキー認証」への段階的な利用促進が実現できます。
Passkey Autofillを利用することで、システム管理されたパスワードと同等の扱いでパスキーの利用を提案されます。
自分のAndroidのバージョンは最新ではないですが、対象サービス向けに保存されているパスワードとパスキーが並べて表示されます。
MacOSのSafariではパスワードとパスキーの両方が保存されている場合はパスキーの方が優先されたりもします。
Androidの新しいバージョンのパスワードマネージャーでは「このサービスではパスキーが利用できます」という表示が行われ、パスキーの登録、管理機能へのリンクが表示されます。これはサービス側でメタデータを公開することで実現されています。
Apple系デバイスではパスキー認証を導入したサービスでパスワード認証を利用したタイミングでパスキーの自動生成ができます。
これを使うためにはサービスが自動生成を要求しつつ、パスワードマネージャー側が対応する必要があります。
まとめです。
パスキー認証など、脱パスワード認証のユーザーへの啓蒙について整理しました。
パスキー認証について開発者向けの啓蒙フェーズは進んでおり、サービスへの導入が進んでいます。
これから重要となるユーザー向けでは、開発者向けとは異なり「仕組みの説明」よりも「使い方の説明」にフォーカスする必要があります。
サービスが対応しない、パスキーが同期しないクロスプラットフォームでの利用などでどうしてもパスワード認証のみ、パスワード認証と別の認証方式を組み合わせた多要素認証を利用するユーザーは現状も今後も世の中にたくさん存在することを意識する必要はあります。
特に認証方式については「新しいものを覚えて使う」コストというかハードルがとても高いものであり「パスキーという新しい仕組みができたよ！」という啓蒙で普及させることは困難だと考えられます。
ユーザー向けの啓蒙において重要となるキーワードは(パスキー認証に対応した)パスワードマネージャーです。
パスキー認証を利用するためにはパスワードマネージャーの利用が必須となります。
パスキー認証をまだ使っていない、サービスが対応していないなどの理由からパスワード認証を使っているユーザーに対しても、完全ではないにせよフィッシング耐性を持てます。パスワードマネージャーを導入している状態で記憶していたパスワードを手入力して認証すると、パスワードマネージャーへの保存が促され、次回以降に利用できます。これは記憶による管理からシステム管理によるパスワード認証のアップグレードです。
さらに、システム管理されたパスワード管理からパスキー管理へ、つまりパスワード認証からパスキー認証へのアップグレードを促す仕組みを用意されています。
パスキー認証に対応したパスワードマネージャーの利用を促進することで、「記憶を用いたパスワード認証」から「システム管理されたパスワード認証」そして「パスキー認証」へと段階的な利用促進を促せると考えています。
以上、皆さんで便利で安全な世の中を目指していきましょう。
発表スライドと補足は以上です。
今回はユーザー向けの啓蒙について考えてみましたが、これを踏まえて開発者向けの啓蒙においても、パスワードマネージャーの重要性について説明することが必要だと考えます。
パスキーはパスワードマネージャーを強制する仕組みです。パスワード認証に対して「任意」とはいえ普及させておく、その上で管理する情報をパスワードからパスキーに変えて貰えばパスキー認証の利用促進につながります。
ユーザーへの説明だけではなく開発者への説明においてもこの辺りにフォーカスしてもらったらいいなと思います。
また、こういう話をすると、パスワードマネージャーの信頼性が気になる方も出てくると思います。
最近だとこちらの記事についての質問をいただくこともあります。
sqripts.com
自身で覚えるのではなくパスワードマネージャーに依存するため、このような疑問や不安が出てくるのは当然です。
あとは、パスワードマネージャーの選定あたりですかね。ユーザーとしてはもちろん、開発者としてもサービスによっても使われ方が多様化している中で、どのパスワードマネージャーをお勧めしたらいいのか、できるのかという悩みもあるでしょう。
現状ではこれらを課題であると認識することが重要であり、どうしたらその課題を解決できるかを検討すれば良いわけです。
良い意味で課題感、危機感を持ち続けながら進めていきましょう。
Digital Identity技術勉強会 #iddance Advent Calendar 2024 17日目の記事ということにしましょう。
qiita.com
ではまた！
mixi2使ってみてね
