認証にまつわるセキュリティの新常識

 認証にまつわるセキュリティの新常識

2016-2017年でのNIST SP800-63-3改定を通じて、認証を含むデジタルアイデンティティの世界では様々な議論が湧き起こりました。

そんな本ガイドラインの内容を通じて、デジタルアイデンティティフレームワークを考える上での共通言語、特に「認証方法」について記載したNIST SP800-63Bについての理解と体得を試みつつ、議論になったいくつかのテーマについて取り上げて、この領域の面白さに触れてみます。

正式fix後に話した内容に、2段階認証と2要素認証、Windowsポリシー変更など少し新しい味付けをして再構成し、InternetWeek2018で話す時に使いました。

Transcript

  1. 認証にまつわる セキュリティの新常識 rev.2 Internet Week ショーケース in 仙台| 2019.05.31 |

    東北大学片平キャンパス 勝原 達也
  2. 本資料は”Internet Week 2018”にて利用した版に 一部改定を施したものです。

  3. 勝原 達也/Tatsuya Katsuhara https://www.linkedin.com/in/kthrtty • NDIAS(現在) • コネクテッドカーのセキュリティ • 車両評価Gマネージャ

    • NRIセキュアテクノロジーズ • Web/プラットフォーム脆弱性診断 • IoT/制御/重要インフラセキュリティ • ハードウェアセキュリティ • 野村総合研究所 • デジタル・アイデンティティ • 認証システム/APIプラットフォーム構築 • OpenID Foundation JAPAN設立活動 • OAuth/OpenIDに関する開発 本日のテーマ& ライフワーク
  4. 認証

  5. 日本語訳、根深い問題

  6. None
  7. Certificationが上に書いてある

  8. None
  9. None
  10. https://www.geotrust.co.jp/support/glossary/ca.html

  11. 認証局 Certification Authority

  12. None
  13. (通称) 技適認証 Technical Standards Conformity Certification

  14. None
  15. 認証済みアカウント Verified Account

  16. 相互認証 Cross Certification Mutual Authentication

  17. なんのこっちゃ

  18. 身の回りにあふれている ≒単純な概念に思えてくる ≒決めつけがち ≒議論がかみ合わない ≒地味に苦労する

  19. 本日のテーマ 認証/Authentication

  20. 本日お伝えしたいこと • 認証およびデジタルアイデンティティを考えるために有用な 共通言語をNIST SP800-63-3の考え方を通じて知る • 認証にフォーカスした63Bを通じてAuthenticator種別を知る • SP800-63-3の改定の過程で巻き起こった議論と、 その背景にあるメッセージを考えてみる

    • デジタルアイデンティティのセキュリティの面白さを知る https://www.flickr.com/photos/alexristea/5636821732/
  21. NIST SP800-63-3とは • NIST SP800-63-3は米国政府機関 向けに、デジタルアイデンティティ フレームワークについて言及したガ イドライン • 日本の事業者には何ら役務が発生す

    ることはない • エッセンスと考え方はとても有用で、 様々な業界から参照されている • Fit&Gapしてリスク分析して流用す ることは良いアプローチ(なはず) https://pages.nist.gov/800-63-3/ OIDFJでの活動 兼 趣味で翻訳 https://openid-foundation-japan.github.io/800-63-3-final/ ※違和感のある訳の改善のためプルリクお願いします
  22. デジタル認証の ガイドライン 登録プロセス 身元確認 認証と ライフサイクル管理 フェデレーションと アサーション 興味キーワード NIST

    SP800-63-3全体概要 本人確認 身元確認 窓口での対面確認 写真付き身分証明書 映像での遠隔身元審査 犯罪収益移転防止法 KYC(Known Your Customer) パスワード認証 パスワード定期変更 秘密の質問 多要素認証 SMS認証 バイオメトリクス アカウントリカバリ Federated Identity Single Sign On(SSO) SAML OAuth2.0 OpenID Connect Web API Authorization Identity Platform NIST SP800-63-3とは 本日の 対象
  23. NIST SP800-63-3とは IAL 1-3 (Identity Assurance Level) ユーザ認証の 確からしさ 連携方法の

    確からしさ 本日の 対象 例えば銀行 2 ユーザ身元確認の 確からしさ 例えばECサイト 2 2 1 2 - AAL 1-3 (Authenticator Assurance Level) FAL 1-3 (Federation Assurance Level)
  24. 63Bもくじ 目次 内容 4. Authenticator Assurance Levels 5. Authenticator及びVerifierの要件 付録A

    — 記憶シークレットの強度 • AAL毎の要件と、それに合致するAuthenticatorの話 • Authenticatorの種類や、備えるべき機能の話 6. Authenticatorライフサイクルの要件 • Authenticatorの発行、紛失、盗難、破棄などの要件 7. セッション管理 • セッションCookie、AccessToken、再認証など認証後の セッション維持とその保護に関わる話 8. 脅威とセキュリティに関する考慮事項 9. プライバシに関する考慮事項 • AuthenticatorやSessionに関するリスク要因および対策 • プライバシーリスクアセスメント、コントロールなどの話 10. ユーザビリティに関する考慮事項 • Authenticationのユーザビリティとビジネス影響 • Authenticatorライフサイクルを通じたユーザビリティ確保 本日の 対象
  25. 用語 • ユーザは文脈で区別される • Applicant→Subscriber→Claimant • Credential Service Provider •

    Applicant情報を確認・検証・登録 • SubscriberへAuthenticatorを発行 • Authentication(認証) • ClaimantがSubscriberであることを、 Authenticatorを用いて確認する行為 • Verifier • Authenticatorの出力を見て、 Subscriberかどうかを確認する • Relying Party • Verifierの確認結果に基づいて、 認証済みセッションを開始 アカウント をゲット! 登録したい! きちんと身元を 確認して ID/PW発行する! サービス使いたい から認証する! きちんと認証して 加入者だけにサービス する! 認証結果や加入者情報を 提供してもらったので サービスできる!
  26. Authenticatorのタイプ # 原文 和訳 認証要素 Something you *** 暗号プロトコル(鍵の所持 証明)の性質があるか

    HWとして 認められるか 1 Memorized Secret 記憶シークレット 知識 No No 2 Look-up Secret ルックアップシークレット 所有 No No 3 Out of Band Device 経路外デバイス 所有 No No 4 SF OTP Device 単一要素OTPデバイス 所有 No Yes/No※ 5 MF OTP Device 多要素OTPデバイス 所有+知識/生体 No Yes/No※ 6 SF Cryptographic Software 単一要素暗号ソフトウェア 所有 Yes No 7 SF Cryptographic Device 単一要素暗号デバイス 所有 Yes Yes 8 MF Cryptographic Software 多要素暗号ソフトウェア 所有+知識/生体 Yes No 9 MF Cryptographic Device 多要素暗号デバイス 所有+知識/生体 Yes Yes ※「デバイス」という呼称と、HWとして認められるかが一致しないので少々トリッキー
  27. Authenticatorのタイプ # Authenticatorのタイプ 内容 1 Memorized Secret 記憶シークレット ユーザが記憶するもの。 例:パスワードやPIN

    ※ローカル/リモートどちらであるか問わない。 2 Look-up Secret ルックアップシークレット Claimant(認証をしたい人)とCSP(認証情報を登 録・払い出す側)の間で共有されているシーク レット。 例:乱数表、Googleアカウントの二要素認証のリ カバリコードのようなもの 3 Out of Band 経路外 (RESTRICTED) セカンダリチャネルを介してVerifierと安全に通信 できるようなもの。 例:SMSによるコード送信、QRコード読み取り、 電話によるコード読み上げ/入力 ※今回の改定で、EメールやVoIPはセカンダリチャ ネルとして認められないとされた点に注意。
  28. Authenticatorのタイプ # Authenticatorのタイプ 内容 4 SF OTP Device 単一要素OTPデバイス 二要素目の入力によるアクティベーションを必要

    とせず、所持していることで認証を実施できる。 例:パスフレーズ入力不要なOTPデバイス(物理 OTPトークンや、Google Authenticatorなどスマホに インストールしたソフト含む) 5 MF OTP Device 多要素OTPデバイス SF OTP Deviceに更に二要素目の入力によるアクティ ベーションを追加したもの。 例:(スマホのロック解除とは別に)Touch IDやマ スタPWでアクティベートするOTPアプリ 6 SF Cryptographic Software 単一要素暗号ソフトウェア ディスクあるいはソフト媒体に記録された一意な 暗号鍵。鍵はデバイス上で最もセキュアなスト レージに保存されており、アクセスコントロール が施されている。 例:端末毎のクライアント証明書(PW保護無し) 7 SF Cryptographic Device 単一要素暗号デバイス 保護された暗号鍵を用いて認証を行うハードウェ アデバイス。鍵はデバイスで一意であり、エクス ポートできてはいけない。 例:FIDO U2FのUSBドングル(挿すだけ)
  29. Authenticatorのタイプ # Authenticatorのタイプ 内容 8 MF Cryptographic Software 多要素暗号ソフトウェア 単一要素暗号ソフトウェアに対して、更にアク

    ティベートするための2要素目が必要となったもの。 例:指紋認証を行うことで有効化されるクライア ント証明書 9 MF Cryptographic Device 多要素暗号デバイス 単一要素暗号デバイスに対して、更にアクティ ベートするための2要素目が必要となったもの。 例:パスワードまたはバイオメトリクスでアク ティベートしなければ利用できないようになって いるUSBトークン、指紋認証や顔認証でセキュアエ レメントをアクティベートするようなFIDO対応ス マホ。 注)なるべく具体例を入れていますが、NISTの基準においてFIPS140 Approvedかどうかなどが影響するため、厳密には該当しない 場合があります。
  30. AAL(Authenticator Assurance Level) • 「Claimant=Subscriberであること」の確認(認証)の信頼性を3段階に分類したもの • 観点は複数あり、同時に満たした場合に当該レベルに適合 • 認証要素(Something you

    ***)は同じ要素を2つ使っても1要素とカウント※ • 利用する暗号アルゴリズム要件は63-3記載の「承認済み(Approved)」なものを利用 要求事項 AAL 1 AAL 2 AAL 3 許容される Authenticator タイプ • 9タイプ全部OK(何でも良い) • Authenticator単独で2要素以上 • またはPW(知識)+2要素目(所有,特徴) • 2要素以上 • 暗号鍵の所持証明要素 • ハードウェア関与 • 記憶シークレット • ルックアップシークレット • 経路外 • 単一要素OTPデバイス • 多要素OTPデバイス • 単一要素暗号ソフトウェア • 単一要素暗号デバイス • 多要素暗号ソフトウェア • 多要素暗号デバイス • 多要素OTPデバイス • 多要素暗号ソフトウェア • 多要素暗号デバイス • 記憶シークレット+以下 • ルックアップシークレット • 経路外 • 単一要素OTPデバイス • 単一要素暗号ソフトウェア • 単一要素暗号デバイス • 多要素暗号デバイス • 単一要素暗号デバイス +記憶シークレット • 多要素OTPデバイス(SW/HW) +単一要素暗号デバイス • 多要素OTPデバイス(HW) +単一要素暗号ソフトウェア • 単一要素OTPデバイス(HW) +多要素暗号ソフトウェア • 単一要素OTPデバイス(HW) +単一暗号ソフトウェア +記憶シークレット ※単一要素を複数用いた場合の認証強度を否定するものではないが、尺度の基準を統一することが難しい。そのため 「多要素」という考え方ありき。
  31. 要求事項 AAL 1 AAL 2 AAL 3 許容される Authenticatorタイプ •

    9タイプ全部OK (何でも良い) • Authenticator単独で2要素以上 • またはPW(知識)+2要素目(所有,生体) • 2要素以上 • 暗号鍵の所持証明要素 • ハードウェア関与 FIPS 140適合 Level 1 (政府機関のVerifier) Level 1 (政府機関のAuthenticator及び Verifier) Level 1 総合 (Verifier及び単一要素暗号デバイス) Level 2 総合 (多要素Authenticator) Level 3 物理セキュリティ (全てのAuthenticator) 再認証 30 日 12 時間または30分間活動なしの場合に、 1つの認証要素を利用して再認証(任意) 12 時間または15分間活動なしの場合に、 両方の 認証要素を利用して再認証(必須) セキュリティ統制 [SP 800-53] 低い基準 (または 等価なもの) [SP 800-53] 中度の基準 (または等価なもの) [SP 800-53] 高い基準 (または等価なもの) 中間者攻撃耐性 必須 必須 必須 Verifierなりすまし 耐性(Phishing耐性) 不要 不要 必須 Verifier改竄耐性 不要 不要 必須 リプレイ耐性 不要 必須 必須 認証意図 (AuthN Intent) 不要 推奨 必須 レコード保持ポリシ 必須 必須 必須 プライバシ統制 必須 必須 必須 AAL(Authenticator Assurance Level)
  32. 読む際のコツ:要求記法および規則 • SHALL(するものとする)およびSHALL NOT(しないものとする) • 厳密に従うことを要求しており、内容と異なってはならない。 • SHOULD(すべきである)およびSHOULD NOT(すべきではない) •

    いくつかある選択肢の中で特定の推奨があることを示している。 • 他の選択肢については言及も除外もしない。 • 行動指針を推奨するが、必須であることまでは要求しない。(微妙な表現) • MAY(してもよい)およびNEED NOT(しなくてよい) • 行動指針が許容できることを示す。 • CAN(できる)およびCANNOT(できない) • 物質的、物理的、偶発的であるかに関わらず 可能性や能力があること。
  33. パスワードからパスフレーズへ https://xkcd.com/936/

  34. パスワードからパスフレーズへ • パスフレーズ前提 • 8文字以上(ランダム生成なら6文字以上)(SHALL) • 最低64文字(SHOULD) • 空白/Unicode(SHOULD) •

    他には複雑さ要件を課さない(SHOULD) • リスト突合で弱いPWをはじく(SHALL) • 漏洩PW、辞書、繰り返し/連番、文脈で特定 • ペースト機能(SHOULD) • パスワードマネージャ連携/使いまわし改善 • 可視化(SHOULD) • ラスト1文字表示、トグルで表示/非表示など • パスワード強度メーター(SHOULD) • (強度を正しく伝えられるかの議論あり) パスフレーズを推奨し、 桁数を伸ばす方向へ誘導 することで、総合的にセ キュリティ向上を図って いくというメッセージ。
  35. パスワード定期変更を求めない方向性 「ユーザに対し定期変更を要求すべきではない」(SHOULD) 「パスワードが危殆化した可能性があれば変更強制」(SHALL) →危殆化をモニタリングできるかという隠れた重めの課題も。 • 定期変更を通じてユーザは「弱いパスワード」を使うようにな るので、結局は突破されがち、という考えに基づく。 https://pages.nist.gov/800-63-FAQ/ • 米ノースカロライナ大学の研究(過去パスワードが分かれば、

    17%のユーザは5回以内の試行で現在パスワードが特定できる) https://www.ftc.gov/news-events/blogs/techftc/2016/03/time-rethink-mandatory-password-changes 大文字/数字 記号 桁数 定期変更#1 定期変更#2 password Passw0rd P@ssw0rd P@ssw0rd! P@ssw0rd!1 P@ssw0rd!2
  36. 完全に廃止された「秘密の質問」 • SP800-63-2では”Pre-registered Knowledge Token”と呼称。 • Knowledge Based Authentication(KBA)とも言われる。 •

    SP800-63-3では記憶シークレットの一部として扱われ、 「やってはいけない」(SHALL)記憶シークレットの例としてわ ざわざ記載されることになった。(例:ペットの名前) • 「アカウントリカバリ」の難易度が増加。 • 生年月日(ソーシャルエンジニアリングの餌食なので問題外) • メールアドレス(経路外Authenticatorでは禁止だが・・・) • SMS(RESTRICTEDだが・・・)
  37. 地味に影響しそうな乱数表の制限追加 • 各セルの値の使い回しが禁止 (SHALL) • NISTは「日本的」な乱数表の利用は考慮されていない • 二要素認証の有効化時に発行されるような「回復コード表」は許容 以前 何回でもセルの値を使ってよい。

    日本における乱数表イメージ (例:キャッシュカード裏面) 今後 各セルは1回しか使えない。
  38. バイオメトリクスの位置付け 単独でAuthenticatorとして認めないが、2要素目として補助的 には利用して良い 理由はいくつか挙げられている。 • False Matching Rate(誤合致率)が低く抑えられようと、 認証行為の確実性に繋がるわけではない。 •

    バイオメトリクスは確率的なもの • 特徴点情報(テンプレート) の保護や無効化の標準不在 • バイオメトリクス特性はシークレットではない • プレゼンテーション攻撃を防ぐPADは今後必須要件になる見込み。
  39. 経路外認証は使えるが”RESTRICTED” • ドラフト改訂の当初は、公衆交換電話網(PSTN)を使っている 場合、SMSの経路外認証は非推奨になり、大盛り上がり • 最終的には”RESTRICTED”という経過観察的な処遇。 • 他にも事業者にとって重要な要件がいくつか • VoIP/EメールはNG(特定デバイスの所持証明にならない)(SHALL)

    • 事前登録済みの電話番号は物理デバイスと結びついていることを確認 • スマホのPush通知インフラはセカンダリチャネルとして有効 • 「アカウントリカバリ」は特別な要件が追加 • 電話番号の変更は新しいAuthenticatorのバインディングとみなされる。
  40. バインディング • Authenticatorの登録・追加・交換・廃止のプロセス。 • ライフサイクルを通じて、AAL維持を意識したプロセスが必要。 登録時バインディング(IAL x) 登録後バインディング(AAL x<=) バインドされ

    た状態 未バインド 状態 同時にバインド実施 リモートトランザクション(途切れてしまう場合) • 一時シークレット(TEL、Email、住所へ送付)を用いて再開 ローカルトランザクション(途切れてしまう場合) • 一時シークレット(TEL、Email、住所へ送付)を用いて再開(再利用禁止) • バイオメトリクス利用 あるAALに必要な Authenticatorが一部ま たは全部利用不能 Authenticator追加(AAL1手段の複数登録または、AAL2にアップグレード) • 追加するAuthenticatorが利用されるAAL以上で認証。 • 通常は、保有しているAuthenticatorのAALで新Authenticatorを登録。 • AALのアップグレード(AAL1→2のみ)実施。 所有する一部のAuthenticatorが紛 失、盗難、破損、有効期限切れ、 失効 所有する一部のAuthenticatorが紛失、 盗難、破損、有効期限切れ、失効 置き換え( AAL2/3の場合のAuthentication要素不足に対応) • 基本的にはIdentity Proofingを伴う当初のリモート/ローカル トランザクションと同様のバインディング手続きを実施 • 一時シークレットまたはバイオメトリクス利用 紛失、盗難、破損、有効期限 切れなどで失効、または解約 したAuthenticatorのバイン ディングは削除する必要あり。 (63-A記載のIdentity Proofingを伴う) 63B記載内容から作成した簡易な状態遷移例
  41. AALを意識したアカウントリカバリは難しい • アカウントリカバリは難しく脆弱になりがち≒狙われやすい • パスワードを覚えていれば、2要素でのリカバリには定石あり • パスワード(知識)+アカウントの回復コード(所有) • スマホ紛失でOTPアプリが使えない、などの問題解決 •

    パスワードを忘れると、2要素でのリカバリは難しい • 別のパスワードを事前登録・・・どうせそれも忘れる&秘密の質問NG • 指紋を予め登録しておけば・・・ハードル高い
  42. パスワード忘れのリカバリはイレギュラー • Identity Proofing(63A)でも言及される「物理」的な Authenticatorを2つ使い、確認コード送付/検証(MAY)という方 法が例示されてはいるが・・・ • 2要素確保できずとも、2物理Authenticatorで良いということ • 郵送で確認コード送付(物理/経路外)+USBキー(物理/所有)

    • 本当に「物理」Authenticator使わないといけないの?
  43. 受信した 確認コードを入力 パスワード再設定 2段階認証(認証要素は1つ)で ログイン完了 確認コードを メールアドレスに 送信開始 登録済みの認証要素いずれか (FIDO,

    OTP, SMS, 回復コード) ※全て「所有」要素
  44. アカウントを識別 設定済みのOTP (所有)を実施 マスク済み情報は 値を入力させる メールアドレス/SMSに 届いた確認コードを入力 2段階認証(認証要素は 1つ)でログイン完了 登録済みの認証要素どれか

    (メール、SMS, 回復コード) ※OTPは使用済み判定 ※Windows Helloで生体要素 が増えるかも。
  45. Eメールの取り扱いには曖昧さが残る • Google/Microsoftでは「Eメール」での確認コード送付も活用 • FIDOドングル、OTP、SMS、回復コード、Eメールの組み合わせ。 • 「所有」1要素になりがちだが、2つの手段の利用はきっちり実施。 • アカウントリカバリ時の確認コード送付は根深い問題 •

    経路外AuthenticatorとしてのEメールは使えない(SHALL)としながら も「現実的には使わざるをえない」というのが、コンシューマ向け サービスでの落とし所と言えそう。 • IAL2,3において「Identity Proofingを伴う当初のリモート/ローカル トランザクションと同様のバインディング手続きを実施」することが 例示されており、Eメールによるリカバリが有効という解釈と考えられ るが・・・(→バインディング参照)
  46. 派生トピック:PCI DSS

  47. Multi-Step vs. Multi-Factor • 多段階認証と多要素認証 • アクセス許可するまえに全ての要素 の認証が成功しなければならない • 全ての要素が提示されるまで認証の

    成否が分かってはならない “Multi-Factor Authentication version 1.0” https://www.pcisecuritystandards.org/pdfs/Multi-Factor- Authentication-Guidance-v1.pdf https://www.flickr.com/photos/31176607@N05/with/34684294971/
  48. MicrosoftはNGということ? • 2段階認証かつ2要素認証なUX。 • 識別後に1要素目の認証。それが成功してから2要素目の認証。 まずは識別 1次認証 (Something you know)

    1要素目で認証済みの状態で 2要素目(Something you have)で2次認証
  49. GoogleはNGということ? • 2段階認証かつ2要素認証なUX。 • 識別後に1要素目の認証。それが成功してから2要素目の認証。 まずは識別 1次認証 (Something you know)

    1要素目で認証済みの状態で 2要素目(Something you have)で2次認証
  50. • 2段階認証かつ2要素認証なUX。 • 識別後に1要素目の認証。それが成功してから2要素目の認証。 AWSはNGということ? まずは識別 1次認証 (Something you know)

    1要素目で認証済みの状態で 2要素目(Something you have)で2次認証
  51. 結局Multi-Step AuthenticationはOKに • コミュニティでの質問が相次ぎ、条件付きで認め られることに。 • 3つの認証要素のうち最低2つを利用すること。 • ある認証メカニズムは、別のものと「独立」であること。 •

    ある認証要素が別の認証要素へのアクセス許可をあたえない。 • ある認証要素の危殆化が、別の認証要素の一貫性・機密性に影 響しない。 • 「独立でない」例 • ID/PW認証後に発行された認証コードの受け取りメール アカウントに、同じID/PWを用いている場合。 →結局ユーザ依存な側面が残っている。 https://blog.pcisecuritystandards.org/faq-is-two-step- authentication-acceptable-for-pci-dss-requirement-8.3
  52. PCI DSSではパスワードの定期変更が残る • 「パスワード定期変更」については最新v3.2.1でも要件が残ったまま • システム運用に関わる「非コンシューマ」に対しては効果ありという立場 • 「人間のいい加減さ」を軽減して、期待した効果が得られる可能性はある • 2020年に次期改定があるため、そのタイミングでの取り込み方に注目

  53. 派生トピック:Windows10

  54. 遂にクライアント/サーバOSポリシーも変更に • Windows OSにおけるPW有効期限 のデフォルトポリシは長らく42日 だった。 • Office365ではNIST改定のタイミ ングで既に新しいパスワードベス プラに変更されていた。

    • 遂にサービスとOSでのポリシーの ギャップが埋まっていく(はず)。 https://blogs.technet.microsoft.com/secguide/2019/05/23/security-baseline- final-for-windows-10-v1903-and-windows-server-v1903/
  55. https://docs.microsoft.com/ja-jp/office365/admin/misc/password-policy- recommendations?view=o365-worldwide

  56. https://docs.microsoft.com/ja-jp/office365/admin/misc/password-policy- recommendations?view=o365-worldwide

  57. このような「過渡期」をどう進むか • ベスプラと法令・業界等の「コンプライアンス順守」は別問題 • 適合基準/認定プロセスの枠組みで、新しいベストプラクティスとの 差異があっても、それはそれ。 • 変化の方向性を把握して「次に打つべき手」を検討 • SP800-63-3の改定はシステム的な機能追加を要する要件が多い。

    • 近い将来業界が求める要件を先読みし、コスト投下ポイントを見定め。 • 特定の変更点だけをピックアップして都合よく解釈するのはやめよう。 • パラダイムシフトを起こすのはガイドラインではなく事業者 • 「効果はゼロではない」か「どんぐりの背比べ」の議論ではなく「効 果が高い施策」にシフトレフト。(例えば多要素認証の導入) • 大変なのは、大変よく分かります。 • 矛盾も不整合も把握したうえでリスクを踏まえて手を打てるのは、 「保護すべきユーザ」に直接相対しているからこそ。
  58. 「やっぱり認証とか デジタルアイデンティティって 面倒で地味なテーマだな」 とか思っているそこのあなた?

  59. デジタルアイデンティティは「今」がアツい • FIDO/WebAuthn/生体認証でパスワードレス • 「なるべく」パスワードを使わない世界へ • 金融グレードAPIを支えるOAuth2/OpenID Connect • WebAPI出したので使ってください、が当たり前の世の中へ

    • リスクベース認証からコンティニュアス認証へ • よりフィジカルな状態・行動に基づくログイン後のリスク判定へ • KYC結果の企業間でのデジタル流通(eKYC) • 金融機関などIALの高い手法で実施されたKYC結果を他社に流通 • Self-Sovereign Identity/Decentralized Identifier • 自分のアイデンティティは自分で管理(ユーザセントリック) • あらゆるサービスに通用する自分自身の永続的な識別子
  60. まとめ • デジタルアイデンティティフレームワークとして再編された NIST SP800-63-3、特に63Bの考え方を通じて共通言語を得た • 63A:登録プロセスと身元確認 • 63B:認証とライフサイクル管理(★本日フォーカス) •

    63C:フェデレーションとアサーション • 「パスワード認証」で一大転換 • パスワードからパスフレーズへ • パスワード定期変更は「事業者(CSP/Verifier)が採る対策として(禁止はしないが)非推奨」 • 秘密の質問の廃止で、アカウントリカバリは複雑さを増していく • SMS認証は要観察 • 生体認証は「今」は補助的なもの • 過渡期の矛盾や解釈の曖昧さに翻弄されず、方向性を見極めよう • 細部を見ると課題はあるが、進むべき方向性は示されている • デジタルアイデンティティはセキュリティ/UX/ビジネス全てに関係し、「今」がアツい https://www.flickr.com/photos/alexristea/5636821732/
  61. ありがとうございました ご指摘、ご感想があればお気軽にご連絡ください @kthrtty, ta.katsuhara@ndias.jp, kthrtty@gmail.com https://www.flickr.com/photos/alexristea/5636821732/

  62. (Blank) https://www.flickr.com/photos/alexristea/5636821732/