セカイノカタチ

世界のカタチを探求するブログ。関数型言語に興味があり、HaskellやScalaを勉強中。最近はカメラの話題も多め

秘密の質問が死滅してほしい理由

よく、銀行などでパスワードリセットのために「秘密の質問」を登録するサイトがありますが、はっきり言ってそれによってセキュリティが高まる根拠が無い上に余計な手間が増えるので死滅して欲しい。

秘密の質問によって危険性が増す

秘密の質問によってセキュリティが高まる根拠が無いどころか、危険性が増すという本末転倒な事態を引き起こしている。

www.yomiuri.co.jp

秘密の質問は、「一般的な内容」で「自分のパーソナルに関わる事項」で「一生においてあまり変動しないもの」という制約が発生するため、攻撃者にとって推測しやすいという致命的な欠陥を持っている。

これを回避するためには、質問と関係ない出鱈目な推測されにくい言葉を入れる必要があり、これは、第2のID/パスワードと何ら変わりがない。

つまり、パスワードという仕組みを改悪して再発明したものが「秘密の質問」というわけだ。

秘密の質問は忘れる

秘密の質問は、ID/パスワードよりも重要度が低く見られがちで、私用頻度も低いので忘れやすい。

それにもかかわらず、忘れることによって重篤な事態を引き起こすリスクがある。

www.zakzak.co.jp

zakzakソースなのがちょっとアレだが。

自分は、秘密の質問を忘れて問い合わせメールを往復させたことが何度かある。

テキストフィールドに入力する

秘密の質問の答えは、パスワードフィールドではなく、通常のテキストフィールドに入力することが多い。

そのため、オートコレクトに記憶される危険性がある。

また、全角半角混在での入力が可能なため、「あれ?全角で入れたっけ?半角だっけ?漢字だっけ平仮名だっけ?送り仮名はどうだったっけ?」という答えを覚えていたとしても、入力値のブレが大きい。特に日本語では。

これを複数のサイトで忘れずに運用する事は不可能だろう。

結局「メモ」することになる。

パスワード運用の基本原則に反する。

秘密の質問の必要性

秘密の質問は、どんな時に活用されるのだろうか?

パスワードをわすれた時の本人確認に使用されることが多いだろう。

  1. パスワードを忘れた方はこちらへ
  2. 本人確認の質問の答え要求
  3. 確認メールの送信
  4. 確認メールのリンクをクリック
  5. 一時的なセッション割当&パスワードの変更

4の後に2だったり、5のタイミングで、ログイン済み扱いになったり、その場で一時的なセッションが割り当てられるだけだったりという派生はあるが、概ねこの手順になると思う。

このシーケンスであれば、「確認メールの送信」を行っているので、本人確認の質問によってそれ以上にセキュリティが高まることはない。

レアケースを考えるのであれば、攻撃者が被害者の平文メールを全て読むことが出来る状況で、秘密の質問がない場合、確認メールを傍受して、本人よりも先にパスワードを変える、もしくはセッションを乗っ取ることが出来る。が、その場合、攻撃者は平文メールの傍受が出来る状態なので、本人確認の質問の有無に依らずとも被害者を攻撃できる可能性が高い。

そして、上記にあげた運用上のリスクが有るため、このケースをケアするために別の脆弱性を発生させているという問題がある。

現実世界の鍵と違い、パスワードを増やせばそれだけ脆弱性は下がると見ていい。

住居で例えるならば、鍵を増やすとともに扉を増やしてしまっているようなものだ。管理が煩雑になり、一番弱い扉を突破すれば良いのでセキュリティは下がる。

秘密の質問は誰が得するのか?

ソフトウェア上のセキュリティ全般に言えることだが、その仕組の効果がデメリットを上回っているか、検討する必要がある。

この場合、先に述べたデメリットがあり、秘密の質問の管理が運用上の脆弱性となる。

では、なぜこの様な仕組みが世の中にのさばっているのか?

特をするのは、システムの提供者であり管理者なのだ。

パスワードの管理責任は、システムの提供者側にはない。利用者側が負うべきリスクだ。

そのため、システム提供者側には、闇雲にパスワードを増やすメリットが発生してしまっている。

パスワードの定期変更ルールや複雑なパスワード設定ルールなども、この理屈が当てはまる。

利用者が、パスワードをどこにメモしようが、忘れようが、盗まれようが、全く責任が発生しない。

そして、システム側からみたセキュリティは強化されたと胸を張って上司に報告できる。

そんなエゴのために多大な迷惑を被る利用者はたまったもんじゃない。

今すぐ廃止して欲しい。