アカウント名:
パスワード:
あれえ？はともかく、案外使いでがあるかも知れません。
サービス別の「ハッシュドパスワード」を使っておけば、万一それが漏洩しても、同じパスワードで提供される別のサービス(プロバイダであればウェブ、ブログ、最近ではなんたらポイントとかなんたらキャッシュとかもあるでしょうか？)までが一挙に脅威にさらされるということがなくなります。
通信プロトコルは標準技術であり、また機能的制約(携帯電話からの利用であるとか)や普及度などの問題から必ずしも思い通りのものを採用できるとは限りません。そのため、個別の認証に本物パスワードを使い回すと「プロバイダがインセキュアな通信方法を使わせていたためにパスワードが漏洩し被害にあった」という主張がされる事態が出てこないとも言い切れません。
一方、プロバイダは管理のしやすさからも、ユーザからの利便性の要求からも、パスワードを一つにしたがります。
そこで、たとえばメーラが「ハッシュドパスワード」に対応し、本物パスワードを入力するのは一回のみ、メーラが記憶し利用するのはそれから生成した「ハッシュドパスワード」だけ、というようなことが考えられます。
メーラが対応してなくても、本物パスワードから各種ハッシュドパスワードを作るページをサービス側が用意するとか(これはこれでフィッシング対策も含めて問題色々ですが)、またはそういう小さなデバイスを配ってしまう、などもありえます。そうなってくると「パスワードは一つだけ」というのは幻想に近くなってくるんですが、それが幻想であることにあまり不満は出てこないのではないか……と予想します。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
目玉の数さえ十分あれば、どんなバグも深刻ではない -- Eric Raymond
そもそもAPOPって (スコア:3, すばらしい洞察)
POP over SSL なら
平文パスワードを（SSLで暗号化して）送って
サーバでハッシュ値に変換して
サーバが持っているハッシュ値と比較
だから サーバはパスワードのハッシュ値しか持ってないわけだけど
APOP の場合は
（サーバから種をもらって）
平文パスワード＋種をクライアントでハッシュ値に変換して送って
サーバも平文パスワード＋同じ種をハッシュ値に変換して比較
という方法をとるわけだから
サーバに「復号可能な形式のパスワード」が置いてあるわけで
本質的に平文パスワード漏洩の可能性は高いよなぁ と思います
PPP の CHAP とか http の digest 認証とかもそう?
Re:そもそもAPOPって (スコア:0)
そうだ、そこをパスワードのハッシュ値(以下、ハッシュドパスワード)にすればいいんだ。
(サーバから種をもらって)
ハッシュドパスワード+種をクライアントでさらにハッシュ値に変換して送って
サーバもハッシュドパスワード+同じ種をさらにハッシュ値に変換して比較
これでハッシュドパスワード自体漏れても大丈夫…あれえ?
Re:そもそもAPOPって (スコア:0)
あれえ？はともかく、案外使いでがあるかも知れません。
サービス別の「ハッシュドパスワード」を使っておけば、万一それが漏洩しても、同じパスワードで提供される別のサービス(プロバイダであればウェブ、ブログ、最近ではなんたらポイントとかなんたらキャッシュとかもあるでしょうか？)までが一挙に脅威にさらされるということがなくなります。
通信プロトコルは標準技術であり、また機能的制約(携帯電話からの利用であるとか)や普及度などの問題から必ずしも思い通りのものを採用できるとは限りません。そのため、個別の認証に本物パスワードを使い回すと「プロバイダがインセキュアな通信方法を使わせていたためにパスワードが漏洩し被害にあった」という主張がされる事態が出てこないとも言い切れません。
一方、プロバイダは管理のしやすさからも、ユーザからの利便性の要求からも、パスワードを一つにしたがります。
そこで、たとえばメーラが「ハッシュドパスワード」に対応し、本物パスワードを入力するのは一回のみ、メーラが記憶し利用するのはそれから生成した「ハッシュドパスワード」だけ、というようなことが考えられます。
メーラが対応してなくても、本物パスワードから各種ハッシュドパスワードを作るページをサービス側が用意するとか(これはこれでフィッシング対策も含めて問題色々ですが)、またはそういう小さなデバイスを配ってしまう、などもありえます。そうなってくると「パスワードは一つだけ」というのは幻想に近くなってくるんですが、それが幻想であることにあまり不満は出てこないのではないか……と予想します。