パスキー導入の課題とベストプラクティス、今後の展望

by ritou

Embed

Start on current slide

Slide 1

Slide 1 text

パスキー導入の課題とベストプラクティス、今後の展望 @ritou 2025/3/25 12:00-13:00 online

Slide 2

Slide 2 text

内容 • パスキー認証登場までの経緯 • パスキー認証の導入パターンと検討事項 • パスキー認証を導入した先にある世界 2

Slide 3

Slide 3 text

※今回触れない技術的な話についてもカバーしている書籍です。私もレビューしました。 3

Slide 4

Slide 4 text

パスキー認証登場までの経緯 4

Slide 5

Slide 5 text

パスワード認証のユーザー側の要件に対する現状 • 推測困難なパスワード • 推測可能なパスワードを利用 • サービス毎に異なるパスワードを記憶 • 使い回す -> パスワードリスト攻撃 • 別々にすると忘れる -> リセットの手間、サービス側のコスト • 正規のサービスのみに入力 • フィッシングサイトの判断は困難パスワード認証 5

Slide 6

Slide 6 text

パスワード認証のサービス側の要件に対する現状 • 推測困難なパスワードを受け入れる • 利用可能な文字種や最大文字数の制限 • パスワードを適切に管理する • 復元可能な状態での保存、漏洩 • 各種攻撃への対策 • フィッシング、ブルートフォース、パスワードリスト/スプレー等パスワード認証 6

Slide 7

Slide 7 text

異なる認証要素を用いる認証方式の足し算 →多要素認証 OTP/認証アプリセキュリティキー or 別の認証要素を利用する認証方式を追加してパスワード認証突破時のハードルを設けるパスワード認証＋ ←知識情報の利用 ←所持情報の利用 7

Slide 8

Slide 8 text

多要素認証からパスワード認証を引き算 →シンプルなパスワードレス認証 SMS OTP Email OTP/マジックリンク or パスワード認証＋ ←課題のある認証方式を使わない ❌ メールアドレスや電話番号など識別子を含む方式でシンプルなパスワードレス認証を実現 8

Slide 9

Slide 9 text

多要素だけじゃダメですか？ • 多要素認証で使われている方式 • メール, SMS OTP • TOTP • 認証アプリ • セキュリティキー 9

Slide 10

Slide 10 text

多様化するフィッシング攻撃 • リアルタイム/中継型と呼ばれるフィッシング攻撃 • 偽サイトに入力された値を正規のサービスに送り、最終的にログインセッションを奪う 10

Slide 11

Slide 11 text

認証方式におけるフィッシング耐性 →システムによる判定 • パスワードマネージャーの自動入力機能 • 登録時のドメイン比較して自動入力を判定 • 判定ロジックはパスワードマネージャー依存 • 動作しない時に手動入力が可能 • ユーザーに利用を強制できない 11

Slide 12

Slide 12 text

クレデンシャルの漏洩リスク • 登録/ログインのクレデンシャル入力時、通信経路: パスワード、OTP、TOTP • デバイス、サービスから漏洩: パスワード、TOTP Secret 12

Slide 13

Slide 13 text

FIDO認証 (FIDO2) • パスワード認証の課題を解決することにフォーカス • 公開鍵暗号方式の利用 • 端末のセキュアな領域にクレデンシャルを保存 • ブラウザの仲介によるフィッシング耐性 • デバイスのローカル認証と組み合わせて多要素認証を実現 13

Slide 14

Slide 14 text

FIDO認証の特徴 14

Slide 15

Slide 15 text

FIDO認証と公開鍵暗号 • デジタル署名の生成、検証の仕組みを利用 • サービス側からのクレデンシャル漏洩リスクの軽減 • サービスから指定されたチャレンジの値を含むことでデジタル署名の使い回しを困難に • フィッシング耐性とは無関係 15

Slide 16

Slide 16 text

