アカウント名:
パスワード:
パスワードを平文で保存しているおそろしいシステム
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
開いた括弧は必ず閉じる -- あるプログラマー
どうやって知った? (スコア: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 のように「
Re:俺流まとめ (スコア:0)
>> このとき、保存した「パスワードのハッシュ」が漏れてしまえば、認証をパスすることが可能です。
>
>正しい。が,ハッシュ値でそのまま認証をパスできるわけではない。そのハッシュ値に衝突する
>パスワードが見つかれば可能。と #1486593 は言いたかったのだろう。
>
>#1486593
>> これは通常考えにくいです。
>
>Charange Response の話が並行してあるため,混乱を招きやすいが,
>ハッシュ値の計算がサーバ側でおこなわれるのであれば,まぁ,言いたいことは
>分かる,気がする。
一つ前のまとめをしている方に比べて、要点を理解できていない気がします。
クラックするのに、ハッシュの衝突を見つける必要はありません。
サーバ側は、保存した情報(ハッシュ継続に必要なコンテキスト等)とチャレンジだけを頼りに、認証のための計算をしなくてはなりません。
もし、この保存情報が攻撃側にバレてしまうと(チャレンジは当然わかるわけですから)、サーバと全く同じ情報を得てしまうことになります。
この場合、公開鍵/電子署名のような非対称な仕組みがない限り、原理的にどういうチャレンジが来たとしても、サーバ側を破るのに必要十分な計算ができることになります。
Re: (スコア:0)
前提としているんじゃないかということが言いたかったんだ。
昔,UNIX マシンに telnet でログインしていたときのような。
あ,でもそこから「時間稼ぎになる」ってまとめるのは完全に間違えていますね。
1行でまとめるなら
「ハッシュ化してても漏れたらアウト」
ってことですね。
# 何より Charange ってスペルが恥ずかしいんだが。
Re: (スコア:0)
すみません、この部分は訂正です。
やや使いづらいですが、OTPのようにハッシュを遡る方法が抜けていました…他にもありますかね?
(/etc/shadow のような方式は、生パスワードをサーバ側入力に必要とするので除外していいと思いますが)
いずれにせよ、チャレンジ/レスポンス方式の場合には、いかなるハッシュ計算方法/保存方法であっても、
保存情報が漏れれば、攻撃側で認証をパスするための計算が可能だという結論は変わりません。