iddance Lesson.5 パスキーのすべて 個人的ハイライト
iddance Lesson.5 パスキーのすべて 個人的ハイライト
オンラインで拝聴したiddanceの個人的なハイライトです。
個人的に確かにと思ったことや、面白かったことを雑にまとめました。
本来の内容とずれているかもしれないので、その点はご容赦ください。
入り口を強化しても裏口が弱かったらダメ
小岩井さんがお話されていましたが、パスキー認証で正面を強固にしてもセッション取られたら、ダメというのは肝に銘じておかないといけないと思いました。
こういった認証の話が起きると、ログインをさせないという入り口に焦点が当たりがちです。
ですが、中に入った時のセキュリティ、例えばセッションなどを取られないようにするのは認証とセットで考えないとダメだと改めて感じました。
セッションの話を聞いて、そういえばDevice Bound Session Credentialsっていつ頃検証できるのだろうとも思いました。
パスキープロバイダーを実は作れる
これは個人的にかなりワクワクしました。
パスキープロバイダーはスケールが大きいから使うだけで、自分では作れないと思っていましたが、どうやら作れるみたいです。
Google提供の情報から読み解いたとおっしゃっていたので、何とか自分でも探し出したいです。
パスワードマネージャーしか使えないログイン画面
小ネタ的な話でしたが、パスワードマネージャーしか使用できないログイン画面はとても面白かったです。
伊藤さんの記事で、パスキーを普及するためにまずはパスワードマネージャーを浸透させていこうとありましたが、上記のような取り組みはすごく良いのではと思っています。
アカウントリカバリーとeKYCによる懸念
パスキーを使用できなくなっている際に、別の方法でアカウントリカバリーをできる必要があります。
ただ、そのアカウントリカバリーの認証強度が弱いと、せっかくパスキーで入り口を強固にしてもアカウントリカバリーの方で侵入をされてしまいます。
なので、アカウントリカバリーも認証強度を強くすることが求められ、その方法の一つとしてマイナンバーカードを使用したeKYCがあるとのことです。
マイナンバーカードなどで、偽造が難しいものを使用して本人確認ができれば、アカウントリカバリーが侵入口になる危険性を減らせそうです。
ただ、上記の方式をあらゆるサービスがとった時、各種サービスに自分の住所などが知られてしまいます。
サービスによってはそこまで情報を渡したくないよねという話があり、皆等しく認証強度をガチガチに上げることが正解なのかを考えないといけないことに気づかさせていただきました。
フィッシング耐性のある知識要素による認証
iddance内の動画ではなく、Xでの投稿ですが以下の投稿をされていました。 知識要素による認証でフィッシング耐性があるものができれば、パスワード認証がメインの時代での移行も結構スムーズにいきそうと感じました。
こんなパスキーはいやだ
面白かったです。
以上です。
拝聴できてとても楽しかったです。ありがとうございました。
Discussion