アカウント名:
パスワード:
パスワードを復元可能な形式で運用していたら社長以下専務・常務クラスまで獄門晒し首、仕様を作ったエンジニアも二度とIT業界での仕事ができないようにする、ぐらいしても良いのではないか。
GPUクラウドの時代、一般人が付けるような簡単なパスワード（人名+誕生日とか辞書に載っている単語+年号とか）ならSHA-2等でハッシュ化しても現実的な時間で解析できちゃうので無駄です。ソルトとストレッチングやっててもWebサーバで1秒以下で演算できるレベルならGPUクラウドで解析できちゃうし、強度の高いストレッチングやるためにパスワード認証するWebサーバのバックエンドにGPUクラウド使うわけでもないでしょ？
無論、10文字のランダムな英数字だとか、英単語を5個ぐらい繋げたパスワードとかはGPUクラウドで簡単に解析できないので、ハッシュ化の意味はあります。で
saltが十分に長くてもGPUクラウドで解析可能なの？
そのsaltが漏洩しないと、どれだけ自信をもって言えるか。
saltは漏洩している前提。だって、ハッシュ値が漏洩しているんだから。
パスワードをハッシュ化する理由は、サーバー内部のファイルが見られた場合に、パスワードを保存していたら、そのパスワードを使って他のサイトの情報も盗めてしまうから。ハッシュ値が流出しても、それで他のサイトにはログインできない。ハッシュ値をパスワードに戻す必要がある。
パスワードを単純にハッシュ化した場合、すでにレインボーテーブル(あらかじめパスワードとハッシュ値の対応表)が出回っているから、単純なハッシュ化では元のパスワードを復元できてしまう。
そこで、パスワードごとにランダムに生成したsaltを、パスワードに付加してからハッシュ化することで、レインボーテーブルを事実上使えなくする方法がある。
と素人の俺は考えているのだが、間違っていたら突っ込み頼む。
多分想定している攻撃が違うんだと思う。
そこそこの数のアカウントの中から、できるだけ多くのハッシュを解読するという攻撃では、レインボーテーブルは有効だし、その対策として十分長いソルトを付けることも有効。
一方で特定のアカウントのハッシュを解読するという攻撃では、パスワードのバリエーションがsaltのそれより小さくなるところで、効果がほぼ頭打ちになる。
まぁ、被害者の視点に立つなら他人のパスワードがどれだけ漏洩したかは、あまり興味ないよね。
なるほど、ある個人のパスワードをハッシュ値から求める場合は、もうばれているsalt値は意味がないので、純粋な計算量となる。あとはsalt + 生成したパスワード候補 をひたすらGPUでハッシュ化して、入手したハッシュ値と一致するかを試行すればいい。
となるとsaltを使う意味はレインボーテーブルを使えなくして計算量を増やすメリットはあるにしても、もとパスワードが短ければ、GPUクラウドで計算量を大量に用意できれば、比較的短時間に一致させることができる。
つまり、パスワードが短ければ、saltがいくら長くてもランダムでも、無駄だと。とはいえ、ランダムで長いsaltが無駄というわけではないけど。長いパスワードを使っていても、レインボーテーブルに載っていたら、すぐに解かれてしまうから。
他人のパスワードがよくある奴「12345」～で、複数のハッシュが同じ値だとそこから推測できちゃうある意味ソーシャルハック
まあ一般人であれば、アカウントが大量に漏れた場合、セキュリティ対策してない人から狙われるから効果はあるわけですが。
社長だとか芸能人だとか、ピンポイントで狙われそうな人はご愁傷様。
だからソルトを使えって話では？
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
身近な人の偉大さは半減する -- あるアレゲ人
いい加減に (スコア:0)
パスワードを復元可能な形式で運用していたら社長以下専務・常務クラスまで獄門晒し首、仕様を作ったエンジニアも二度とIT業界での仕事ができないようにする、ぐらいしても良いのではないか。
GPUクラウドの時代、ハッシュ化しても無駄です (スコア:3, 興味深い)
GPUクラウドの時代、一般人が付けるような簡単なパスワード（人名+誕生日とか辞書に載っている単語+年号とか）ならSHA-2等でハッシュ化しても現実的な時間で解析できちゃうので無駄です。
ソルトとストレッチングやっててもWebサーバで1秒以下で演算できるレベルならGPUクラウドで解析できちゃうし、強度の高いストレッチングやるためにパスワード認証するWebサーバのバックエンドにGPUクラウド使うわけでもないでしょ？
無論、10文字のランダムな英数字だとか、英単語を5個ぐらい繋げたパスワードとかはGPUクラウドで簡単に解析できないので、ハッシュ化の意味はあります。
で
Re: (スコア:0)
saltが十分に長くてもGPUクラウドで解析可能なの？
Re: (スコア:0)
そのsaltが漏洩しないと、どれだけ自信をもって言えるか。
Re: (スコア:0)
saltは漏洩している前提。
だって、ハッシュ値が漏洩しているんだから。
パスワードをハッシュ化する理由は、サーバー内部のファイルが見られた場合に、パスワードを保存していたら、そのパスワードを使って他のサイトの情報も盗めてしまうから。
ハッシュ値が流出しても、それで他のサイトにはログインできない。ハッシュ値をパスワードに戻す必要がある。
パスワードを単純にハッシュ化した場合、すでにレインボーテーブル(あらかじめパスワードとハッシュ値の対応表)が出回っているから、単純なハッシュ化では元のパスワードを復元できてしまう。
そこで、パスワードごとにランダムに生成したsaltを、パスワードに付加してからハッシュ化することで、レインボーテーブルを事実上使えなくする方法がある。
と素人の俺は考えているのだが、間違っていたら突っ込み頼む。
Re:GPUクラウドの時代、ハッシュ化しても無駄です (スコア:0)
多分想定している攻撃が違うんだと思う。
そこそこの数のアカウントの中から、できるだけ多くのハッシュを解読するという攻撃では、レインボーテーブルは有効だし、その対策として十分長いソルトを付けることも有効。
一方で特定のアカウントのハッシュを解読するという攻撃では、パスワードのバリエーションがsaltのそれより小さくなるところで、効果がほぼ頭打ちになる。
まぁ、被害者の視点に立つなら他人のパスワードがどれだけ漏洩したかは、あまり興味ないよね。
Re: (スコア:0)
なるほど、ある個人のパスワードをハッシュ値から求める場合は、もうばれているsalt値は意味がないので、純粋な計算量となる。
あとはsalt + 生成したパスワード候補 をひたすらGPUでハッシュ化して、入手したハッシュ値と一致するかを試行すればいい。
となるとsaltを使う意味はレインボーテーブルを使えなくして計算量を増やすメリットはあるにしても、
もとパスワードが短ければ、GPUクラウドで計算量を大量に用意できれば、比較的短時間に一致させることができる。
つまり、パスワードが短ければ、saltがいくら長くてもランダムでも、無駄だと。
とはいえ、ランダムで長いsaltが無駄というわけではないけど。
長いパスワードを使っていても、レインボーテーブルに載っていたら、すぐに解かれてしまうから。
Re: (スコア:0)
他人のパスワードがよくある奴「12345」～で、
複数のハッシュが同じ値だとそこから推測できちゃう
ある意味ソーシャルハック
Re: (スコア:0)
まあ一般人であれば、アカウントが大量に漏れた場合、セキュリティ対策してない人から狙われるから効果はあるわけですが。
社長だとか芸能人だとか、ピンポイントで狙われそうな人はご愁傷様。
Re: (スコア:0)
だからソルトを使えって話では？