アカウント名:
パスワード:
パスワードを復元可能な形式で運用していたら社長以下専務・常務クラスまで獄門晒し首、仕様を作ったエンジニアも二度とIT業界での仕事ができないようにする、ぐらいしても良いのではないか。
GPUクラウドの時代、一般人が付けるような簡単なパスワード（人名+誕生日とか辞書に載っている単語+年号とか）ならSHA-2等でハッシュ化しても現実的な時間で解析できちゃうので無駄です。ソルトとストレッチングやっててもWebサーバで1秒以下で演算できるレベルならGPUクラウドで解析できちゃうし、強度の高いストレッチングやるためにパスワード認証するWebサーバのバックエンドにGPUクラウド使うわけでもないでしょ？
無論、10文字のランダムな英数字だとか、英単語を5個ぐらい繋げたパスワードとかはGPUクラウドで簡単に解析できないので、ハッシュ化の意味はあります。でも、そういう強度の高いパスワードをつけるようなセキュリティマニアは、そもそもパスワードを使いまわししないので、ハッシュ化によるセキュリティ向上の恩恵は受けられないのです。
あと、WEBサーバに不正アクセスされたならパスワードをリアルタイムに悪意のあるサーバに投げるJavaScriptの注入とかもできます。
ってことで、パスワードのハッシュ化なんてものは今の時代たいして役にたちません。パスワードやそのハッシュが漏洩しないようにセキュリティを万全にすることが第一で、そこを破られたらもうどうしようもないのです。
高木浩光大先生も、パスワードを使いまわししないのが常識になったのだから、パスワード表示機能はあっても良いと言い出してるね。
高木浩光先生はパスワードの定期的変更不要派で、パスワードのハッシュが漏洩する可能性を考慮してしまうとパスワードの定期的変更が必要派に餌を与えてしまうってことも影響しているだろうけどね（生パスワードの場合漏洩したら解析時間必要なく即悪用される可能性があるので定期的変更しても無駄だが、パスワードハッシュは解析に時間がかかるので定期的変更で攻撃を防げる場合がある）。
2012年https://twitter.com/HiromitsuTakagi/status/198005727317598208 [twitter.com]> しかし、業界の中にはそういう常識を共有していない愚事業者もいるわけで、パスワードをハッシュ化せずに保管したり、（略）するアホが未だ絶えない。
↓
2018年https://twitter.com/HiromitsuTakagi/status/986086337005547520 [twitter.com]> ハッシュ化パスワードを流出させた場合（この場合オフライン攻撃される）を想定する必要がないのは、他のサイトで同じパスワードを使わないのが今日では鉄則だから。
2018年https://twitter.com/HiromitsuTakagi/status/1029730665489547264 [twitter.com]> パスワードはサイト毎に別のものを設定するのが当然となってしまった今日、一周回ってdocomoのパスワード表示機能は妥当な設計ではないか？という時代に突入してきた感ある。
いつまでも昔のセキュリティの常識を絶対だと考えていると、老害扱いされるから気を付けた方が良いよ。昔常識だったパスワードの定期的変更や、入力時のパスワードのマスキング（アスタリスク化）が今では不要となってきているように、世の中は変化していっているから。
パスワードをサイト毎に変えるのが常識と言ってもそれはマニアの間だけで全然末端に浸透してないし、そもそも50個も80個もサイトにアカウントを持ってて全部違うパスワードを付けて覚えるのは不可能。
ヒント：Googleなら先頭にGO、Yahooなら先頭にYA、AmazonならAMをつける
そのルール自体、アカウント数が増えると混乱の元になる。で、繰り返すうちにアカウントロックされて余計面倒なことに…
敵も知っていたら意味が無いがな∴自分だけが知っている連想ルールで付けてます
マニアの間だけって、それいつの認識です？今時のスマホは、Webサイトで新たにパスワード設定しようとしたら、長いランダムなパスワードを自動生成して記憶させるかを聞いてくるのがデフォルトになってるでしょう。そしてスマホユーザー率・スマホのみでアクセスするユーザー率は上がってますし、よくわからないままに従うライトユーザーほどサイトごとにバラバラのパスワードになりますよ。
JPCERTがキャンペーンやって総務省も推奨している方法を「マニアの間だけ」って言い切っちゃうのは、あなたの周りの方々の常識の方を疑っちゃいますよねー
> そもそも50個も80個もサイトにアカウントを持ってて全部違うパスワードを付けて覚えるのは不可能。
パスワードマネージャを使うとか、手帳にメモっておくとかいくらでも方法あるでしょ
そもそも、サイトによってパスワードのルールが違う（記号使えというとこがあれば記号禁止のとこもあるし文字数制限もサイトによって違う）ので必ずいくつかのパスワードを使うことになるし、どのサイトにどれだか忘れちゃうからどっちにしろ書き留める必要が出てくるよね
サイトごとに
srad1ujaujasrad2ujaujasrad3ujaujasrad4ujaujasrad5ujauja
と使い分けていて、その一つが漏洩してしまうと、現時点では多分ないとは思っても他のパスワードは変えたくなるよね。
「あれsradの後の数字何番だっけ？？？」
パスワードマネージャなんてマスターパスワード抜かれたら芋づるに全部やられるから論外ですね。手帳にメモるなんて、なおさら非常識。盗まれたら全部アウトですよ。
で、君はどうやって管理してるのかな？
手帳にメモって自宅に置いてます。
え、盗まれたら、、そもそも手帳が盗まれるくらいなら、もっと大事な物が盗まれています。(さすがに AC)
真っ当なパスワードマネージャーなら二要素認証に対応していますし、普通はYubiKeyに対応しているのでそれ使えば良いでしょ
別の者です。
Webサイトなら例えば、パスワードの接頭辞を123456、後ろにサイト名、github.comなら123456githubとすることにすると管理上のコストは低いよ。それが脆弱かどうかは私には何ともわからないけど、パスワードマネージャーを使うことで攻撃される要素を一つ増やすこととどっちが良いかは私にはもっとわからないな。
普通にパスワード3つくらい使い回しですが？あと末尾の数字つけて変えたり。だいたいみんなそうでしょ？
その程度の使いまわしは「パスワードの定期的な変更はかえって危険」と類似してて今の時代は通用しなくなってきている
普通にパスワードを3パターンほど使いまわしつつサイトごとに違う数字2桁くらい足して変えます。それで十分じゃないですか？
50個も常時サイト訪問することはないし、頻度が低いなら個人宅ならパスワード手帳作るのもひとつの手じゃないかな？手帳がない出先や会社で使うパスワードは5つぐらいなら常時使っていれば出鱈目な文字列のパスワードでも覚えていられる
>>パスワードはサイト毎に別のものを設定するのが当然となってしまった今日これって何処から導かれた結論なのか気になります知らないだけで流出したアカウント情報が元に同一所有者のパスワード被りが近年激減してるとかなんだろうか・・・それとも、パスワード設定時に「他のパスワードと同じ物を使用しないでください」って書かれることが当然になって、責任の所在がパスワードを使いまわしているユーザーに移動したから?
高木先生が言ってるのはたぶん、『セキュリティのために誰が何をやるべきか』みたいな話。
平文のパスワードが漏れると、それを使い回しているユーザに被害が出るので、サービス提供側が、ユーザのパスワードを暗号化するなどして守るべきだった。 ↓暗号解析が容易になって、ちょっと暗号化したくらいでは流出した際の被害は防げなくなってしまった。 ↓サービス側の暗号化では安全が確保できないので、ユーザ側で『パスワードを使い回さない』という対策をとるしかなくなった。 ↓ユーザ側で対策するしかないなら、サービス側は暗号化しない方がむしろ利便性高くていいんじゃないか？
みたいな感じ？
暗号化では無くて一方向のハッシュ化。暗号化だと復号できるので流出時の被害が甚大。1111みたいな雑なパスワードも256文字のパスワードも安全性に差がなくなってしまう。ハッシュ化だと力業で計算するしかなく、強度に差が出る。
こんなこと言っても揚げ足取りにしかならないけれど、ハッシュ化によるセキュリティ上の恩恵はあるでしょう平文保存だったら即座に不正アクセス可能なんだからそもそもハッシュ化して保存する目的と意味はパスワード使いまわしするユーザーがいてもいなくても変わらない
saltが十分に長くてもGPUクラウドで解析可能なの？
そのsaltが漏洩しないと、どれだけ自信をもって言えるか。
saltは万一のハッシュ漏洩時に簡単にレインボーテーブルが作られない・使われないように、ハッシュ関数自体をユーザーごとにわずかに変える（塩を振って味付けする）ためものなので、平文で保存され、最悪漏洩しても構わないものです。あるsaltのハッシュからパスを推定できたとしても、同じパスの他のユーザはsaltが違うので特定できません。
saltは漏洩している前提。だって、ハッシュ値が漏洩しているんだから。
パスワードをハッシュ化する理由は、サーバー内部のファイルが見られた場合に、パスワードを保存していたら、そのパスワードを使って他のサイトの情報も盗めてしまうから。ハッシュ値が流出しても、それで他のサイトにはログインできない。ハッシュ値をパスワードに戻す必要がある。
パスワードを単純にハッシュ化した場合、すでにレインボーテーブル(あらかじめパスワードとハッシュ値の対応表)が出回っているから、単純なハッシュ化では元のパスワードを復元できてしまう。
そこで、パスワードごとにランダムに生成したsaltを、パスワードに付加してからハッシュ化することで、レインボーテーブルを事実上使えなくする方法がある。
と素人の俺は考えているのだが、間違っていたら突っ込み頼む。
GPUクラウド使えば計算できるんですよ、たぶん
多分想定している攻撃が違うんだと思う。
そこそこの数のアカウントの中から、できるだけ多くのハッシュを解読するという攻撃では、レインボーテーブルは有効だし、その対策として十分長いソルトを付けることも有効。
一方で特定のアカウントのハッシュを解読するという攻撃では、パスワードのバリエーションがsaltのそれより小さくなるところで、効果がほぼ頭打ちになる。
まぁ、被害者の視点に立つなら他人のパスワードがどれだけ漏洩したかは、あまり興味ないよね。
なるほど、ある個人のパスワードをハッシュ値から求める場合は、もうばれているsalt値は意味がないので、純粋な計算量となる。あとはsalt + 生成したパスワード候補 をひたすらGPUでハッシュ化して、入手したハッシュ値と一致するかを試行すればいい。
となるとsaltを使う意味はレインボーテーブルを使えなくして計算量を増やすメリットはあるにしても、もとパスワードが短ければ、GPUクラウドで計算量を大量に用意できれば、比較的短時間に一致させることができる。
つまり、パスワードが短ければ、saltがいくら長くてもランダムでも、無駄だと。とはいえ、ランダムで長いsaltが無駄というわけではないけど。長いパスワードを使っていても、レインボーテーブルに載っていたら、すぐに解かれてしまうから。
他人のパスワードがよくある奴「12345」～で、複数のハッシュが同じ値だとそこから推測できちゃうある意味ソーシャルハック
まあ一般人であれば、アカウントが大量に漏れた場合、セキュリティ対策してない人から狙われるから効果はあるわけですが。
社長だとか芸能人だとか、ピンポイントで狙われそうな人はご愁傷様。
だからソルトを使えって話では？
> 簡単なパスワード（人名+誕生日とか辞書に載っている単語+年号とか）と> 10文字のランダムな英数字だとか、英単語を5個ぐらい繋げたパスワード
の間に、結構な領域があるのでは。（つまり極論では？）
私の場合、英文フレーズの各単語から文字を抽出（＝辞書にない）＋数字を入れた、10文字程度のパスワード、などを使う。だが、別にセキュリティマニアではないので、
> でも、そういう強度の高いパスワードをつけるようなセキュリティマニアは、そもそもパスワードを使いまわししない
という想定は成り立たない。（主観的なセキュリティクラスごとに、何種類かを使いまわしする）そういう人も少なくないと思うのだが。
むしろ、情報が漏れた場合に「安易なパスワードユーザ」も「ある程度工夫したパスワードを使うユーザ」も、区別なしに瞬時に再利用できる生パスワード保存は、可能な防御もしていない点で、充分に非難されることだと思う。
つまり、今でも業者がハッシュ化の意味は十分あるし、すべきだと思う。
1件のパスワードを現実的な時間で解析できたとしても、480万件のパスワードを現実的な時間で解析できるの？大量のパスワードを得たとして、それを現実的に使えるものにするためには膨大な計算資源が必要となれば、得られた情報の価値が下がる。十分な抑止効果になると思うけど。
ある意味正しいけど、情報の価値はそんなことでは変わらないと思う。屁理屈いうなら1億件のパスワードが漏洩したら、480万件より解析に時間がかかるから抑止効果がより高いということになる。
勿論、ダミーデータを入れる等の対策に意味がないとは言わない。
単なる屁理屈ですね。件数が増えても、解析時間と解析で得られる価値が比例するから抑止効果は変わらない。得られる価値と、そのためにかかるコストの比が重要。生パスワードよりハッシュ化したものの方が、価値を得るためのコストが高いから有効なんです。
パスワードを労力無しに取得できるのと、費用をかけて解析しないと解読できないのとでは意味合いが全く違うと思うのですが…
「解析できちゃう」って書いてるけど、そういう記事読んだだけで、やったこともないし、具体的な手順も知らないんだろ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはシンプルである。必要なのはそのシンプルさを理解する素質だけである -- Dennis Ritchie
いい加減に (スコア:0)
パスワードを復元可能な形式で運用していたら社長以下専務・常務クラスまで獄門晒し首、仕様を作ったエンジニアも二度とIT業界での仕事ができないようにする、ぐらいしても良いのではないか。
GPUクラウドの時代、ハッシュ化しても無駄です (スコア:3, 興味深い)
GPUクラウドの時代、一般人が付けるような簡単なパスワード（人名+誕生日とか辞書に載っている単語+年号とか）ならSHA-2等でハッシュ化しても現実的な時間で解析できちゃうので無駄です。
ソルトとストレッチングやっててもWebサーバで1秒以下で演算できるレベルならGPUクラウドで解析できちゃうし、強度の高いストレッチングやるためにパスワード認証するWebサーバのバックエンドにGPUクラウド使うわけでもないでしょ？
無論、10文字のランダムな英数字だとか、英単語を5個ぐらい繋げたパスワードとかはGPUクラウドで簡単に解析できないので、ハッシュ化の意味はあります。
でも、そういう強度の高いパスワードをつけるようなセキュリティマニアは、そもそもパスワードを使いまわししないので、ハッシュ化によるセキュリティ向上の恩恵は受けられないのです。
あと、WEBサーバに不正アクセスされたならパスワードをリアルタイムに悪意のあるサーバに投げるJavaScriptの注入とかもできます
。
ってことで、パスワードのハッシュ化なんてものは今の時代たいして役にたちません。
パスワードやそのハッシュが漏洩しないようにセキュリティを万全にすることが第一で、そこを破られたらもうどうしようもないのです。
高木浩光先生も、一周回ってパスワード表示機能は妥当と言い出してる (スコア:4, 興味深い)
高木浩光大先生も、パスワードを使いまわししないのが常識になったのだから、パスワード表示機能はあっても良いと言い出してるね。
高木浩光先生はパスワードの定期的変更不要派で、パスワードのハッシュが漏洩する可能性を考慮してしまうとパスワードの定期的変更が必要派に餌を与えてしまうってことも影響しているだろうけどね（生パスワードの場合漏洩したら解析時間必要なく即悪用される可能性があるので定期的変更しても無駄だが、パスワードハッシュは解析に時間がかかるので定期的変更で攻撃を防げる場合がある）。
2012年
https://twitter.com/HiromitsuTakagi/status/198005727317598208 [twitter.com]
> しかし、業界の中にはそういう常識を共有していない愚事業者もいるわけで、パスワードをハッシュ化せずに保管したり、（略）するアホが未だ絶えない。
↓
2018年
https://twitter.com/HiromitsuTakagi/status/986086337005547520 [twitter.com]
> ハッシュ化パスワードを流出させた場合（この場合オフライン攻撃される）を想定する必要がないのは、他のサイトで同じパスワードを使わないのが今日では鉄則だから。
2018年
https://twitter.com/HiromitsuTakagi/status/1029730665489547264 [twitter.com]
> パスワードはサイト毎に別のものを設定するのが当然となってしまった今日、一周回ってdocomoのパスワード表示機能は妥当な設計ではないか？という時代に突入してきた感ある。
いつまでも昔のセキュリティの常識を絶対だと考えていると、老害扱いされるから気を付けた方が良いよ。
昔常識だったパスワードの定期的変更や、入力時のパスワードのマスキング（アスタリスク化）が今では不要となってきているように、世の中は変化していっているから。
Re: (スコア:0)
パスワードをサイト毎に変えるのが常識と言ってもそれはマニアの間だけで全然末端に浸透してないし、
そもそも50個も80個もサイトにアカウントを持ってて全部違うパスワードを付けて覚えるのは不可能。
Re:高木浩光先生も、一周回ってパスワード表示機能は妥当と言い出してる (スコア:1)
ヒント：Googleなら先頭にGO、Yahooなら先頭にYA、AmazonならAMをつける
Re: (スコア:0)
そのルール自体、アカウント数が増えると混乱の元になる。
で、繰り返すうちにアカウントロックされて余計面倒なことに…
Re: (スコア:0)
敵も知っていたら意味が無いがな
∴自分だけが知っている連想ルールで付けてます
Re:高木浩光先生も、一周回ってパスワード表示機能は妥当と言い出してる (スコア:1)
マニアの間だけって、それいつの認識です？
今時のスマホは、Webサイトで新たにパスワード設定しようとしたら、長いランダムなパスワードを自動生成して記憶させるかを聞いてくるのがデフォルトになってるでしょう。
そしてスマホユーザー率・スマホのみでアクセスするユーザー率は上がってますし、よくわからないままに従うライトユーザーほどサイトごとにバラバラのパスワードになりますよ。
Re:高木浩光先生も、一周回ってパスワード表示機能は妥当と言い出してる (スコア:1)
JPCERTがキャンペーンやって総務省も推奨している方法を
「マニアの間だけ」って言い切っちゃうのは、
あなたの周りの方々の常識の方を疑っちゃいますよねー
Re: (スコア:0)
> そもそも50個も80個もサイトにアカウントを持ってて全部違うパスワードを付けて覚えるのは不可能。
パスワードマネージャを使うとか、手帳にメモっておくとかいくらでも方法あるでしょ
そもそも、サイトによってパスワードのルールが違う（記号使えというとこがあれば記号禁止のとこもあるし文字数制限もサイトによって違う）ので必ずいくつかのパスワードを使うことになるし、どのサイトにどれだか忘れちゃうからどっちにしろ書き留める必要が出てくるよね
Re:高木浩光先生も、一周回ってパスワード表示機能は妥当と言い出してる (スコア:1)
サイトごとに
srad1ujauja
srad2ujauja
srad3ujauja
srad4ujauja
srad5ujauja
と使い分けていて、その一つが漏洩してしまうと、現時点では多分ないとは思っても他のパスワードは変えたくなるよね。
Re: (スコア:0)
「あれsradの後の数字何番だっけ？？？」
Re: (スコア:0)
パスワードマネージャなんてマスターパスワード抜かれたら芋づるに全部やられるから論外ですね。
手帳にメモるなんて、なおさら非常識。盗まれたら全部アウトですよ。
Re:高木浩光先生も、一周回ってパスワード表示機能は妥当と言い出してる (スコア:1)
で、君はどうやって管理してるのかな？
Re: (スコア:0)
手帳にメモって自宅に置いてます。
え、盗まれたら、、
そもそも手帳が盗まれるくらいなら、もっと大事な物が盗まれています。
(さすがに AC)
Re: (スコア:0)
真っ当なパスワードマネージャーなら二要素認証に対応していますし、普通はYubiKeyに対応しているのでそれ使えば良いでしょ
Re: (スコア:0)
別の者です。
Webサイトなら例えば、パスワードの接頭辞を123456、後ろにサイト名、github.comなら123456githubとすることにすると
管理上のコストは低いよ。
それが脆弱かどうかは私には何ともわからないけど、パスワードマネージャーを使うことで攻撃される要素を一つ増やすことと
どっちが良いかは私にはもっとわからないな。
Re: (スコア:0)
普通にパスワード3つくらい使い回しですが？
あと末尾の数字つけて変えたり。
だいたいみんなそうでしょ？
Re: (スコア:0)
その程度の使いまわしは
「パスワードの定期的な変更はかえって危険」
と類似してて今の時代は通用しなくなってきている
Re: (スコア:0)
普通にパスワードを3パターンほど使いまわしつつ
サイトごとに違う数字2桁くらい足して変えます。
それで十分じゃないですか？
Re: (スコア:0)
50個も常時サイト訪問することはないし、頻度が低いなら個人宅ならパスワード手帳作るのもひとつの手じゃないかな？
手帳がない出先や会社で使うパスワードは5つぐらいなら常時使っていれば出鱈目な文字列のパスワードでも覚えていられる
Re: (スコア:0)
>>パスワードはサイト毎に別のものを設定するのが当然となってしまった今日
これって何処から導かれた結論なのか気になります
知らないだけで流出したアカウント情報が元に同一所有者のパスワード被りが近年激減してるとかなんだろうか・・・
それとも、パスワード設定時に「他のパスワードと同じ物を使用しないでください」って書かれることが当然になって、
責任の所在がパスワードを使いまわしているユーザーに移動したから?
Re:高木浩光先生も、一周回ってパスワード表示機能は妥当と言い出してる (スコア:1)
高木先生が言ってるのはたぶん、
『セキュリティのために誰が何をやるべきか』
みたいな話。
平文のパスワードが漏れると、それを使い回しているユーザに被害が出るので、
サービス提供側が、ユーザのパスワードを暗号化するなどして守るべきだった。
↓
暗号解析が容易になって、ちょっと暗号化したくらいでは流出した際の被害は防げなくなってしまった。
↓
サービス側の暗号化では安全が確保できないので、ユーザ側で『パスワードを使い回さない』という対策をとるしかなくなった。
↓
ユーザ側で対策するしかないなら、サービス側は暗号化しない方がむしろ利便性高くていいんじゃないか？
みたいな感じ？
Re: (スコア:0)
暗号化では無くて一方向のハッシュ化。
暗号化だと復号できるので流出時の被害が甚大。
1111みたいな雑なパスワードも256文字のパスワードも
安全性に差がなくなってしまう。
ハッシュ化だと力業で計算するしかなく、強度に差が出る。
Re: (スコア:0)
こんなこと言っても揚げ足取りにしかならないけれど、ハッシュ化によるセキュリティ上の恩恵はあるでしょう
平文保存だったら即座に不正アクセス可能なんだから
そもそもハッシュ化して保存する目的と意味はパスワード使いまわしするユーザーがいてもいなくても変わらない
Re: (スコア:0)
saltが十分に長くてもGPUクラウドで解析可能なの？
Re: (スコア:0)
そのsaltが漏洩しないと、どれだけ自信をもって言えるか。
Re:GPUクラウドの時代、ハッシュ化しても無駄です (スコア:2)
saltは万一のハッシュ漏洩時に簡単にレインボーテーブルが作られない・使われないように、ハッシュ関数自体をユーザーごとにわずかに変える（塩を振って味付けする）ためものなので、平文で保存され、最悪漏洩しても構わないものです。
あるsaltのハッシュからパスを推定できたとしても、同じパスの他のユーザはsaltが違うので特定できません。
Re: (スコア:0)
saltは漏洩している前提。
だって、ハッシュ値が漏洩しているんだから。
パスワードをハッシュ化する理由は、サーバー内部のファイルが見られた場合に、パスワードを保存していたら、そのパスワードを使って他のサイトの情報も盗めてしまうから。
ハッシュ値が流出しても、それで他のサイトにはログインできない。ハッシュ値をパスワードに戻す必要がある。
パスワードを単純にハッシュ化した場合、すでにレインボーテーブル(あらかじめパスワードとハッシュ値の対応表)が出回っているから、単純なハッシュ化では元のパスワードを復元できてしまう。
そこで、パスワードごとにランダムに生成したsaltを、パスワードに付加してからハッシュ化することで、レインボーテーブルを事実上使えなくする方法がある。
と素人の俺は考えているのだが、間違っていたら突っ込み頼む。
Re: (スコア:0)
GPUクラウド使えば計算できるんですよ、たぶん
Re: (スコア:0)
多分想定している攻撃が違うんだと思う。
そこそこの数のアカウントの中から、できるだけ多くのハッシュを解読するという攻撃では、レインボーテーブルは有効だし、その対策として十分長いソルトを付けることも有効。
一方で特定のアカウントのハッシュを解読するという攻撃では、パスワードのバリエーションがsaltのそれより小さくなるところで、効果がほぼ頭打ちになる。
まぁ、被害者の視点に立つなら他人のパスワードがどれだけ漏洩したかは、あまり興味ないよね。
Re: (スコア:0)
なるほど、ある個人のパスワードをハッシュ値から求める場合は、もうばれているsalt値は意味がないので、純粋な計算量となる。
あとはsalt + 生成したパスワード候補 をひたすらGPUでハッシュ化して、入手したハッシュ値と一致するかを試行すればいい。
となるとsaltを使う意味はレインボーテーブルを使えなくして計算量を増やすメリットはあるにしても、
もとパスワードが短ければ、GPUクラウドで計算量を大量に用意できれば、比較的短時間に一致させることができる。
つまり、パスワードが短ければ、saltがいくら長くてもランダムでも、無駄だと。
とはいえ、ランダムで長いsaltが無駄というわけではないけど。
長いパスワードを使っていても、レインボーテーブルに載っていたら、すぐに解かれてしまうから。
Re: (スコア:0)
他人のパスワードがよくある奴「12345」～で、
複数のハッシュが同じ値だとそこから推測できちゃう
ある意味ソーシャルハック
Re: (スコア:0)
まあ一般人であれば、アカウントが大量に漏れた場合、セキュリティ対策してない人から狙われるから効果はあるわけですが。
社長だとか芸能人だとか、ピンポイントで狙われそうな人はご愁傷様。
Re: (スコア:0)
だからソルトを使えって話では？
極論では (スコア:0)
> 簡単なパスワード（人名+誕生日とか辞書に載っている単語+年号とか）
と
> 10文字のランダムな英数字だとか、英単語を5個ぐらい繋げたパスワード
の間に、結構な領域があるのでは。（つまり極論では？）
私の場合、英文フレーズの各単語から文字を抽出（＝辞書にない）＋数字を入れた、10文字程度のパスワード、などを使う。
だが、別にセキュリティマニアではないので、
> でも、そういう強度の高いパスワードをつけるようなセキュリティマニアは、そもそもパスワードを使いまわししない
という想定は成り立たない。（主観的なセキュリティクラスごとに、何種類かを使いまわしする）
そういう人も少なくないと思うのだが。
むしろ、情報が漏れた場合に「安易なパスワードユーザ」も「ある程度工夫したパスワードを使うユーザ」も、区別なしに瞬時に再利用できる生パスワード保存は、可能な防御もしていない点で、充分に非難されることだと思う。
つまり、今でも業者がハッシュ化の意味は十分あるし、すべきだと思う。
Re: (スコア:0)
1件のパスワードを現実的な時間で解析できたとしても、480万件のパスワードを現実的な時間で解析できるの？
大量のパスワードを得たとして、それを現実的に使えるものにするためには膨大な計算資源が必要となれば、得られた情報の価値が下がる。
十分な抑止効果になると思うけど。
Re: (スコア:0)
ある意味正しいけど、情報の価値はそんなことでは変わらないと思う。
屁理屈いうなら1億件のパスワードが漏洩したら、480万件より解析に時間がかかるから抑止効果がより高いということになる。
勿論、ダミーデータを入れる等の対策に意味がないとは言わない。
Re: (スコア:0)
単なる屁理屈ですね。
件数が増えても、解析時間と解析で得られる価値が比例するから抑止効果は変わらない。
得られる価値と、そのためにかかるコストの比が重要。
生パスワードよりハッシュ化したものの方が、価値を得るためのコストが高いから有効なんです。
Re: (スコア:0)
パスワードを労力無しに取得できるのと、費用をかけて解析しないと解読できないのとでは
意味合いが全く違うと思うのですが…
Re: (スコア:0)
「解析できちゃう」って書いてるけど、そういう記事読んだだけで、やったこともないし、具体的な手順も知らないんだろ。