ritou_user_authn_builderscon_tokyo_2018

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

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

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
11. パスワード、通知、多要素認証 • ユーザー識別 : メールアドレス / SMS / サービス内のID • 認証方法 : パスワード • 多要素認証 ◦ ワンタイムパスワード / セキュリティキー • リカバリー ◦ メール/SMSでURL/短い文字列を送信 ◦ リカバリーコード 11 よくある実装
12. パスワード、通知、多要素認証 • ユーザー識別 : メールアドレス / SMS / サービス内のID • 認証方法 : パスワード • 多要素認証 ◦ ワンタイムパスワード / セキュリティキー • リカバリー ◦ メール/SMSでURL/短い文字列を送信 ◦ リカバリーコード 12 よくある実装 ←←←←←←← 複雑になりがち ←←←←←←←
13. アカウントライフサイクルと認証方法の設定 • 新規登録時 ◦ メールアドレス / SMS の確認 -> リカバリー ◦ パスワード設定 -> パスワード認証 • アカウント設定から ◦ 多要素認証の設定 : ワンタイムパスワード, SecurityKey ◦ リカバリーコードの払い出し 13
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/
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