webauthn_study_ritou.pdf

Transcript

1. 1.

   WebAuthnの導入事例から見る 定石と今後の課題 @ritou #webauthn_study 2019/10/28

2. 2.

   @ritou

3. 3.

   本日の内容 •事例から導入のポイントを整理 •2段階/2要素としての導入 •「パスワードレス」としての導入 •GOAL:不安になりそうな部分を認識し て導入に向けた一歩を踏み出す

4. 4.

   ２段階/2要素としての導入

5. 5.

   の前に、リカバリーの話

6. 6.

   by 誰か “FIDOはリカバリーが課題だよね”

7. 7.

   アカウントリカバリー •利用不可能になったクレデンシャルの無効 化&再設定 •パスワード •TOTP(Secret) •リカバリーコード •Authenticator(PublicKey) •別の認証方式 or 複数登録

   に収束
8. 8.

   パスワード認証における リカバリー •忘れた •別の認証方式 + 再設定 •利用できない環境 •覚えてればあらゆる環境で利用可能

9. 9.

   SMS/Emailへ通知における リカバリー •番号、メアドが変わった •別の認証方式 + 無効化/再設定 •一時的に利用できない環境、状況 •別の認証方式

10. 10.

    TOTPにおける リカバリー •手元の端末の設定消した、落とした •別の認証方式 + 無効化/再設定 •一時的に利用できない環境、状況 •別の認証方式

11. 11.

    リカバリーコードの リカバリー(?) •紛失、盗難 •別の認証方式 + 無効化/再発行 •一時的に利用できない環境、状況 •別の認証方式

12. 12.

    FIDOにおける リカバリー •紛失、盗難 •別の認証方式もしくは複数登録可能 にして無効化/再設定 •利用できない環境 •別の認証方式

13. 13.

    リカバリーは それほど問題ではない

14. 14.

    (改めて) ２段階/2要素としての導入

15. 15.

    導入事例 •Google, Github… •パスワード認証との組み合わせ •間違っても単一要素で通さない

16. 16.

    どこに手を入れるか •アカウント設定 •認証 •再認証 •(2段階/2要素が必須でない限りは)新 規登録の対応は任意

17. 17.

    アカウント設定 •追加認証を有効にする •リカバリー設定 : 別の認証方式を用意 •SMS/Emailによる通知 •リカバリーコード設定 •Authenticator(PublicKey)設定 •名前をつけるタイミング?

18. 18.

    アカウント設定 (Github)

19. 19.

    認証 •パスワード認証+追加認証を要求 •複数ある場合に優先する認証方式? •設定やWebAuthnの利用可否で分岐? •別の認証方式への切り替え •スキップ機能 = Cookieの所持認証?

20. 20.

    認証(Github)

21. 21.

    再認証 •例 : Github •「パスワード確認」していたところ に WebAuthn が利用可能

22. 22.

    再認証(Github)

23. 23.

    検討事項

24. 24.

    (検討事項) リカバリー用の認証方式 •海外サービスでは最低でも2つは用意 している模様 •SMS •リカバリーコード •カスタマーサポートの負担が決まる

25. 25.

    (検討事項) 利用可能な環境の制限 •制限する場合は管理が必要 •User-Agent •Platform or Cross-platform •Attestation

26. 26.

    (検討事項) 追加認証要求のタイミング •パスワード認証「成功」したら要求 •パスワード認証結果に関わらず要求 •パスワード認証前に要求

27. 27.

    まとめ •アカウント設定のあたりは定石と呼 べるものができており、環境を縛る かどうかぐらいか •認証部分はまだ考慮すべき点がある かも？

28. 28.

    パスワードレスとしての導入

29. 29.

    2段階/2要素に比べて なんとなく不安？

30. 30.

    やはりリカバリー？

31. 31.

    (あなたの思う) パスワードレスとは？ •パスワードを使わない •所持 or 生体 or 記憶(ローカル?) •FIDO UP(UserPresent)はNG?

    •FIDO UV(UserVerified)相当 •所持 + (記憶 or 生体)
32. 32.

    パスワードを使わない •単一要素の認証方式とFIDO UVの組み 合わせ •SMS/Email/Pushへの通知 •ソーシャルログイン •緩いとこに攻撃を受ける覚悟が必要

33. 33.

    FIDO UV相当 •複数要素の認証方式が必要 •それがなかったからFIDOなんだろ？ •他のサービスで2段階/2要素してる IdPとのID連携? •IdPがMFAを保証してくれたら使え そう -> OpenID

    Connect!
34. 34.

    どこに手を入れるか •アカウント設定 •認証 •再認証 •新規登録(FIDO必須な場合)

35. 35.

    検討事項

36. 36.

    (検討事項) Resident Keyの利用 •サービスのユーザー識別を先にする かどうか •メアドやSMSを入れる手間を減らせ るか? •RK非対応環境ではどうする？

37. 37.

    RedidentKey利用アリ (Microsoft)

38. 38.

    RedidentKey利用ナシ (Y!J)

39. 39.

    (検討事項) 新規登録フロー、リカバリー •リカバリー考慮して効率的に２種類 の認証方式を設定するには？ •新規登録も要件の分解が必要 •連絡先、属性情報、クレデンシャル •#iddance でやるよ

40. 40.

    まとめ •リカバリー用に別の認証方式は必要 •サービスが必要とする認証要素によ り、実装に幅が出そう •新規登録フローについてはまだ手本 となるサービスはなさそう

41. 41.

    終わり •質問などは @ritou までください •11/1(金)に #iddance やります