「秘密の質問」の危険性

最近、パスワードについて「使いまわしをしない」とか「できるだけ複雑なものにする」とか言われるようになった。
しかし一部のシステムでは「秘密の質問」が安全性を下げているように感じる。
開発者はそのような設計をしないようにするべきだし、ユーザは利用時に気をつけなければいけないと思う。
「秘密の質問」の危険性について考えた結果についてまとめておく。

「秘密の質問」とは

ユーザがパスワードを登録する際、システムは併せて「秘密の質問」を要求する。
パスワードを忘れてしまったユーザは、ユーザID、秘密の質問(数パターンから選択)、秘密の質問の答え、の3つを正しく入力するとパスワードが再設定できる。

問題点

以下のような危険性がある。

  1. 「秘密の質問」が実質的にパスワードよりも強い権限を持つこと
    • 「秘密の質問」を知っていさえすればいくらパスワードを強固にしても再設定できる。
  2. 答えを予測されやすいこと
    • 質問によって答えの内容が絞られるため、ブルートフォースアタックも可能。
      • 例えば、「好きな食べ物は?」という質問なら適当に食べ物を入れていけばよい。
    • 本人のことをよく知っている人ならば、「好きな食べ物」や「ペットの名前」などは知っていることも多い。
    • SNSなどを使ってソーシャルエンジニアリングされやすい
  3. 使いまわしされやすいこと
    • 同じ「秘密の質問」に対しては同じ内容が使い回されやすく、パスワードと同様の危険性がある。
  4. システム自体が「秘密の質問」を考慮した設計になっていない場合があること
    • 登録時の入力フォームや確認メールなどで、パスワードは伏られた表示(*****など)になるのに対し、秘密の質問はそのまま表示される
    • データがサーバ上に平文で保存されている 1
    • パスワードは何度か間違えるとロックされるが、秘密の質問ではそのような機能がない

ユーザ側の対策例

ユーザ側の対策例として、以下のものが考えられる。

  • 質問の答えを使いまわさないこと。
  • 質問の答えには、絶対に誰にも知られることのない内容を登録する。
  • 自分で登録ルールを作る
    • 秘密の質問をずらして登録する。
      例えば、「好きな食べ物」に「ペットの名前」を登録する
    • あるいは、秘密の質問とは関係のない答えを入れて、秘密の質問を無効化する 2
    • その他、自分の中で「パスワードをハッシュ化したものを登録する」などのルールを作っておけば、使いまわしも回避できる。 3

ここまで書いてはみたものの、ユーザ側での現実的な対策は難しいというのが正直な印象。
開発者もユーザも、「秘密の質問」の危険性を認識する必要があると思う。


  1. アカウント設定変更のページなどで「秘密の質問の答え」がそのまま表示されているような場合は、該当する。 [return]
  2. 秘密の質問が意味を成さなくなるので、パスワードを忘れないように注意 [return]
  3. こちらも、秘密の質問が意味を成さなくなるので注意 [return]

関連記事


  1. Spring Security + ThymeleafでAjaxリクエストにCSRF対策トークンを適用
  2. 一部のパスだけSpring SecurityのCSRF対策を無効化する
  3. Let's EncryptでDebian+ApacheをSSL/TLS化
  4. SRIによってCDN上のスクリプト改ざんを検知する
  5. OpenSSL+パスワードでファイルの暗号化/復号処理
  6. TrueCryptのレビューレポートを読んでみた
  7. Google ChromeのSSL/TLS暗号化アルゴリズム設定

comments powered by Disqus