パスキーがあればなぜパスワードがいらないのか

## はじめに

### ダメと言われても我々は同じパスワードを使い回す

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2388259/f729918a-1365-14ae-ca07-0617c67a9418.png)


SNS、ゲーム、ECサイト、サブスクなど、今の時代は何をするにもアカウントへのログインが求められ、これまで数え切れない回数のパスワード入力を行なってきたと思います。
おそらく、指が勝手に動くくらい、自分のパスワード入力に慣れているのではないでしょうか。

「パスワードの使い回しは危険だ」とはよく言われますが、実際どれくらいの人が全て全く違うパスワードを設定しているでしょうか。
銀行システムだろうが、ECサイトだろうが同じ（もしくは似た）パスワードを使い回している人は正直に手を挙げてください。
はい、全員おろしてください。
そうです、我々は全て異なるパスワードを管理するのは面倒なんです。（断定）
しかしWebサイトを開発・運用している身からすれば、自分たちのシステムで不正アクセスなどの被害は出てほしくないのでお願いだから厳重なパスワードを設定して欲しいです。

今回はそんな私たちを救ってくれる新たな認証の一つである「パスキー」について調べてみました。

### ID/パスワードだけに財産を守らせるのは荷が重すぎる

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2388259/07976259-f510-09d3-1add-89711402d2be.png)


パスキーについて見ていく前に、ID/パスワード認証の弱みを調べてまとめてみました。

##### 安全性が利用者の管理に依存する
これは容易に想像できますが、結局パスワードをどのように設定するかでセキュリティの高さが決まります。
例えば辞書攻撃は最も多い攻撃手段の一つなので、単純なパスワードだと不正アクセスされる可能性が高いです。

##### 被害が拡大する恐れ
もしパスワードを使いまわしていれば一つ漏洩しただけでさまざまなサービスに不正アクセスされてしまう可能性があります。

##### 漏洩する要因が多い
パスワードが漏洩する原因はフィッシングや通信の盗聴など、いくつもあります。
パスワードのメモを誰でも見えるところに貼ってるとか、入力しているところを見られるとかもあります。
また、いくら利用者が正しく管理していても、システム側に不備があって攻撃者に狙われるなんてこともあります。

## パスキーとは

簡単に言うと、サービス側が利用者の端末を認証し、端末が利用者本人を認証することで、結果的にサービスが利用者を認証できる仕組みです。

一般的に知られているWebサービスでいうと、Googleでパスキーの利用を勧められたことはないでしょうか？
他にもGitHubやAWSコンソールなど、近年パスキーの利用が増えているように感じます。

[Googleのパスキーに関する情報](https://support.google.com/accounts/answer/13548313?hl=ja)

### 認証時に起こっていること

① ___利用者　→ サービス___
「サービスにアクセスしよ」→端末ポチポチ
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2388259/74834835-e357-fc37-5832-f235dfe9c9fd.png)

② ___サービス　→ 端末___
「端末を認証します。初回設定時に作成してそちらの端末にある署名用の秘密鍵でこのデータに署名してください。」→端末にデータを送信
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2388259/1d07da14-ea0c-4f25-02e8-b3bc0d7ce8db.png)

③ ___端末　→ 利用者___
「OK、でもその前にこの端末操作してるやつがほんまに本人か確かめるわ。ちょっと待ってて。」→端末が本人認証（FaceIDや指紋認証など、ロック解除時に使うあれ）

④ ___利用者　→ 端末___
「ほい」→認証
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2388259/5cf8362a-cd8a-ce24-6a7e-f6e3edf08928.png)

⑤⑥ ___端末　→ サービス___
「こいつ本人でしたわ。よし、じゃあ約束通り署名しますよっと。これでおれのことも信じてくれ！」→署名データを送信

⑦⑧ ___サービス　→ 利用者___
「こちらで検証用の公開鍵で復号して、正当な端末であることを確認できました。どうぞお入りください。」→認証成功

下図はIPAが出している[情報セキュリティ10大脅威2024 解説書](https://www.ipa.go.jp/security/10threats/nq6ept000000g22h-att/kaisetsu_2024.pdf)で記載されている図です。上記の番号はこの図の番号に対応しています。
（すみません、最初からこっち見た方がわかりやすいと思います。）

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2388259/fe0c18b0-220a-41e7-3ca4-f6e018fc60d4.png)

図中の矢印に注目して欲しいのですが、利用者から見ると __赤色の矢印__ のフローしか見えていないのでとてもシンプルに感じます。

### メリット

このように、利用者はサービスに対してパスワードを入力することなく認証することができました。
すでにお気づきかもしれませんが、パスキーは生体認証と端末認証による多要素認証になっています。
多要素認証であるというだけでセキュリティが高いことがわかりますね。

多要素認証と聞くと、パスワードを入力したあとにSMSやメールで認証コードが送られてきて少し面倒なイメージがあるかもしれませんが、パスキーは一度の認証のみです。しかもそれは生体認証などを使った普段から慣れている端末の簡単な認証です。

また、パスキーではサービス側にパスワードなどの情報が保存されません。
そのためサービス管理者に対する不安も解消されます。

楽な認証なのにセキュリティも高いのでもし利用できるのであれば積極的に利用すべきかと思います。

### 注意点

しかし現在利用しているパスワード認証を全てパスキーには置き換えられるというわけではありません。

##### サービス側がパスキーに対応している必要あり

当然、サービス側が署名の検証などをしないといけなくて、現時点でパスキーが使えるサービスは決して多いとは言えません。

##### 端末の管理が必要

パスキーの仕組みを見て分かる通り、端末が利用者本人専用のものであるという前提で認証が成り立っています。そのため、当然共用の端末ではパスキーの利用はふさわしくありません。
当たり前ですが、例えば端末自体を盗まれて端末認証を突破されれば不正アクセスされてしまいます。

## まとめ

__パスキーは、ただ利用者が便利だというだけでなく、安全性も高い__

## 参考

- 情報セキュリティ10大脅威2024 解説書（IPAのホームページより）
    - https://www.ipa.go.jp/security/10threats/nq6ept000000g22h-att/kaisetsu_2024.pdf
- Googleのパスキーに関する情報
    - https://support.google.com/accounts/answer/13548313?hl=ja