【書評】『WEB+DB PRESS Vol.136』から学ぶ、パスキー(Passkey)導入で変わるセキュリティとUX

新屋司

2023.12.30

最近、認証技術を学んでいるときに「パスキー」という言葉をよく目にするようになりました。どうやら従来のパスワードの問題を解決する新時代の認証方式として注目を浴びているようです。しかし「パスキー」とはどのような認証方式なのでしょうか。

パスワード以外の認証方式と言えば「多要素認証」や「パスワードレス認証」がありますが、「パスキー」はこれらと比べて何が違うのでしょうか。

『WEB+DB PRESS Vol.136』の特集2『実戦投入パスキー』を読むことで、これらの疑問の答えが見つかります。パスワードレス認証がなぜ登場したか、なぜ新しい認証方式であるパスキーが求められているのか。ユーザーの体験に着目しながら詳しく解説してくれています。

このブログ記事では、全5章ある『WEB+DB PRESS Vol.136』の特集2『実戦投入パスキー』を、私の見解を交えながらまとめてみます。興味が湧いた方はぜひ書籍を手にとって見てください。

以降、本書と表記させていただきます。

結論

まず結論まとめから

「パスキー」とはどのような認証方式なのでしょうか。

パスキーは、ユーザーのデバイスと認証サーバーの間とで公開鍵暗号方式で認証を行う「パスワードレス認証」のひとつであり、ユーザーがデバイスを所有していることと、PINコードやFaceIDなどの生体認証を組み合わせて認証することから「多要素認証」でもあります。

パスワード以外の認証方式と言えば「多要素認証」や「パスワードレス認証」がありますが、「パスキー」はこれらと比べて何が違うのでしょうか。

上述した通り、「多要素認証」であり「パスワードレス認証」でもありますが、従来の認証方式と比べて利便性が向上しており、ユーザーのログイン体験が向上している点です。

以降、この結論に至るまでの解説です。

パスワードの限界

ます、パスワードの問題について整理します。本書にはこうあります。

脆弱なパスワードが原因となり、毎年のように不正アクセスや不正送金などが繰り返されています。サービス提供者でも2段階認証などの2要素認証方式を採用していますが、いまだに実際に2段階認証を有効化するユーザーはごくわずかであり、近年では各種2段階認証を突破する攻撃例も増加傾向にあります。

つまり

パスワードを使い回したり、予測されやすいパスワードを設定する等の「ユーザーの問題」
パスワードのハッシュ化を怠ったり、ハッシュ値（SaltやPepperと併せて）が漏洩する等の「サービス提供者の問題」

ユーザーとサービス提供者の両サイドに問題があり、漏洩事例が後を絶たないということです。特に前者の問題が大きく、サービス提供者がどんなに堅牢なシステムを構築しても、ユーザーのリテラシー次第でパスワード漏洩・アカウント乗っ取りが容易に発生してしまいます。

この対策として多要素認証の設定が挙げられますが、サービス提供者はユーザーに多要素認証を強制できません。 なぜなら、知識情報（パスワード）以外を確認するためには所有情報か生体情報を確認する必要がある（※1）わけですが、所有情報か生体情報を確認する一定の操作をユーザーに強制することになり、ユーザーのログイン体験を悪くさせるからです。

【※1】
多要素認証は、認証の3要素である知識・所有・生体情報を組み合わせて認証することを言います。

一定の操作とは、認証しようとしているサービスでまずパスワードを入力し、別のサービスまたデバイスに移動してOTP（ワンタイムパスワード）を確認。そこからまた元のサービスに戻ってOTP入力する、といった感じです。

確かに画面を行ったり来たりするのはちょっと煩わしいので多要素認証の設定をユーザーに強制させるのは少々強引な気がします。社内向けの認証システムなら多要素認証を強制できもしますが、~~Toカスタマーの認証システムで多要素認証を強制しているサービスを私は見たことがありません。~~

【20240101追記】
・現在、Githubは多要素認証が必須です。Toカスタマーの認証システムで多要素認証を強制しているサービスを私は見たことがない、というのは言い過ぎていますね。

