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