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

    View full-size slide

  2. ● エヴァンジェリスト @ OpenID ファウンデーション ジャパン
    ○ OAuth / OpenID Connect
    ○ 「OAuth 2.0 脆弱性」で検索→
    ● エンジニア @ 株式会社ミクシィ
    ○ Identity, Platform
    ● #idcon
    2
    Ryo Ito @ritou

    View full-size slide

  3. パスワード認証
    3

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  6. パスワード認証の現実
    ● 推測困難な文字列は考えられない -> 簡単なパスワード
    ● 複数覚えられない -> 使い回しからのパスワードリスト攻撃
    ● ばらつくサービスの仕様や運用に振り回されるユーザー
    ○ 英数のみ、最長●文字、記号を少なくとも
    ○ メールで送信してみたり、漏洩してみたり
    ○ 定 期 変 更 は 必 要 で す か
    6

    View full-size slide

  7. パスワード認証をやめるべき理由
    ● ユーザーへの負担
    ○ ユーザーのスペック不足
    ● サービス側のコスト、リスク
    ○ CSによるリカバリー対応
    ○ 漏洩対策
    ○ 攻撃対策
    7

    View full-size slide

  8. 本セッションについて
    8
    ● パスワードレスなユーザー認証が注目されている
    ● 開発者は何をすべき?
    ● 自分のサービスをパスワードレスにする準備をしよう
    現状
    最新
    動向
    課題

    対策

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  11. アカウントライフサイクルと認証方法の設定
    ● 新規登録時
    ○ メールアドレス / SMS の確認 -> リカバリー
    ○ パスワード設定 -> パスワード認証
    ● アカウント設定から
    ○ 多要素認証の設定 : ワンタイムパスワード, SecurityKey
    ○ リカバリーコードの払い出し
    13

    View full-size slide

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

    View full-size slide

  13. なぜソーシャルログイン + パスワード?
    ● IdP、IdP上のアカウントに問題が発生したときへの準備
    ● 「パスワード確認」機能
    16

    View full-size slide

  14. アカウントライフサイクルと認証方法の設定
    ● 新規登録時
    ○ ソーシャルログイン : 確認済みメアド/SMSがあればリカバリー用途に
    ○ (サービスによっては)パスワード設定 : パスワード認証
    ● アカウント設定から
    ○ 多要素認証の設定 : ワンタイムパスワード, SecurityKey
    ○ リカバリーコードの払い出し
    17

    View full-size slide

  15. 最新動向
    18

    View full-size slide

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

    View full-size slide

  17. FIDO
    ● FIDO 1.0
    ○ UAF (Universal Authentication Framework) : パスワードレスなユー
    ザー認証のための仕様
    ○ U2F (Universal Second Factor) : 2要素認証のための仕様
    ● FIDO 2.0 = UAF + U2F
    20

    View full-size slide

  18. Web Authn(Web Authentication) API
    ● FIDO 2.0 の Web API仕様
    ○ https://www.w3.org/TR/webauthn/
    ● 登録 : navigator.credentials.create() 認証情報の生成
    ● 認証 : navigator.credentials.get() 認証情報の参照
    21

    View full-size slide

  19. 22
    https://webauthn.org/

    View full-size slide

  20. 登録フロー
    29

    View full-size slide

  21. 登録フロー
    30

    View full-size slide

  22. 登録フロー
    31
    ① RP Serverがブラウザにデータを送信
    ● チャレンジ
    ● ユーザー情報 : 対象ユーザーのID, 表示名など
    ● RP情報 : ドメインなど

    View full-size slide

  23. 登録フロー
    32
    ② ブラウザはAuthenticator に新しい認証情報を要求
    -> authenticatorMakeCredential を呼び出す

    View full-size slide

  24. 登録フロー
    33
    ③ Authenticator はユーザーの確認の後、新しい鍵ペアと証明書を生成
    ● ユーザーの確認 : ローカル認証
    ○ 存在するか
    ○ 登録に同意しているか
    ● 鍵ペアの生成
    ○ 秘密鍵は安全に保存
    ● 証明書
    ○ 公開鍵を含む
    ● チャレンジへの署名
    ○ 秘密鍵で署名生成

    View full-size slide

  25. 登録フロー
    34
    ④ Authenticator はブラウザにデータを返す

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  32. 認証フロー
    41

    View full-size slide

  33. 認証フロー
    42

    View full-size slide

  34. 認証フロー
    43

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  37. 課題と対策
    46

    View full-size slide

  38. どのようにしてパスワードレスを実現できるか
    ● 新規サービス : パスワード認証を使わない
    ● 既存サービス : パスワード認証を使うのをやめる
    1. 新たな認証方式の提供
    2. 新たな認証方式への移行
    3. パスワード認証の撤廃
    47

    View full-size slide

  39. 課題 :
    ● どの認証方式を使う?
    ● UXはどうなる?
    ● パスワード確認してたとこ、どうする?
    48

    View full-size slide

  40. 現状のパスワードレスな認証方式
    ● メール/SMSにて認証コードを送信/検証
    ● ソーシャルログイン
    ● バックアップコード
    ○ ユーザーパスワードではないという意味合い
    ● 特定のモバイル端末で操作を行うことでログインさせる
    ○ 考えていくと Web Authnっぽくなる
    49

    View full-size slide

  41. UXの変化 : 登録フロー
    ● 今まで
    ○ メールアドレス/SMS の確認 -> パスワード設定 -> 完了
    ○ メールアドレス/SMS 入力 + パスワード設定 -> 完了 + 後で確認
    ● パスワードレス :
    ○ メールアドレス/SMS の確認 -> 完了
    ○ メールアドレス/SMS の確認 -> 他の認証方法設定 -> 完了
    50

    View full-size slide

  42. UXの変化 : ログインフロー
    ● 今まで : パスワード認証が最優先、ダメならリカバリーフロー
    ○ パスワード認証 -> 完了
    ○ パスワード認証 -> リカバリー -> 完了
    ● パスワードレス : ユーザーに紐づく認証方式毎に処理を分岐
    ○ メールアドレス/SMS入力 -> 設定済みの認証フロー -> 完了
    ■ GoogleみたいなUXに近いイメージ
    51

    View full-size slide

  43. 「パスワード確認」相当の処理、どうするか
    ● 決済/アカウント情報変更など、重要な処理の前に行われてる
    ● どの認証方式で代替するかのキメが必要
    ○ ユーザー認証と同等 (例 : Yahoo! JAPAN)
    ○ ローカル認証 : 画面ロック解除、PIN...
    52

    View full-size slide

  44. まとめ
    ● パスワード認証を安全に運用することは困難
    ● WebAuthn APIによる新しい認証方式はすぐそこまで来ている
    ● 今ある認証方式でもパスワードレスは始められる
    ● パスワード認証への依存を意識しよう
    53

    View full-size slide

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

    View full-size slide