FIDO認証のフィッシング耐性 • パスワードマネージャーの進化形 • サービスが指定したオリジンとの比較による対象判定 • 判定ロジックは標準化されたもの • 動作しない時、手動入力は困難 • ユーザーに利用を強制できる 16

Slide 17

Slide 17 text

セキュリティキー • 多要素認証のための追加認証の方式(所持情報)として登場 • PINなどのユーザー検証と組み合わせると単体で利用可能 • コンシューマ向けの課題 • 有料で購入する必要がある • 保存できるクレデンシャルの数に限界がある 17

Slide 18

Slide 18 text

プラットフォーム認証器 • スマートフォンのセキュア領域にクレデンシャルを保存 • セキュリティキーよりも多数保存可能 • 端末紛失、機種変更時に全てのサービスに削除、再設定の手間が発生 • 使い慣れた画面ロック解除と組み合わせて多要素認証を実現 • PIN、パターンロック、生体認証(顔、指紋) 18

Slide 19

Slide 19 text

パスキー認証 • パスワードマネージャーにクレデンシャルを保存し、複数端末での同期を許容 • 秘密鍵の管理という観点でセキュリティ低下 • 端末紛失、機種変更時の手間を改善して実用的に • プラットフォーム謹製、およびサードパーティーなパスワードマネージャーが利用可能 19

Slide 20

Slide 20 text

FIDO認証からパスキー認証へ 20

Slide 21

Slide 21 text

ユーザー認証の変遷 21 パスワード認証多要素認証 FIDO認証シンプルなパスワードレス認証パスキー認証別の認証要素を足し算パスワード認証を引き算パスワードマネージャーの管理による利便性向上公開鍵暗号方式の利用とフィッシング耐性セキュリティキー＋ユーザー検証パスワードレス認証

Slide 22

Slide 22 text

パスキー認証の導入パターンと検討事項 22

Slide 23

Slide 23 text

パスキー認証導入のモチベーション • サービス全体、もしくは特定機能を利用するユーザーの利便性と安全性を高めたい • より便利で安全な認証方式を利用可能にしたい • 多要素認証によるSMS送信料などのコストを削減したい 23

Slide 24

Slide 24 text

パスキー認証の導入パターン • 既存の認証方式にパスキー認証を追加 • パスキー認証の必須化 24

Slide 25

Slide 25 text

既存の認証方式にパスキー認証を追加 • 任意でパスキー認証を利用可能にする • よく利用する端末では便利にログインできる 25

Slide 26

Slide 26 text

導入のステップ 1. パスキー管理機能 2. ログインフロー 3. パスキーの利用促進 26

Slide 27

Slide 27 text

導入にあたっての検討事項 • 既存のログインフローとの関係 • 既存の認証方式に影響を抑えつつ導入 • パスキー認証を優先 27

Slide 28

Slide 28 text

既存の認証方式への影響を抑えつつ導入 • Passkey Auto fi llを利用して“使えるユーザーに使ってもらう” • ログインフォームの自動入力の対象にパスキーを追加 • ソーシャルログインのボタンに”パスキーでログイン”を追加 • エラー発生時のケアが重要 28

Slide 29

Slide 29 text

パスキーを優先 • Identi fi er-Firstパターンのロジック変更 • メールアドレスやSMS番号、ユーザーIDを先に入力させ、パスキーが登録済みならパスキー認証を要求 • 登録済みパスキーがそこで使えるかは不明 29

Slide 30

Slide 30 text

パスキーの必須化 • あるユーザー、ある機能に対してパスキー認証を強制する • 対象ユーザー：全員 or ある条件を満たす場合 • 対象機能：サービスのログイン or 特定機能の利用時 • 法制度、業界ガイドライン、外部サービス利用のためのシステム要件、不正ログインによる実害に伴う要件など 30

Slide 31

Slide 31 text

導入のステップ 1. パスキー管理機能 2. 対象ユーザー、対象機能の場合にパスキー認証を要求 • 登録済みならば認証要求 • 未登録ならば登録フローへ 31

