Hatena::ブログ(Diary)

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

2010-02-24

モバイル版はてなのログインページはSSLへのリンクがない

今のモバイルはてな携帯電話iPhoneAndroidDSi)のログインページに変わってから、SSLに切り替えるリンクがなくなりました。

f:id:khashi:20100224202842j:image:h300

はてなアイデアに2月1日にidea:26265として登録したのですが、未だに検討すらされていません。

iPod touchはてなログインするときはURL欄を編集してhttpsに変えてからログインしています。が、携帯電話ではURL書き換えは非常に面倒なので、自分でSSLログインページをブックマークでもしておかないといけません。

…と思って携帯(au W53CA)でhttps://www.hatena.ne.jp/mobile/loginにアクセスしてみたところ、

このサイトは安全でない可能性があるため接続できません(発行者エラー)

という、携帯電話が出すエラーが表示されてしまいました。

怖くて携帯からはてなにID、パスワードを使ってログインできない…!

かんたんログインログインしてますが、「高木浩光@自宅の日記 - はてなのかんたんログインがオッピロゲだった件」を見るとそれも心配だし…。

いやはや、恐ろしい。

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を即時無効にすること

2007-12-21

とあるソフトウェアのユーザー登録で…

製品登録したら、登録完了メールに会員IDとパスワードが記載されていました。このパスワードは自分で入力したものではなく、登録システムから発行されたものです。

この会員IDとパスワードで「ユーザー登録」ページにログインし、パスワードを変更したら「パスワード変更通知メール」が送られてきて、変更したパスワードが記載されてました。パスワードを変更した意味無いし…。

2007-09-04

大手プロバイダのメール

大手プロバイダのメールがSSLに対応しているのか、対応していても、メールソフトの設定方法で説明されているのか、ふと気になったので調べてみました。

プロバイダのサイトで公開されているサポートページで、メールソフトはOutlook Express6の場合を参考にしました。

BIGLOBE

http://support.biglobe.ne.jp/settei/mailer/win-oe/oe6actset.html

最後の手順12では、「このサーバはセキュリティで保護された接続(SSL)が必要」のどちらもチェックされていません。

トラブルのQ&Aにある「エラー:0x800CCC7D「このサーバーはSSL接続をサポートしていません。」と表示される。(Outlook Express)」ではチェックを外すように指示されているので、SSLに対応していないのですね。

OCN

http://ocnfaq.ocn.ne.jp/EokpControl?site=default&lang=ja&tid=17451&event=FE0006

Step13では、「このサーバはセキュリティで保護された接続(SSL)が必要」のどちらもチェックされていません。

トラブルシューティングの「[Windows] Outlook Express 6.0 サーバーへの接続は失敗しました。(エラー番号:0x800CCC0E)」では「チェックの必要はありません。」と書かれているので、SSLに対応していないのですね。

@nifty

http://support.nifty.com/support/manual/mail_set/mail/win_oe6x.htm

SSLについての記述はありませんでした。

「メールに関するトラブル」の「「このサーバは SSL 接続をサポートしていません。」と表示される。(エラー:0x800CCC7)」ではチェックを外すように指示されているので、SSLに対応していないのですね。

うーん…

メールは、まだまだ盗聴の危険がいっぱい、ということでしょうか。

クライアントプロバイダのメールサーバーの間だけSSLで保護しても、メールサーバー同士の通信ではどうなっているかわからないし…。大事なメールはPGPとかで暗号化するしかないのかな。

とりあえず、ボクが使っているAsahiネットではSSLに対応しているし、設定方法でも説明されていました。プロバイダのメールは使わないけど。