アカウント名:
パスワード:
>プロトコルを合わせれば認証を通せるわけでしょ。
通せませんよw
正確にはハッシュから元のパスワードを推測するのは困難です。
たとえハッシュ値とハッシュ関数が明らかでも、そのハッシュ値にするための平文を見つけるのが大変なようにハッシュ関数は設計されているはずだからです。
セキュリティには、あまり詳しくないですが、>正確にはハッシュから元のパスワードを推測するのは困難です。それは困難ですが、ハッシュ値とハッシュ関数が明らなら、パスワードが正しいかどうかは判定できるはずなのでそれらが手にはいるとパスワードの判定を多少速くできるようになると思います。
それはパスワード辞書や総あたりで見つける為の時間が多少短くなっただけでもともとパスワードという方法をとっている限りあなたの希望する安全ではないと思います。
のように行われます。 このような手順を踏めば、
ので安全です。
現実には元のパスワードが123456とかabcdefな場合がよくあるので、ハッシュが1件でなく全部流出した場合、へぼパスワードのアカウントは全部抜かれるんですけどね。
それは、にわか知識で作られたへぼ実装の場合だけです。 ちゃんとした実装では、saltもその都度変更するので、同じパスワードでも異なるハッシュ値となります。 この辺 [unixuser.org]とか参照で。
# と偉そうに言いつつ、自分も先週知ったばかりなのでAC(汗
あなたの示された参照先にも書いてあると思いますが、salt をランダムにしても,その値をどこかに保存しておかないといけません。もしそれがハッシュ値と同じファイルの同じ行とかに保存されていたら、「ハッシュ値だけが流出」ということはまずないと思います。
ランダムな salt を付加することで、へぼパスワードが少し(場合によってはかなり)マシなものになりますが、それは salt が知られていないことが前提にあります。
失礼しました。「へぼパスワードが問題になるのはへぼ実装だけ」というのはちょっと過激な見出しでした。 元の全部抜かれる [srad.jp]というコメントの問題については大幅に解決しますが、全く問題が無くなるわけではなく、総当たりでいずれ突破されうるというのは皆様のおっしゃる通りです。
# たぶんいろんな方から突っ込みを受けているのは、そういう理由ですよねorz # saltが漏れても容易には解析できなくなるので、はるかにマシとは思いたいのですが・・・とはいえ、昨今のマシンパワーを考えると安心はできないようですね。
ハッシュとsaltの両方が流出した場合は?
> 料理なら見ればわかりますよねってのは無しね。
えっ?何のための例?分かりにくくするためですか?
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
人生unstable -- あるハッカー
なんでパスワードまで流出するの (スコア:2, 興味深い)
Re: (スコア:0)
平文かどうかに関係なくパスワードそのものを保存していたことが問題だろう。
Re:なんでパスワードまで流出するの (スコア:0)
ハッシュを保存していたとしても、ハッシュが流出すれば、プロトコルを合わせれば認証を通せるわけでしょ。
ハッシュが流出しても一緒。流出したこと自体が問題。
Re:なんでパスワードまで流出するの (スコア:2, すばらしい洞察)
>プロトコルを合わせれば認証を通せるわけでしょ。
通せませんよw
正確にはハッシュから元のパスワードを推測するのは困難です。
たとえハッシュ値とハッシュ関数が明らかでも、
そのハッシュ値にするための平文を見つけるのが大変なように
ハッシュ関数は設計されているはずだからです。
Re: (スコア:0)
Re: (スコア:0)
y=f(x)という関数fがあるとして、yからx(と、同じyの値が得られるx')が実質推測不可能なfがハッシュ関数。
別のコメントでも書かれてるけど、ハッシュ関数使った認証ってのは、
大雑把に言ってパスワードをxとして入れたとき得られるyの値と、手元に保存してあるyの値を比較して行う。
そういうfを使うから、yが漏れても認証通すにはxを入れないといけないわけで、元コメが言うようにまず通せない。
ハッシュ値が漏れるってのは、このyが漏れることで、生パスワードxが漏れるのとは影響の度合が全然違うよね?
まぁ、fが分かっているなら手元で総当りでyになるxを探せるわけで、変更した方が無難といえば無難。
でも、普通はfの方もsaltとかで強化するから、ある程度の強度を持つパスワードならバレる可能性はほぼないけど。
Re: (スコア:0)
セキュリティには、あまり詳しくないですが、
>正確にはハッシュから元のパスワードを推測するのは困難です。
それは困難ですが、ハッシュ値とハッシュ関数が明らなら、パスワードが正しいかどうかは判定できるはずなので
それらが手にはいるとパスワードの判定を多少速くできるようになると思います。
それはパスワード辞書や総あたりで見つける為の時間が多少短くなっただけで
もともとパスワードという方法をとっている限りあなたの希望する安全ではないと思います。
Re: (スコア:0)
これsha1なんだが、元のテキスト何かわかる?あなたのパソコンでブルートフォースでもしてどれくらい時間かかるか試してみて!
Re:なんでパスワードまで流出するの (スコア:3, 参考になる)
99%の人には「いまさら」だろうけど誤解が減るのは良いことなので書いておくと、Webサイトでの認証は
のように行われます。
このような手順を踏めば、
ので安全です。
Re: (スコア:0)
現実には元のパスワードが123456とかabcdefな場合がよくあるので、ハッシュが1件でなく全部流出した場合、へぼパスワードのアカウントは全部抜かれるんですけどね。
へぼパスワードが問題になるのはへぼ実装だけ (スコア:2, 参考になる)
それは、にわか知識で作られたへぼ実装の場合だけです。
ちゃんとした実装では、saltもその都度変更するので、同じパスワードでも異なるハッシュ値となります。
この辺 [unixuser.org]とか参照で。
# と偉そうに言いつつ、自分も先週知ったばかりなのでAC(汗
Re:へぼパスワードが問題になるのはへぼ実装だけ (スコア:2, 参考になる)
アルゴリズムとハッシュの組があればブルートフォースや辞書攻撃が可能です。
# ユーザごとに異なるアルゴリズムとして解いていく。
まぁこれにはアルゴリズムが判明しているって前提があるんで、この前提の保護を強化する事は可能です。
ソルトorハッシュに情報量の減らない追加演算(第二ソルトをハードコーディングしたり、ビットシャッフルやビット反転を掛ける)を加えることでアルゴリズムに改変を加えてしまえば、ユーザ情報DBに含まれるソルトやハッシュだけでは解けなくなります。
しかしこの場合も、ソースコード(や追加演算情報を格納した別DB)が抜き取られればやはり辞書攻撃が可能になります。
Re: (スコア:0)
Re: (スコア:0)
あなたの示された参照先にも書いてあると思いますが、salt をランダムにしても,
その値をどこかに保存しておかないといけません。もしそれがハッシュ値と同じ
ファイルの同じ行とかに保存されていたら、「ハッシュ値だけが流出」ということ
はまずないと思います。
ランダムな salt を付加することで、へぼパスワードが少し(場合によってはかなり)
マシなものになりますが、それは salt が知られていないことが前提にあります。
Re: (スコア:0)
失礼しました。「へぼパスワードが問題になるのはへぼ実装だけ」というのはちょっと過激な見出しでした。
元の全部抜かれる [srad.jp]というコメントの問題については大幅に解決しますが、全く問題が無くなるわけではなく、総当たりでいずれ突破されうるというのは皆様のおっしゃる通りです。
# たぶんいろんな方から突っ込みを受けているのは、そういう理由ですよねorz
# saltが漏れても容易には解析できなくなるので、はるかにマシとは思いたいのですが・・・とはいえ、昨今のマシンパワーを考えると安心はできないようですね。
Re: (スコア:0)
ハッシュとsaltの両方が流出した場合は?
Re: (スコア:0)
Salt → 調味料
アルゴリズム → 調理方法
ハッシュ → 初めて見る料理の見本写真
見本写真と塩だけで原料を推測できるかい?
# 料理なら見ればわかりますよねってのは無しね。
# 原料は原型をとどめていないので。
冷や奴好きな私に抜け目はないな。 (スコア:0)
> 料理なら見ればわかりますよねってのは無しね。
えっ?何のための例?分かりにくくするためですか?