Hatena::ブログ(Diary)

Scrapcode@はてなダイアリー このページをアンテナに追加 RSSフィード

2010-02-06

パスワードリマインダーの実装を考える

サイト運営者の視点で、パスワードリマインダーの実装について考えてみます。

(1) 登録メールアドレスに生パスワードを送信する

アチコチでよく見かけますが、パスワードの扱いが軽すぎます。

メールを盗聴されるとパスワードが漏れます。パスワードの使い回しが少なくないと思われる現在、該当サイトだけでなく他のサイトもアカウントを乗っ取られる危険性があります。

また、該当サイトではデータベースに生パスワード、もしくは復号可能なパスワードを保存している事になります。万が一該当サイトのサーバークラックされた場合、データベースのデータと復号方法まで一緒に漏れる可能性があります。

(2) 登録メールアドレスにランダムな仮パスワードを送信する

メールを盗聴されるとその仮パスワードを使ってログインされ、アカウントが乗っ取られます。パスワードを変更されてしまうとどうしようもなくなります。

盗聴者より先にログインしてパスワードを変更してしまえば、被害を回避できます。

パスワードが漏れても、アカウントを乗っ取られるのは該当サイトだけで済む分、(1)よりマシです。

(3) (2)に加え、登録情報との照合を行う

生年月日や秘密の質問など、ユーザー登録情報との照合を行うことにより、第三者による勝手な仮パスワード申請を避ける事ができます。

しかし、メールを盗聴されると危険なのは(2)と変わりません。

パスワード申請時ではなく、仮パスワードでのログイン時に照合を行うのであれば、安全性は高まります。

(4) 登録メールアドレスパスワード再設定用のURLを送信する

メールを盗聴されると危険なのは(1)と同じですが、盗聴者より先にパスワードを再設定してしまえば*1、被害を回避できます。

盗聴者が勝手にパスワード再設定用のURLを申請してしまうことができると、本人より先にパスワードを再設定されてしまう危険があります。

パスワードが見えてしまう事が無いので、もしメールを盗聴されて先にパスワード再設定を行われたとしても、アカウントを乗っ取られるのは該当サイトだけで済む分、(1)よりマシです。

(5) (4)に加え、登録情報との照合を行う

生年月日や秘密の質問など、ユーザー登録情報との照合を行うことにより、もしパスワード再設定用URLが漏れてもアカウントを乗っ取られる可能性がかなり低くなります。

ただし、パスワード再設定用URLをメール送信する前にこの照合を行った場合の危険性は(4)と同じになってしまいます。照合を行う場合は、パスワード再設定の段階で行うべきです。

(6) 登録メールアドレスパスワード再設定用URLを送信し、リマインダーフォームに確認コードを表示する。

  1. リマインダーのフォームで登録情報との照合を行う。
  2. 登録メールアドレスパスワード再設定用のランダムなURLを送信する。
  3. リマインダーの「メールを送信しました」表示と共に、ランダムな確認コードを表示する。
  4. ユーザーはパスワード再設定用URLにアクセスし、確認コードを入力し、パスワード再設定を行う。
  5. 使用済みURLと確認コードは破棄する。

メールを盗聴されても、パスワード再設定用URLだけではパスワードを変更できません。また、確認コードの表示がSSLで保護されていれば、確認コードを傍受されることもありません。

(7) 登録メールアドレスに確認コードを送信する

  1. リマインダーのフォームで登録情報との照合を行う。
  2. 登録メールアドレスにランダムな確認コードを送信する。
  3. セッションデータとしてサーバー側で確認コードを保持し、ユーザーからの確認コード入力を待つ。
  4. ユーザーがメールの確認コードを入力。
  5. パスワード再設定を行う。
  6. 使用済み確認コードは破棄する。

メールを盗聴されても確認コードのみなので、盗聴者がログインパスワード変更を行う事はできません。

セッションハイジャックとメールの盗聴が同時に発生しなければ、アカウントを乗っ取られる事は無いと思います。

この記事を書いたキッカケ

(6)と(7)はどこかで使われているかな?

(1)〜(5)に比べてメール盗聴に強く、実装も難しくないと思いますが、何か見落としている問題点があればコメントいただけるとうれしいです。

この記事を書いたキッカケは、去年見たユーザー登録型のサイトで(1)の事例が多くてウンザリしたからです。パスワードみたいな秘匿性の高い情報を平文でネットワークを流れるメールに書いてはいけないというのは、電子メールを使い始める最初に注意されることだと思うのですが…最近はそうでもないのでしょうか?

最近はPOP over SSL / SMTP over SSLに対応したプロバイダも増えてきてはいますが、これらが保護できるのはメールクライアントと各サーバーとの間だけです。サーバー - サーバー間をSSLで保護されるかどうかは保証されません。また、受信者側がPOP over SSLに対応していないかも知れないし、対応していてもメールクライアントSSLを使う設定にしていないかも知れません。

メール盗聴が実際にどれぐらい発生するかはわかりませんが、サイト運営側は盗聴されてもユーザーに被害が及ばない仕組みを用意するべきです。

(2010-02-09 追記) 「登録情報との照合」について

