アカウント名:
パスワード:
パスワードを平文で保存しているおそろしいシステム
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日本発のオープンソースソフトウェアは42件 -- ある官僚
どうやって知った? (スコア:2, 興味深い)
Source: Perfect Passwords, Mark Burnett 2005
って書いてました。でこの本の著者はどうやって知ったんだろう?
ついでに:約9人に1人がテーブル9.1(Top500のことかな)のパスワードを使ってるらしいです。
AVG anti-virus data base out of date
Re: (スコア:2, 興味深い)
Re: (スコア:0)
Re: (スコア:1)
# 管理がアマいだけならsaltかけましょう♪
で、もう一つの可能性としては、(以下略)
Re: (スコア:0)
Re: (スコア:0)
「パスワードのハッシュとチャレンジを結合したもの」のハッシュを計算するだろ。常考。
Re: (スコア:0)
MS-CHAP とかの話ですかね?
もし「パスワードのハッシュ」を利用するなら、それがサーバに保存されている必要があります。
このとき、保存した「パスワードのハッシュ」が漏れてしまえば、認証をパスすることが可能です。
つまり、ハッシュ化して保存したところで、/etc/passwd(shadow) のような意味で、
安全性が増すわけではないため、常考というほどのメリットはありません。
Re: (スコア:1, 参考になる)
それは当然でしょう。クライアントから与えられたパスワードからハッシュを計算して、サーバが保存している「ハッシュの値」と比較しないといけませんから。
>このとき、保存した「パスワードのハッシュ」が漏れてしまえば、認証をパスすることが可能です。
これは通常考えにくいです。「パスワードのハッシュ」が漏れても、プログラム(システム)が常考レベルで改変されていないなら、「漏れた『パスワードのハッシュ』をハッシュ化」した値と保存している「ハッシュの値」と比較します
Re:どうやって知った? (スコア:0)
えっと、通常の CHAP や APOP が生パスワード(に復元可能なデータ)を保存せざるを得ないのは、プロトコル策定した人たちが、単に無知だったからだと思ってます?(^^;
毎回異なるチャレンジを食わせた後のハッシュ結果が、毎回同じ「保存しているハッシュの値」になるなんて、ありえないと思いますよ。