この文書は2016年以降更新されていません
セキュリティの質問の選択と使用に関するチートシート
|
最終改訂日 (yy/mm/dd):2015/07/18 はじめにこのチートシートでは、"パスワードを忘れた場合" に使用する Web アプリケーション機能を実装するために、セキュリティの質問を選択および使用するときに、開発者が手本にできるベストプラクティスを提供します。 問題点パスワードを忘れた場合の機能を使用または実装するときに、ユーザーや開発者にガイダンスを提供するための業界標準はありません。その結果、開発者は通常、不適切な質問のセットを採用して、無防備に実装しています。開発者のこのような行為は、ユーザーに対するリスクだけでなく、潜在的な責任問題が原因で、開発者組織に対してもリスクをもたらすことになります。パスワードなど無用になるか、少なくとも、さまざまな多要素認証メカニズムの中の 1 つとして、あまり重要なものではなくなれば理想的なのですが、現実には、今でも Cobol に頼っているように、おそらくこれからもパスワードに頼らざるを得ないでしょう。そこで、パスワードを忘れた場合のソリューションをできるだけ無難なものにするためにできることは何でしょうか。 セキュリティの質問と ID データの選択ほとんどの人は、不適切な "セキュリティの質問" を見たら、すぐにおかしいと気づきます。大体の見当は付くはずです。「好きな色は何色ですか?」のようなものは、明らかに不適切な質問です。しかし、Good Security Questions Web サイトが的確に指摘しているように、"適切なセキュリティの質問は、実のところ存在しません。まずまずの質問か、不適切な質問しかありません"。 ほとんどの組織では、忘れてしまったパスワードをユーザーが自分でリセットできるようにしていますが、これはセキュリティのためではなく、ユーザーがヘルプデスクに掛ける電話の回数を減らして自分たちの負担を軽くするためです。これは利便性とセキュリティの典型的なトレードオフであり、この場合、まず間違いなく利便性 (組織にとってはコストの低減、ユーザーにとってはセルフサービスのシンプル化) のほうに軍配が上がります。 コスト削減というビジネス面が通常は優勢になるという状況で、少しでもセキュリティを強化するために何をすべきかが課題です。 ここで、いくつか提案をします。ただし、具体的なセキュリティの質問を推奨することは、敢えて行いません。そうすると逆効果になる可能性があるからです。多くの開発者がその質問を深く考えずに使用したら、攻撃者は即座に各種のソーシャルネットワークから当該データの収集を開始するでしょう。 理想的な特徴忘れたパスワードをリセットするためにユーザーに提示されるセキュリティの質問や ID 情報は、次に示す 4 つの特徴を備えていることが理想的です。
手順手順 1) ID データ、定型の質問、ユーザーが作成した質問を決定する通常、後のパスワードリセットに使用する情報はすべて、1 つの HTML フォームを使用して収集する必要があります。 組織とユーザーの間に取引関係がある場合は、ユーザーが Web サイトに登録した際に、おそらく何らかの追加情報をユーザーから収集したはずです。たとえば、次のような情報があります。
セキュリティ強化のために、まずユーザーに電子メールアドレスを尋ねて電子メールを送信し、そのメールに記載した専用ページにアクセスしてもらって他の識別要素を 2 つ (またはそれ以上) 入力させる、という方法があります。この方法では、ユーザーはランディングページに到着した後にも、いくつもの "秘密の" 質問に回答する必要があるので、電子メール自体はあまり有用にはなりません。 一方、たとえばソーシャルネットワーキングサイトや無料の電子メールサイト、ニュースサイト、写真共有サイトなど、一般の人を対象にした Web サイトをホストしている組織では、この ID 情報を持っていない可能性が高く、ありふれた "セキュリティの質問" を使用する必要があります。しかし、別の電子メールアドレスやショートメッセージサービスの電話番号など、帯域外のサイドチャネルにパスワードのリセットの情報を送信するための、何らかの手段を収集する必要もあります。 意外かもしれませんが、ユーザーがいくつかの "定型の" 質問セットから選択できるようにすることには、若干のメリットもあります。ユーザーは通常、当初のユーザープロファイル作成作業の一環として、セキュリティの質問への記入を求められますが、ほとんどのユーザーは急いでいます。ユーザーはサイトに登録して、中を見て回りたいだけです。もしユーザーにそのとき、独自の質問を作るよう要求したら、おそらくはしぶしぶするので、非常に質の悪い質問を作ってしまう可能性が高くなります。 しかし、ユーザー自身で質問を 1 つまたは複数作成するよう要求することには、それなりの根拠もあるのです。一般的な法的見解では、独自の質問の作成にあたって、ユーザーにある種の適切なガイダンスを提供したうえで質問作成を要請した場合には、潜在的責任の少なくとも一部が組織からユーザーへ移動するようなのです。その場合に、ユーザーの脆弱なセキュリティの質問 (たとえば、「一番好きなアイスクリームは何味ですか?」など) が原因でユーザーアカウントがハッキングされても、ユーザーの自己責任となって、組織が訴えられる可能性も低くなるというのが大勢の見方となっています。 OWASP は「パスワードを忘れた場合に関するチートシート」で、複数のセキュリティの質問をユーザーに提示し、正しい回答を得てからパスワードの再設定を許可するように推奨しています。たとえば、定型の質問セットから 1 つか 2 つの質問をユーザーが選択し、ユーザー自身の (別の) 質問も作成することを義務付けたうえで、ユーザーが選択した定型の質問 1 つと、ユーザー自身の質問に回答するよう要求するなどの方法がお勧めです。 手順 2) 定型の質問を法務部またはプライバシー責任者と確認するほとんどの開発者は通常、まず最初に関連事業部門と質問内容を検討することはしても、法務部や個人情報保護管理責任者と質問を検討しようとは思わないかもしれません。しかし、これは是非とも行う必要があります。質問が厳守する必要のある準拠法や規制 / コンプライアンスの問題が存在する可能性があるからです。たとえば、電気通信業界では、FCC の Customer Proprietary Network Information (CPNI) 規定で "個人情報" が含まれたセキュリティの質問を顧客に尋ねることを禁止しています。そのため、「あなたの出生地はどこですか?」といった質問は、通常は許可されません。 手順 3) 回答の最小長を義務付けるたとえ適切なセキュリティの質問を提示しても、ユーザーは通常、長ったらしい文で質問に答えるのが面倒なので、短い回答を好む傾向があります。短いののしり言葉や、"xxx" や "1234" のような回答も、珍しくありません。フレーズか文で答える必要があるとか、受け入れ可能な回答には最小長 (10 文字や 12 文字など) があることをユーザーに伝えるとたいてい、比較的推測しにくい回答を作成するようになります。 手順 4) 質問と回答を安全に保存する方法を考える問題の保存と回答の保存には、2 つの面があります。質問は当然ユーザーに提示する必要があるので、プレーンテキストとして保存するか、元に戻せる暗号化テキストとして保存します。回答は基本的に人に見せる必要はないので、セキュリティ保護された暗号ハッシュを使用して保存することができます (もっとも、一部のヘルプデスクがパスワードのリセットに質問と回答の両方を使用し、回答は入力するのではなく、読むことができるようにしてほしいと主張しているのもわかっています。立場により意見はそれぞれなのです)。いずれにせよ、回答はプレーンテキストで保存せず、少なくとも暗号化しておくことをお勧めします。これは、特に "独自の質問を作成する" タイプに対する回答で、潜在的にデリケートな回答が返される質問 (「私と妻が共有している私の預金口座番号は?」など) をユーザーが提示する場合に当てはまります。 何よりの問題は、質問をプレーンテキストにするか、元に戻せる暗号化テキストで保存する必要があるかです。我々の意見としては、少なくとも "独自の質問を作成する" タイプには、そういった質問を暗号化することをお勧めします。というのも、質問が暗号化されていれば、暇を持てあました悪意のある DBA が、セキュリティの質問と回答が保存されている DB を退屈しのぎに物色して、機密あるいは知られると恥ずかしい情報を偶然見つけたときに、会社が訴えられる可能性がかなり減るからです。 さらに、質問を暗号化していて回答をハッシュ化していることを説明すれば、顧客も少しでもセキュリティが向上するなら安心して多少恥ずかしい質問でもできるというものです。(想像力を働かせれば、どのような質問のことを指しているかはわかるはずです。) 手順 5) ユーザーに自分の質問の定期的な見直しを促す多くの企業では通常、電子メールアドレスや所在地住所などの連絡先情報が最新であるかどうかを確認するために、ユーザーに対して頻繁にユーザープロファイルの更新を求めます。この機会を利用して、ユーザーに自分のセキュリティの質問を見直してもらいましょう。(このとき、ユーザーに少し時間的余裕があれば、この機会を利用して、より良い質問を選択できるかもしれません。)ユーザーの回答をハッシュするのではなく暗号化している場合は、このときに、対応するセキュリティの回答を表示することもできます。 パスワードを忘れた場合のフローの一環としてそれぞれの質問が何者かに提示された回数の統計を取っている場合 (推奨) は、その情報も表示するとよいでしょう。(たとえば、アドバイスに反して、「あなたの一番の趣味は何ですか?」のような質問を作成したユーザーは、パスワードをリセットしたのは 5 回だけなのにこの質問が 113 回も提示されているのを知ったら、どうやらセキュリティの質問もパスワードも変更したほうがよいと自覚するでしょう。) 手順 6) 質問の変更リクエストの認証多くの Web サイトでは、現在のパスワードと一緒に希望する新しいパスワードを入力させることにより、適切にパスワード変更のリクエストを認証します。ユーザーが現行の正しいパスワードを指定できない場合、パスワードの変更リクエストは無視されます。セキュリティの質問を変更する際も、同様の認証制御を実施する必要があります。正しいパスワードを提示したうえで、新しいセキュリティの質問と回答を提供することをユーザーに義務付けます。ユーザーが正しいパスワードを指定できない場合、セキュリティの質問の変更リクエストは無視する必要があります。この制御により、クロスサイトリクエストフォージェリ攻撃だけでなく、ユーザーのワークステーションまたは認証済みアプリケーションセッションを乗っ取った攻撃者による変更も防止します。 セキュリティの質問の使用セキュリティの質問の回答をユーザーに要求するケースとして最もよくあるのは、次のまったく異なる 2 つのシナリオです。
どちらのシナリオについても、セキュリティの質問に対する回答をユーザーに求めるときには、常に異なる 2 セットの質問 / 回答を使用するよう強くお勧めします。 パスワードの使用に加えてセキュリティの質問 / 回答を使用しても、多要素認証にはならないことに注意する必要があります。それらは、どちらも「自分の知っていること」のカテゴリに分類されます。それらは同じ要素になるため、多要素にはなりません。もう 1 つ注意が必要なことは、パスワードがそもそも非常に弱い認証形式なのですが、セキュリティの質問に回答することは通常、さらに弱い認証形式であるという点です。その理由は、通常、ユーザーがパスワードを作成する際には、候補のパスワードをパスワードの複雑さの規則 (最小長 > 10 文字、少なくとも 1 つの英文字、1 つの数字および 1 つの特殊文字など) と照らし合わせてテストしますが、(最小長の要件を求めることを除けば) このような配慮をセキュリティの回答に対して行うことがほとんどないからです 。そのため、一般に、適切なパスワードのエントロピーは、セキュリティの質問に答えることよりも桁違いに高くなります。 忘れたパスワードのリセットに使用するセキュリティの質問「パスワードを忘れた場合に関するチートシート」では、セキュリティの質問に対する回答を収集する際に、開発者として知っておくべきことのほとんどすべてについて詳しく説明しています。ただし、セキュリティの質問を選択するとき (質問の候補リストから選択する場合)、または独自のセキュリティの質問 / 回答を記述するときに、ユーザーを支援する方法についてのガイダンスは提供していません。「パスワードを忘れた場合に関するチートシート」では、セキュリティの質問 / 回答として追加の ID を実際に使用できるものと想定しています。ただし、そのようなことは、ほとんどありません。ユーザーが進んで ID を提供することは (今後も) まずありませんし、また、特定の法規への準拠のために禁止されていることもあります (たとえば、電気通信会社と [CPNI] データの場合など)。 そのため、少なくとも一部の開発チームが、より一般的なセキュリティの質問と回答をユーザーから収集することになります。開発者として、これを実行する必要がある場合の正しいプラクティスを次に示します。
後者については、ユーザーに [Good Security Questions] Web サイトを参照するように勧めてください。 さらに、攻撃者は「忘れたパスワード」のリセットフローを使用してユーザーのパスワードをリセットしようとするため (特に、攻撃者が SMS テキストメッセージを受信する電子メールアカウントやモバイルデバイスなどのサイドチャネルを侵害している場合)、セキュリティの質問の意図しない無許可の情報公開を最小限に抑えることが正しいプラクティスになります。たとえば、ユーザーが 1 つのセキュリティの質問に答えない限り、それ以降の質問を表示しないようにするなどの方法もあります。このようにすると、攻撃者がすべての質問を一度に調べられるチャンスがなくなります。ただし、これは「パスワードを忘れた場合に関するチートシート」のアドバイスに反することであり、スポンサーの事業部門が使い勝手が悪いと判断することもあります (ここでも、立場により意見はそれぞれなのです)。 最後に、ユーザーが入力するセキュリティの質問を "パスワード" タイプとして扱うか、単に通常の "テキスト" 入力として扱うかを検討する必要があります。前者はショルダーサーフィン攻撃を阻止できますが、入力ミスの発生が増えるというトレードオフがあります。おそらく、最良のアドバイスは、ユーザーに選択を任せることです。既定では、"パスワード" 入力タイプとして扱うことでテキストを非表示にしますが、チェックボックスをチェックすればセキュリティの回答がクリアテキストとして表示されるようにします。 追加の認証手段としてのセキュリティの質問まず、繰り返しますが、パスワードが弱い認証とすれば、セキュリティの質問の使用はさらに弱いものです。また、本物の多要素認証や、強力な認証スタイル (ワンタイムパスワードの使用、サイドチャネル通信を必要とするものなど) の代わりにはなりません。一言で言えば、セキュリティの質問を使用しても、得られるものはほとんどないのです。しかし、そうする必要がある場合は、次のことを念頭に置いてください。
関連資料パスワードを忘れた場合に関するチートシート Authors and Primary EditorsKevin Wall - kevin.w.wall[at]gmail com Other CheatsheetsDeveloper Cheat Sheets (Builder)
Assessment Cheat Sheets (Breaker)
Mobile Cheat Sheets OpSec Cheat Sheets (Defender) Draft Cheat Sheets
|