文中で「生年月日や秘密の質問など」と書きましたが、生年月日はWebで公開しているプロフィールに書いている人も多いため、照合に使うには危険です。

秘密の質問はサイト側が用意している質問選択肢が全然秘密になっていないことが多く、質問内容を自由に決められない場合には、やはり危険です。「ペットの名前」や「出生地」などは、ブログなどで公開していることも多いでしょう。

Webサービスによっては登録情報がメールアドレス、ユーザーID、パスワードぐらいしか無い場合もあるので、第三者にでも簡単に照合できてしまうかもしれません。

第三者でも照合できるような場合は勝手にリマインダーを使ってしまえるため、どの方法でもメール盗聴と照合突破を同一の攻撃者にやられると無力です。

第三者による照合一致の確率を極力抑える事ができた場合は、メール盗聴されただけではパスワードを変更できない方法が安全です。

危険度が変わらないならどの方法でもいいかも知れませんが…、それでも(1)だけは勘弁して欲しいところです(これだけは危険度が別格かと)。

高機能で使いやすいけどパスワードの扱いが杜撰なサービスよりは、多少使いにくくてもパスワードの扱いがしっかりしているサービスを使いたいものです。

*1:ただし、再設定が完了したURLを即時無効にすること

falsehfalseh 2010/02/06 23:46 攻撃者がリマインダフォームに直接アクセスしたときのことを考えると、メールが盗聴された場合にまずいと言う意味で(3)〜(5)に比べて(6),(7)が特別強いわけではないと思うのですがどうでしょうか。
私もメール盗聴がどのくらい発生するかわかりませんが、リマインダの場合はログインしていない状態からスタートするので、セッションハイジャックとか以前の問題かと思いました。

khashikhashi 2010/02/07 11:12 id:falsehさん、コメントありがとうございます。

> 攻撃者がリマインダフォームに直接アクセスしたときのことを考えると、

「登録情報との照合」である程度は回避できると思うのですが、問題はその照合内容ですね。ユーザーID、メールアドレス、生年月日などでも、プロフィールページやブログなどでユーザーが公開していたら照合の意味が無くなってしまいます。
「秘密の質問と答え」でも、例えばサイト側が用意した質問選択肢の中から「ペットの名前」を選び、答えに本当の名前を書いた場合、そのユーザーがブログでペットの名前を出していれば意味がありませんね。
どういう情報を照合させるかが、実際の実装時に重要な検討項目だと思います。これがとても難しいでしょうけど。。。

攻撃者が照合を突破して、かつメールを盗聴できてしまった場合は、メールを利用するリマインダーは全て同じ危険にさらされるでしょう。

サイト運営側が照合内容を工夫して、攻撃者による照合一致の確率をなんとか低く抑えることができたとして、その上でメール盗聴された場合を考えてみます。照合を行わない(1)(2)(4)は除外します。

(3)でメール送信前のみに照合を行う場合、盗聴した仮パスワードでログインできてしまうかも知れません。メール盗聴のみで被害が発生しえます。

(5)でメール送信前のみに照合を行う場合、盗聴したパスワード再設定URLでパスワードを再設定できてしまうかも知れません。メール盗聴のみで被害が発生しえます。

(3)と(5)で、仮パスワードでログインしたとき、またはパスワード再設定のときに照合が行われるのであれば、メールを盗聴しただけでは乗っ取られることはないと思います。

(6)は照合がメール送信前でも後でも、メール盗聴で盗まれたパスワード再設定URLだけではパスワードを変更できません。確認コード表示がSSLで保護されていれば、同じPCのモニタを見ている人以外には確認コードを盗まれることは無いと思います。

(7)は照合がメール送信前でも後でも、メール盗聴で盗まれた確認コードだけではパスワードを変更できません。ここで、id:falsehさんの

> リマインダの場合はログインしていない状態からスタートするので、セッションハイジャックとか以前の問題かと思いました。

の懸念が出てくるわけですが、ログインの有無に関わらずセッションは開始できませんか?

falsehfalseh 2010/02/07 13:28 ログインの有無にかかわらずセッションが開始できるので、攻撃者がリマインダフォームにアクセスして(本人とは全然関係ないところでセッションを開始して)、メール盗聴で確認コードが盗めればパスワードの変更が可能だと思います。
つまり、セッションハイジャックとメール盗聴の組み合わせではなく、メール盗聴と「登録情報の照合」だけで突破できます。
と、言う意味で、(3)/(5)/(7)は同等だと思ったのですが。

outout 2010/02/08 00:27 どの方法もメールが盗聴されたらアウトですね。

khashikhashi 2010/02/09 01:57 id:falsehさん

攻撃者による「登録情報の照合」が可能な場合に無力だということには全く異論ありません。
本文に「「登録情報との照合」について」を追記いたしました。

> outさん

outさんもfalsehさんと同じような理由から「どの方法もメールが盗聴されたらアウト」と書かれたのでしょうか?

スパム対策のためのダミーです。もし見えても何も入力しないでください
ゲスト


画像認証

トラックバック - http://d.hatena.ne.jp/khashi/20100206/1265422541