アカウント名:
パスワード:
クライアント側とサーバ側の問題を混同してませんか?今回の問題はクライアント側。
プロトコル的に、素のPOP3は生のパスワードをそのまま送信するし、APOPはサーバから送られてくるチャレンジと生のパスワードを連結したもののMD5ハッシュを送信。どちらも、認証の段階ではクライアント側には平文なパスワードが必要。よくある「DESをハッシュ関数にしたパスワードのハッシュ保存」では、認証できません。ソフトウェア的に復号可能な状態でパスワードを保存しておく必要があります。
ちなみに、サーバー側でも、素のPOPならDESなハッシュ保存で問題ありませんが、APOPだ
> 本来の意味の暗号化アルゴリズムとしてのDESの 利用の意味だったとしたら
DESでもなんでも、結局は鍵をローカルに保持しておかないと復号できない。
最初のほうのコメントにあったように、rootとられてるなら鍵だって参照できるだろうし、rootとられてないならそもそも見れないんだから平文だろうと問題ないでしょ。
rootとか関係無しにパスワードファイルだけ参照できちゃうような脆弱性があればまた別でしょうけど。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
「毎々お世話になっております。仕様書を頂きたく。」「拝承」 -- ある会社の日常
おかしいな DESで暗号化が普通じゃないのか (スコア:2)
当時は、DES で暗号化して保存するのが普通でした。
少し前に、新しく入ってきた業者が、
「パスワードは、平文で保存してないとだめなんだ」
と言っていたので理由を聞いたら、
「そんなの当たり前じゃないか!読み出して、String Compare するからだ!」
と、言われてしまった。
まさか、技術的問題って、それじゃないよね。
Re: (スコア:1)
クライアント側とサーバ側の問題を混同してませんか?
今回の問題はクライアント側。
プロトコル的に、素のPOP3は生のパスワードをそのまま送信するし、
APOPはサーバから送られてくるチャレンジと生のパスワードを連結したもののMD5ハッシュを送信。
どちらも、認証の段階ではクライアント側には平文なパスワードが必要。
よくある「DESをハッシュ関数にしたパスワードのハッシュ保存」では、認証できません。
ソフトウェア的に復号可能な状態でパスワードを保存しておく必要があります。
ちなみに、サーバー側でも、素のPOPならDESなハッシュ保存で問題ありませんが、
APOPだ
Re:おかしいな DESで暗号化が普通じゃないのか (スコア:0)
> 本来の意味の暗号化アルゴリズムとしてのDESの 利用の意味だったとしたら
DESでもなんでも、結局は鍵をローカルに保持しておかないと復号できない。
最初のほうのコメントにあったように、
rootとられてるなら鍵だって参照できるだろうし、
rootとられてないならそもそも見れないんだから平文だろうと問題ないでしょ。
rootとか関係無しにパスワードファイルだけ参照できちゃうような脆弱性があればまた別でしょうけど。