アカウント名:
パスワード:
パスワードを平文で保存しているおそろしいシステム
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私はプログラマです。1040 formに私の職業としてそう書いています -- Ken Thompson
どうやって知った？ (スコア: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)
#1486382
> パスワードを平文で保存しているおそろしいシステム
それは確かに恐ろしい。
#1486485
> challenge responseで認証するには、平文（か平文に戻せる）システムが必要なんですが。
間違い。理由は下の文。
#1486503
> 「パスワードのハッシュとチャレンジを結合したもの」のハッシュを計算するだろ。常考。
正しい
#1486559
> もし「パスワードのハッシュ」を利用するなら、それがサーバに保存されている必要があります。
> このとき、保存した「パスワードのハッシュ」が漏れてしまえば、認証をパスすることが可能です。
正しい
俺流まとめ (スコア:0)
#1486382
> パスワードを平文で保存しているおそろしいシステム
しかしパスワードを平文でネットワークに流すシステムよりマシ。
#1486485
> challenge responseで認証するには、平文（か平文に戻せる）システムが必要なんですが。
間違いではない。しかし，
#1486503
> 「パスワードのハッシュとチャレンジを結合したもの」のハッシュを計算するだろ。常考。
工夫次第ではこういうことも可能。
HMAC の場合でいうと，「パスワードと『パスワードとチャレンジを結合したもののハッシュ』
を結合したもののハッシュ』といったところだろうか。MD5 のように「前から順番に」計算する
ハッシュ関数であれば，「パスワード」のところまでのハッシュ値を保存しておき，認証の時点で
続きの計算を再開することができる。
難点は他の認証方式と共有できないこと。
APOP と CRAM-MD5 に対応した POP サーバには，やはりパスワードを平文で保存する必要が
ある。と思う。
#1486559
> このとき、保存した「パスワードのハッシュ」が漏れてしまえば、認証をパスすることが可能です。
正しい。が，ハッシュ値でそのまま認証をパスできるわけではない。そのハッシュ値に衝突する
パスワードが見つかれば可能。と #1486593 は言いたかったのだろう。
#1486593
> これは通常考えにくいです。
Charange Response の話が並行してあるため，混乱を招きやすいが，
ハッシュ値の計算がサーバ側でおこなわれるのであれば，まぁ，言いたいことは
分かる，気がする。
#1486593
> そもそも、適切に十分なハッシュ値からの認証が現実的なコストで可能であるなら、
少なくとも現在広く実装されている MD5 を用いた認証では，現実的なコストで
ハッシュに衝突するパスワードを推定することは可能と考えたほうがいいだろう。
今更タレこむほどのネタ [srad.jp]でもない。
要するに，平文であれハッシュであれ，漏れたらアウト。
全ユーザにパスワードを変更させる必要がある。
ハッシュ化していると，攻撃されるまでの時間が少し稼げるかもしれない。
あと，管理者ならばユーザのハズかしいパスワードなど見せられたくないし。
俺的には
1. パスワードデータベースは漏らすな！！
2. ネットワークに平文でパスワードを流すな！
3. あ，できるんならハッシュ化しといたら？
くらいな感じ。
他の方も挙げておられるように，別のシステムへの拡散を防げるというのもあるが，
普通は「異なるシステムで同じパスワードを使うべきではない」の方が前提となる。
メールサーバとネットバンキングで同じパスワード使うとかマジ止めてほしい。
こっちの責任にすんなよ。
ってとこだな。
Re: (スコア:0)
>> このとき、保存した「パスワードのハッシュ」が漏れてしまえば、認証をパスすることが可能です。
>
>正しい。が，ハッシュ値でそのまま認証をパスできるわけではない。そのハッシュ値に衝突する
>パスワードが見つかれば可能。と #1486593 は言いたかったのだろう。
>
>#1486593
>> これは通常考えにくいです。
>
>Charange Response の話が並行してあるため，混乱を招きやすいが，
>ハッシュ値の計算がサーバ側でおこなわれるのであれば，まぁ，言いたいことは
>分かる，気がする。
一つ前のまとめをしている方に比べて、要点
Re: (スコア:0)
前提としているんじゃないかということが言いたかったんだ。
昔，UNIX マシンに telnet でログインしていたときのような。
あ，でもそこから「時間稼ぎになる」ってまとめるのは完全に間違えていますね。
1行でまとめるなら
「ハッシュ化してても漏れたらアウト」
ってことですね。
# 何より Charange ってスペルが恥ずかしいんだが。
Re: (スコア:0)
すみません、この部分は訂正です。
やや使いづらいですが、OTPのようにハッシュを遡る方法が抜けていました…他にもありますかね？
（/etc/shadow のような方式は、生パスワードをサーバ側入力に必要とするので除外していいと思いますが）
いずれにせよ、チャレンジ/レスポンス方式の場合には、いかなるハッシュ計算方法/保存方法であっても、
保存情報が漏れれば、攻撃側で認証をパスするための計算が可能だという結論は変わりません。