debiruはてなメモ

はてなブログの HTML が Invalid なの、わたし、気になります

【11日目】多段階認証で脆弱になる話

メタ的まえがき

この記事は11日目であるが、この文章は12月17日(日曜)に書いている。アドベントカレンダーなのに中断してしまい申し訳ない。11日(月曜)に書きかけていたが、書き切らずに眠ってしまった。そして金曜日が過ぎた。

このアドベントカレンダーを放置してもしょうがないので、後出しになるけれども予定していた記事を公開していくことにする。

11日目(月曜)の記事です

パスワードに纏わる話をしてみようと思う。まずは認証の話をしよう。本当はこのセクションに本来のまえがきがあるはずだが文脈がおかしくなったので割愛する。ともかく、認証の話がしたいのだ。

「識別」と「認証」

パスワード認証や生体認証といった言葉があるが、認証をする際には、必ず2つの確認が行われる。1つ目の確認は「誰であるか」の確認である。そして2つ目は「本当にその人であるか」の確認である。

前者の確認を「識別(Identification)」と言い、後者の確認を「認証(Authentication)」と言う。いわゆる ID と Password の組が該当する。認証にはパスワード以外もあるが、その種類の特徴は後述する。

認証とは「本人確認」の手続きであり、識別と認証の2つの確認によって本人確認がされるということである。

認証と認可

認証(Authentication)と認可(Authorization)の違いは何だろうか。

認証は「本人であるかを確認すること」である。一方、認可は「あるモノに対して、操作の権限を与えること」である。例えば「なんとかジェネレーター」というサービスがあったとき、Twitter で OAuth でログインっぽい操作をしたときには「認可」が行われるのである。

  1. まず Twitter にログインする(ここは認証である)。
  2. 「なんとかジェネレーター」に Read 権限を与える(これが認可である)。
  3. なんとかジェネレーターは、認可された権限を使って、なんとかジェネレーター側の認証をしたことにするかもしれない(認可による認証)。

認証と認可の違いは非技術者のためのOAuth認証(?)とOpenIDの違い入門を読むとよい。「OAuth 認証」という言葉が変かどうかは、少し難しいが「OAuth 認証」を定義しよう - OAuth.jp に書かれている。

認可を受けたアプリは与えられた権限の操作を自由に行うことができる。与えた権限によっては、第三者(そのアプリ)はあなたの Twitter アカウントで投稿したり、あなたの DM を読んだりすることもできる。https://twitter.com/settings/applications に Write 権限や DM Read 権限を与えているどうでもいいアプリがないか確認してみよう。

この記事では認可の話は全く関係ないので忘れてほしい。

認証の3要素

認証(つまり本人確認)の方法には「認証の3要素」と呼ばれる分類がある。

  • 記憶(SYK: Something You Know)
    • 暗証番号、パスワードなど
    • 【弱点】漏洩、推測(総当たり試行)など
  • 所持(SYH: Something You Have)
    • カードキー、鍵、秘密鍵ファイル、所有メールアドレスへのシークレットトークンの通知、SMS暗証番号の通知など
    • 【弱点】紛失、盗難、盗聴など
  • 生体(SYA: Something You Are)
    • 指紋、目の虹彩、声紋、顔認識など
    • 【弱点】照合する側が生体情報を管理するコストやプライバシー上のリスクが大きい。物理的な認証デバイスが必要。怪我をした場合に生体要素の再設定が不可能。

何を用いて「認証」するか、ということである。生体認証は、照合の難しさ(偽陰性と偽陽性)の問題もある。

認証にはどの方法を用いてもよいが、ユーザの負担(面倒臭さ)や実用性から、Webサービスのアカウントなどでは「パスワード認証」を用いていることが一般的に多い(8割程度がパスワード認証であるという調査結果がある)。

パスワードの漏洩や不正アクセスという問題を考えてみると、そもそもパスワードがなければよいという考えもできる。認証を電話なりメールでのやりとりによって行うということである。「Web サービスにパスワードは必要ない」という翻訳記事が2017年11月に書かれてはてブコメントが付いているが、パスワード認証の方が都合がよいこともあるので一長一短である。

多要素認証という考え

二段階認証、二要素認証などと言われることがあるが、一般には多要素認証(MFA; Multi-Factor Authentication)と言う。

「認証の3要素」のうち1つの要素だけを認証に用いる場合、その認証方法の弱点を突破されると不正ログインなどの問題が生じてしまう。これを防ぐ目的で、複数の認証要素を組み合わせて弱点を補うという考えが生まれた。

「パスワードを2種類用意する」あるいは「鍵を2つ用意する」といった「1要素2段階認証」でも安全性は向上するが、弱点を補うという本質を考えれば「多段階」であることよりも「多要素」であることが重要となる。

多段階認証で脆弱になる話

一般的な言い方ではないが、ここでは「2要素1段階認証」と「2要素2段階認証」と呼んでみる。これが意味することは次の通りである。

  • 【ケース1】認証画面でパスワードとSMS暗証番号が同時に要求される。
  • 【ケース2】認証画面でパスワードを要求され、それが通った後でSMS暗証番号が要求される。

【ケース2】は「2段階認証」であって「2要素認証」ではないという話である。好ましいのは【ケース1】であるというのだ。

これは一体何の話かというと、PCI DSS が2017年2月に公開した「Information Supplement "Multi-Factor Authentication"」という文書の5ページ目 "Multi-step vs. Multi-Factor" の節に書かれていることである。

PCI DSS requires that all factors in multi-factor authentication be verified prior to the authentication mechanism granting the requested access.

Moreover, no prior knowledge of the success or failure of any factor should be provided to the individual until all factors have been presented.

If an unauthorized user can deduce the validity of any individual authentication factor, the overall authentication process becomes a collection of subsequent, single-factor authentication steps, even if a different factor is used for each step.

  • PCI DSS では、認証機構が認証を通す前に多要素認証の全ての要素を検証される必要があります。
  • また、全ての要素が提示されるまで、任意の要素の成功・失敗に関する事前知識が個人に提供されるべきではありません。
  • 認証されていないユーザが個々の認証要素の妥当性を推測できる場合、ステップ毎に異なる要素が使われていたとしても、認証プロセス全体は「一要素認証」の集合となります。

上記は拙訳だが、PCI DSS における多要素認証では「多要素1段階」であることが求められている。一般的な ID/PW 認証において片方(パスワード)が一致しない場合に「(ID は存在するが)パスワードが違います」ではなく「ID または パスワードが違います」のように攻撃者にヒントを与えないようなエラーメッセージにせよという話と近いものがある。

この意味では多段階認証は安全性を損なうことになるわけである。1項目より2項目(パスワード1個よりは2個)の方が良いことは良いが、そうではなく、2項目より2要素(記憶+記憶より記憶+所持)にすべきであり、2段階より1段階(全ての認証要素の要求は1回にまとめるべき)だということだ。

まとめ

認証の話をざっくりとしてみた。次の記事では、一般的なパスワード認証を用いているサービスにおける安全なパスワード運用方法と、ユーザに対する事業者の不適切な説明について書く。

今日のステータス

https://www.ipa.go.jp/security/vuln/report/index.html

改修中

このセクション要る?

これはウェブ届出フォーム Advent Calendar 2017 の記事です。

Next debiru's HINT 「ホームページいうな