Upgrade to Pro — share decks privately, control downloads, hide ads and more …

ritou_user_authn_builderscon_tokyo_2018

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

ritou

September 07, 2018
Tweet

More Decks by ritou

Other Decks in Technology

Transcript

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

    Connect ◦ 「OAuth 2.0 脆弱性」で検索→ • エンジニア @ 株式会社ミクシィ ◦ Identity, Platform • #idcon 2 Ryo Ito @ritou
  2. パスワード認証の現実 • 推測困難な文字列は考えられない -> 簡単なパスワード • 複数覚えられない -> 使い回しからのパスワードリスト攻撃 •

    ばらつくサービスの仕様や運用に振り回されるユーザー ◦ 英数のみ、最長•文字、記号を少なくとも ◦ メールで送信してみたり、漏洩してみたり ◦ 定 期 変 更 は 必 要 で す か 6
  3. 10

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

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

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

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

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

    パスワード認証 • アカウント設定から ◦ 多要素認証の設定 : ワンタイムパスワード, SecurityKey ◦ リカバリーコードの払い出し 17
  9. FIDO • FIDO 1.0 ◦ UAF (Universal Authentication Framework) :

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

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

  12. 24

  13. 25

  14. 26

  15. 27

  16. 28

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

    対象ユーザーのID, 表示名など • RP情報 : ドメインなど
  18. 登録フロー 33 ③ Authenticator はユーザーの確認の後、新しい鍵ペアと証明書を生成 • ユーザーの確認 : ローカル認証 ◦

    存在するか ◦ 登録に同意しているか • 鍵ペアの生成 ◦ 秘密鍵は安全に保存 • 証明書 ◦ 公開鍵を含む • チャレンジへの署名 ◦ 秘密鍵で署名生成
  19. 認証フロー 40 ③ Authenticator はユーザー確認後、保存している秘密鍵に紐づく認証情報を生成 • ユーザーの確認 : ローカル認証 ◦

    存在するか ◦ 登録に同意しているか • 秘密鍵の呼び出し • 証明書 ◦ 公開鍵を含む • チャレンジへの署名 ◦ 秘密鍵で署名生成
  20. UXの変化 : 登録フロー • 今まで ◦ メールアドレス/SMS の確認 -> パスワード設定

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

    完了 ◦ パスワード認証 -> リカバリー -> 完了 • パスワードレス : ユーザーに紐づく認証方式毎に処理を分岐 ◦ メールアドレス/SMS入力 -> 設定済みの認証フロー -> 完了 ▪ GoogleみたいなUXに近いイメージ 51