Slide 32

Slide 32 text

パスキー認証の必須化の難しさ • パスキー認証の強制自体が難しいわけではなく、”どうしても利用できないユーザー”を適切にケアできるかが重要 • 初めて利用する環境、既存のパスキーが同期されていない環境 • 非対応環境 32

Slide 33

Slide 33 text

パスキー同期の理想と現実 • ここまではいけそう • 単一パスワードマネージャーのパスキーをクロスプラットフォームで同期 -> 選択肢が増える • パスキーのお引越し(インポート、エクスポート) ≠同期 • これは難しそう • プラットフォームアカウント同士のパスキー同期 33

Slide 34

Slide 34 text

初めて利用する環境、既存のパスキーが同期されていない環境 • Webアプリを提供していれば比較的簡単に直面する状況 • パスキー認証が必須の場合 • ヘルプなどでHybrid Transportを補足して使ってもらう • 別の仕組みでクロスデバイスを実現 • パスキー認証が任意の場合 • 上記に加え、既存の認証方式へのフォールバック 34

Slide 35

Slide 35 text

非対応環境 • 様々なデバイスにブラウザが載っている現状において、非対応環境は0にはならない • パスキー認証が必須の場合: 諦めるしかない？ • 別の仕組みでクロスデバイスを実現 • パスキー認証が任意の場合 • 上記に加え、既存の認証方式へのフォールバック 35

Slide 36

Slide 36 text

パスキー管理機能 • サービスの内容が様々でも、パスキー管理機能のUXは汎用的なものが適用可能 • GoogleやFIDOアライアンスのUXガイドラインが参考にできる • パスキーについての説明、パスキーカード(登録済みの情報表示 )、ダイアログや確認フォーム 36

Slide 37

Slide 37 text

パスキー認証と一緒に提供したい機能 • ログインセッション管理機能 • 環境、認証方式の情報と合わせて管理 • 現時点で第３者にログインされていないことを確認 • 認証強度による追加認証要求などのハンドリングに利用可能 37

Slide 38

Slide 38 text

パスキー認証と一緒に提供したい機能 • セキュリティイベントログの生成と確認機能 • ログイン/ログアウト、パスキー関連操作をログに残す • 何があったのかを後から確認可能 • 自サービス内部だけではなく、連携サービスに送る仕組みも標準化されている 38

Slide 39

Slide 39 text

パスキー認証導入の先にある世界 39

Slide 40

Slide 40 text

パスキー認証＝理想のユーザー認証? • これまではパスワード認証の課題にフォーカスしていた • 今後はパスキー認証の課題にフォーカスする必要性がある • パスキー同期の限界、非対応環境、アカウントリカバリー • パスキー認証に対する脅威 40

Slide 41

Slide 41 text

パスキー認証における脅威 • デバイスへの物理アクセス • 物理的にスマートフォンを奪われる + ローカル認証突破 • 同一環境にいる人物によるローカル認証突破 • 正規のエクスポート機能を用いたパスキー情報吸い出し • Hybrid Transport+ソーシャルエンジニアリング攻撃によるログインセッション取得 41

Slide 42

Slide 42 text

仮定: SNSがパスキー認証に対応 1. 攻撃者:パスキー認証のHybrid Transport 用 QR表示 2. ターゲット:QR読み込み、パスキー認証成功 3. 攻撃者:ログインセッション取得成功 [悪用厳禁] Hybrid Transportの悪用 42 フォローでプレゼント！　　　

Slide 43

Slide 43 text

パスキー導入の先にある世界 • ユーザー認証については今後も脅威と対策の繰り返し • サービスを安全、便利に利用してもらうためには身元確認、 ID連携などと合わせて考える必要がある • マイナンバーカードの活用 • デジタル認証アプリ(OIDC) • Digital Identity Wallet 43

Slide 44

Slide 44 text

終わり質問どうぞ！ 44