この節で最も重要なのは、認証行為が堅牢であることに加えて「ユーザーのログイン体験」もまた認証を考える上では重要な要素だということです。ログイン体験が悪い認証サービスは、どんなに堅牢だとしてもユーザーに使ってもらえません。

パスワードレス認証への期待と現実

パスワード認証が堅牢でないのは、パスワードが以下の条件を満たしていないからです。

【強いシークレットの条件】・記憶させない・毎回ちがう・手入力させない

パスワード認証って一個も条件を満たしてないじゃん... ならばパスワード自体を無くしてしおうということでパスワードレス認証の登場です。従来のパスワードレス認証方式は以下のとおりです。

1.マジックリンク認証

ユーザーの登録メールアドレスに認証用のリンク付きメールを送信し、リンクをクリックすることで認証します。しかし

任意のデバイスでメール受信が可能（な場合が多い）ため、所有を確認する方法としてあまり信頼できない

ので、~~流行ってる印象はあまり無いですね。~~

【20240101追記】
・海外ではSMSの信頼性が低くマジックリンクによる認証もわりと使われているようです。

2.SMS認証

ユーザーが所有する携帯電話にSMSを送信し、確認コードを入力して認証します。 SIMに紐づくキャリア回線を使用するため、所有を確認する方法としてはマジックリンクよりは信頼できますが

SIMスワッピングなどでハッキング自体は可能
また、SMS通信費が高くなりがち

この認証方式は多要素認証の一部としてはよく見ますね。

マジックリンク認証とSMS認証は強いシークレットの条件である「記憶させない」と「毎回ちがう」を満たしていますが、「手入力させない」の条件を満たしていません。このため、ユーザーを偽サイトに誘導し確認コードを手入力させてアカウント情報抜き取ること、フィッシング攻撃（※2）が可能です。

【※2】
フィッシング攻撃は、認証情報を入力するときに「ブラウザが介入し」、ユーザーが「正規のサービスかどうか判断を誤ってしまう」ことで成立します。後述のデバイス認証でこれを防ぐことができるのですが、パスワードマネージャーを利用することでもこの攻撃を防ぐことが出来ます。しかし、パスワードマネージャーを利用するかどうかはユーザー次第です。

パスワード自体を無くしてもOTPの手入力は無くならならず、入力の煩わしさとフィッシング攻撃のリスクは残ったまま。
「手入力させない」ためにはどうすればいいのか...ここでデバイス認証が登場します。

3.デバイス認証（FIDO認証）

デバイスの内部に組み込まれている認証器でキーペアを生成し、公開鍵暗号方式でサーバーと認証を行う方式です。

認証フローを図にまとめるとこんな感じです。

登録: ユーザーが所有するデバイスの認証器が生成したキーペアの、片方（秘密鍵）を認証器内部に、もう片方（公開鍵）を認証サーバーに保存し、登録が完了
認証: 認証サーバーが生成したチャレンジコードをユーザーの秘密鍵で署名・サーバーに返送し、サーバーで検証してOKなら認証が完了

ユーザーの所有情報確認は、デバイスのローカル認証で行います。FaceIDやPINコードなどがそうです。FaceIDなら生体情報、PINコードなら知識情報も同時に確認することになるため、多要素認証でもあるわけですね。

まずデバイス認証は強いシークレットの条件を満たしています。 OTPが無くなっているので、ログインの煩わしさが軽減されています 認証時にユーザーは手入力をしない、そしてデバイスは正規のサービスを判定し認証フローを進めるのでフィッシング攻撃への耐性があります さらにサーバーには公開鍵しか保存していないので、仮に漏洩しても公開鍵だけではアカウント乗っ取りはできません！

これまでの問題を全て克服しています...うおおお！デバイス認証（FIDO認証）最強！！...と思えますが、実は弱点があります。

その弱点とは、端末自体を紛失してしまうとアカウントをリカバリできないことです。端末変更の場合でもそれまで利用していたサービスのアカウントを移行できません。これは秘密鍵が端末内にしか存在できないことに由来します。そのため、同じサービスを利用し続けるためには新しくキーペアを発行し、アカウントを新しく登録し直すしかありません。

