ritou_user_authn_builderscon_tokyo_2018

658c29959d8a9fd352afa440a5813137?s=47 ritou
September 07, 2018

 ritou_user_authn_builderscon_tokyo_2018

パスワードレスなユーザー認証時代を迎えるためにサービス開発者がしなければならないこと - builderscon tokyo 2018

builderscon tokyo 2018にて発表したスライドです。
https://builderscon.io/tokyo/2018/session/9f0ac19c-0367-4307-a3d4-e5431d80267e

658c29959d8a9fd352afa440a5813137?s=128

ritou

September 07, 2018
Tweet

Transcript

  1. パスワードレスな ユーザー認証時代を迎えるために サービス開発者が しなければならないこと 1 @ritou builderscon tokyo 2018

  2. • エヴァンジェリスト @ OpenID ファウンデーション ジャパン ◦ OAuth / OpenID

    Connect ◦ 「OAuth 2.0 脆弱性」で検索→ • エンジニア @ 株式会社ミクシィ ◦ Identity, Platform • #idcon 2 Ryo Ito @ritou
  3. パスワード認証 3

  4. パスワード認証に求められる環境 • 推測が困難な文字列を考えられるユーザー • (複数の)文字列を覚えられる/思い出せるユーザー • ユーザーを安全に保護するサービス 4

  5. パスワード認証に求められる環境 • 推測が困難な文字列を考えられるユーザー • (複数の)文字列を覚えられる/思い出せるユーザー • ユーザーを安全に保護するサービス 特定デバイス不要の 最強の認証方式 5

  6. パスワード認証の現実 • 推測困難な文字列は考えられない -> 簡単なパスワード • 複数覚えられない -> 使い回しからのパスワードリスト攻撃 •

    ばらつくサービスの仕様や運用に振り回されるユーザー ◦ 英数のみ、最長•文字、記号を少なくとも ◦ メールで送信してみたり、漏洩してみたり ◦ 定 期 変 更 は 必 要 で す か 6
  7. パスワード認証をやめるべき理由 • ユーザーへの負担 ◦ ユーザーのスペック不足 • サービス側のコスト、リスク ◦ CSによるリカバリー対応 ◦

    漏洩対策 ◦ 攻撃対策 7
  8. 本セッションについて 8 • パスワードレスなユーザー認証が注目されている • 開発者は何をすべき? • 自分のサービスをパスワードレスにする準備をしよう 現状 最新

    動向 課題 & 対策
  9. 現状 9

  10. 10

  11. パスワード、通知、多要素認証 • ユーザー識別 : メールアドレス / SMS / サービス内のID •

    認証方法 : パスワード • 多要素認証 ◦ ワンタイムパスワード / セキュリティキー • リカバリー ◦ メール/SMSでURL/短い文字列を送信 ◦ リカバリーコード 11 よくある実装
  12. パスワード、通知、多要素認証 • ユーザー識別 : メールアドレス / SMS / サービス内のID •

    認証方法 : パスワード • 多要素認証 ◦ ワンタイムパスワード / セキュリティキー • リカバリー ◦ メール/SMSでURL/短い文字列を送信 ◦ リカバリーコード 12 よくある実装 ←←←←←←← 複雑になりがち ←←←←←←←
  13. アカウントライフサイクルと認証方法の設定 • 新規登録時 ◦ メールアドレス / SMS の確認 -> リカバリー

    ◦ パスワード設定 -> パスワード認証 • アカウント設定から ◦ 多要素認証の設定 : ワンタイムパスワード, SecurityKey ◦ リカバリーコードの払い出し 13
  14. 14

  15. ソーシャルログイン • 外部の Identity Provider のアカウントを利用 • ソーシャルログイン機能のみを利用している場合、そのサービス上 ではパスワードレスと言えるかも •

    パスワード認証とセットで利用されることも多い 15
  16. なぜソーシャルログイン + パスワード? • IdP、IdP上のアカウントに問題が発生したときへの準備 • 「パスワード確認」機能 16

  17. アカウントライフサイクルと認証方法の設定 • 新規登録時 ◦ ソーシャルログイン : 確認済みメアド/SMSがあればリカバリー用途に ◦ (サービスによっては)パスワード設定 :

    パスワード認証 • アカウント設定から ◦ 多要素認証の設定 : ワンタイムパスワード, SecurityKey ◦ リカバリーコードの払い出し 17
  18. 最新動向 18

  19. キーワード • FIDO 2.0 • Web Authn(Web Authentication) API 19

  20. FIDO • FIDO 1.0 ◦ UAF (Universal Authentication Framework) :

    パスワードレスなユー ザー認証のための仕様 ◦ U2F (Universal Second Factor) : 2要素認証のための仕様 • FIDO 2.0 = UAF + U2F 20
  21. Web Authn(Web Authentication) API • FIDO 2.0 の Web API仕様

    ◦ https://www.w3.org/TR/webauthn/ • 登録 : navigator.credentials.create() 認証情報の生成 • 認証 : navigator.credentials.get() 認証情報の参照 21
  22. 22 https://webauthn.org/

  23. 23

  24. 24

  25. 25

  26. 26

  27. 27

  28. 28

  29. 登録フロー 29

  30. 登録フロー 30

  31. 登録フロー 31 ① RP Serverがブラウザにデータを送信 • チャレンジ • ユーザー情報 :

    対象ユーザーのID, 表示名など • RP情報 : ドメインなど
  32. 登録フロー 32 ② ブラウザはAuthenticator に新しい認証情報を要求 -> authenticatorMakeCredential を呼び出す

  33. 登録フロー 33 ③ Authenticator はユーザーの確認の後、新しい鍵ペアと証明書を生成 • ユーザーの確認 : ローカル認証 ◦

    存在するか ◦ 登録に同意しているか • 鍵ペアの生成 ◦ 秘密鍵は安全に保存 • 証明書 ◦ 公開鍵を含む • チャレンジへの署名 ◦ 秘密鍵で署名生成
  34. 登録フロー 34 ④ Authenticator はブラウザにデータを返す

  35. 登録フロー 35 ⑤ ブラウザが RP Server にデータを渡す • clientData •

    attestationObject
  36. 36 ⑤ RP Server がデータを検証し、登録処 理を行う • 保存するのは公開鍵

  37. 37 https://auth0.com/blog/introduction-to-web-authentication/

  38. 認証フロー 38 ① RP Serverがブラウザにデータを送信 • チャレンジ • 公開鍵のidも指定可能

  39. 認証フロー 39 ② ブラウザはAuthenticator に認証情報を要求

  40. 認証フロー 40 ③ Authenticator はユーザー確認後、保存している秘密鍵に紐づく認証情報を生成 • ユーザーの確認 : ローカル認証 ◦

    存在するか ◦ 登録に同意しているか • 秘密鍵の呼び出し • 証明書 ◦ 公開鍵を含む • チャレンジへの署名 ◦ 秘密鍵で署名生成
  41. 認証フロー 41

  42. 認証フロー 42

  43. 認証フロー 43

  44. 44 https://auth0.com/blog/introduction-to-web-authentication/

  45. WebAuthn APIを用いる認証が定着するまでは • ブラウザの対応 • Authenticator の普及 • ユーザーへの啓蒙 45

  46. 課題と対策 46

  47. どのようにしてパスワードレスを実現できるか • 新規サービス : パスワード認証を使わない • 既存サービス : パスワード認証を使うのをやめる 1.

    新たな認証方式の提供 2. 新たな認証方式への移行 3. パスワード認証の撤廃 47
  48. 課題 : • どの認証方式を使う? • UXはどうなる? • パスワード確認してたとこ、どうする? 48

  49. 現状のパスワードレスな認証方式 • メール/SMSにて認証コードを送信/検証 • ソーシャルログイン • バックアップコード ◦ ユーザーパスワードではないという意味合い •

    特定のモバイル端末で操作を行うことでログインさせる ◦ 考えていくと Web Authnっぽくなる 49
  50. UXの変化 : 登録フロー • 今まで ◦ メールアドレス/SMS の確認 -> パスワード設定

    -> 完了 ◦ メールアドレス/SMS 入力 + パスワード設定 -> 完了 + 後で確認 • パスワードレス : ◦ メールアドレス/SMS の確認 -> 完了 ◦ メールアドレス/SMS の確認 -> 他の認証方法設定 -> 完了 50
  51. UXの変化 : ログインフロー • 今まで : パスワード認証が最優先、ダメならリカバリーフロー ◦ パスワード認証 ->

    完了 ◦ パスワード認証 -> リカバリー -> 完了 • パスワードレス : ユーザーに紐づく認証方式毎に処理を分岐 ◦ メールアドレス/SMS入力 -> 設定済みの認証フロー -> 完了 ▪ GoogleみたいなUXに近いイメージ 51
  52. 「パスワード確認」相当の処理、どうするか • 決済/アカウント情報変更など、重要な処理の前に行われてる • どの認証方式で代替するかのキメが必要 ◦ ユーザー認証と同等 (例 : Yahoo!

    JAPAN) ◦ ローカル認証 : 画面ロック解除、PIN... 52
  53. まとめ • パスワード認証を安全に運用することは困難 • WebAuthn APIによる新しい認証方式はすぐそこまで来ている • 今ある認証方式でもパスワードレスは始められる • パスワード認証への依存を意識しよう

    53
  54. 終わりです • こっそり質問がある方 -> @ritou まで • この分野、もっと詳しく知りたくなったら -> idcon

    54