アカウント名:
パスワード:
あれえ?はともかく、案外使いでがあるかも知れません。
サービス別の「ハッシュドパスワード」を使っておけば、万一それが漏洩しても、同じパスワードで提供される別のサービス(プロバイダであればウェブ、ブログ、最近ではなんたらポイントとかなんたらキャッシュとかもあるでしょうか?)までが一挙に脅威にさらされるということがなくなります。
通信プロトコルは標準技術であり、また機能的制約(携帯電話からの利用であるとか)や普及度などの問題から必ずしも思い通りのものを採用できるとは限りません。そのため、個別の認証に本物パスワードを使い回すと「プロバイダ
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはシンプルである。必要なのはそのシンプルさを理解する素質だけである -- Dennis Ritchie
そもそもAPOPって (スコア:3, すばらしい洞察)
POP over SSL なら
平文パスワードを(SSLで暗号化して)送って
サーバでハッシュ値に変換して
サーバが持っているハッシュ値と比較
だから サーバはパスワードのハッシュ値しか持ってないわけだけど
APOP の場合は
(サーバから種をもらって)
平文パスワード+種をクライアントでハッシュ値に変換して送って
サーバも平文パスワード+同じ種をハッシュ値に変換して比較
という方法をとるわけだから
サーバに「復号可能な形式のパスワード」が置いてあるわけで
本質的に平文パスワード漏洩の可能性は高いよなぁ と思います
PPP の CHAP とか http の digest 認証とかもそう?
Re:そもそもAPOPって (スコア:0)
そうだ、そこをパスワードのハッシュ値(以下、ハッシュドパスワード)にすればいいんだ。
(サーバから種をもらって)
ハッシュドパスワード+種をクライアントでさらにハッシュ値に変換して送って
サーバもハッシュドパスワード+同じ種をさらにハッシュ値に変換して比較
これでハッシュドパスワード自体漏れても大丈夫…あれえ?
Re:そもそもAPOPって (スコア:0)
あれえ?はともかく、案外使いでがあるかも知れません。
サービス別の「ハッシュドパスワード」を使っておけば、万一それが漏洩しても、同じパスワードで提供される別のサービス(プロバイダであればウェブ、ブログ、最近ではなんたらポイントとかなんたらキャッシュとかもあるでしょうか?)までが一挙に脅威にさらされるということがなくなります。
通信プロトコルは標準技術であり、また機能的制約(携帯電話からの利用であるとか)や普及度などの問題から必ずしも思い通りのものを採用できるとは限りません。そのため、個別の認証に本物パスワードを使い回すと「プロバイダ
Re:そもそもAPOPって (スコア:0)
>
>そうだ、そこをパスワードのハッシュ値(以下、ハッシュドパスワード)にすればいいんだ。
>
>(サーバから種をもらって)
>ハッシュドパスワード+種をクライアントでさらにハッシュ値に変換して送って
>サーバもハッシュドパスワード+同じ種をさらにハッシュ値に変換して比較
>
>これでハッシュドパスワード自体漏れても大丈夫…あれえ?
それがhttpのdigest認証なのでは?