Scrapcode@はてなダイアリー

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

Security

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

(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)だけは勘弁して欲しいところです（これだけは危険度が別格かと）。

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

Permalink | コメント(5) | トラックバック(0) | 11:15