アカウントのリカバリと移行ができないのは致命的すぎる...ここでやっとパスキーが登場します。

パスキーの登場

AppleがWWDC2021で...（中略）...「Passkey」という概念を発表しました。パスキーによって、それまで特定のデバイスに閉じ込められていたFIDOクレデンシャルは、端末紛失時や新規端末への移行時に「移行」できます。 Appleが発表したのは、FIDOクレデンシャルはをiCloud Keychain経由で同期するという計画でした。

パスキーは、iCloud Keychainによってデバイス間で鍵情報を共有するため、デバイス認証の弱点を克服しています。AppleだけでなくGoogleとMicrosoftもパスキーに対応することを表明しており、2023年12月ではiOSやMacOS, Windows, Androidでパスキーが利用可能です。

https://passkeys.dev/device-support/#matrix

まだ全てのOS・ブラウザに対応しているわけではないため、ユーザーにパスキーだけの認証を強制することはできませんが、今後の浸透に期待したいところです。

パスキーは、従来のパスワードレスの良さを残しつつ、パスワードレスの弱点を克服した認証方式であることがわかりました。実際に触ってみると、アカウント登録（パスキー登録）は数クリックで完了、認証はワンボタンでログインすることができます。パスワード認証や従来のパスワードレス認証方式と比べると格段にユーザー体験が良いことがわかります。

一例ではありますが、こちらのサービスはパスキーを導入しています。

一方で課題もあります。多くの一般的なユーザーはパスキーのことを知りません。そのため、ワンボタンでログイン可能だとしてもユーザーは利用しません。よって、パスキーが浸透するにはユーザーの理解が必要です。私もパスキー登録するときに少々混乱しました。多くのユーザーはきっと尚さらです。
従来の認証方式はそのまま、Yahoo!IDさんのようにユーザーに向けてヘルプページをつくるなどパスキーに関する情報発信を地道に続け、少しずつ利用ユーザーを増やしていく。なかなかに大変そうですが、これからに期待をしています。

考察&感想

まとめてみて、ひとつ疑問が生まれました。パスキーは、FIDO認証をiCloudやGoogleアカウントなどを通じてデバイス間で鍵情報を共有する仕組みです。ということは、iCloudやGoogleアカウントにログインする時のパスワード認証方式のみを使用してしまう場合、これはセキュリティが脆弱だと言えないでしょうか？

確かに、この場合のクラウドサービス（AppleやGoogle,Microsoft）のセキュリティは重要な役割を果たします。しかし本書を読めば、ユーザーのリテラシーもセキュリティにおいて重要な要素であると気づきます。ユーザーがシークレット管理を疎かにすればどんなに堅牢なシステムも突破されてしまいます。問題は、その不特定多数のユーザーのリテラシーをどのように高めるかです。 AppleやGoogle, Microsoftはユーザーに健全なセキュリティ習慣を奨励しており、ユーザーに多要素認証の設定など、推奨してくれます。

パスキーを導入すれば完全に無敵になれるわけではなく、ユーザーとサービス提供者の相互の努力と協力によってセキュリティを高めていくのですね。

そして、本書はユーザーのログイン体験をしっかり整理してくれています。私はOTPの入力を何とも感じていませんでしたが、どのようにすればユーザーを煩わせることなくログインさせられるか、サービス提供者はユーザー体験を向上させるために出来ることを模索し続けなければならないのだとわかりました。

参考1

パスキーという単語の定義は、現在少々あいまいな部分があるようです。本記事でまとめたように、「同期可能なFIDOクレデンシャル」のことをパスキーと呼ぶこともあれば、「デバイス認証の中で登場する同期不可のFIDOクレデンシャル」のことをパスキーと呼ぶこともあるようです。現在インターネットで検索すると後者の説明を多くみかけます。

【20240101追記】最近は同期の可否を問わずパスキーと呼び、同期するものを同期パスキーなどと呼ぶ人が増えてきたようです。