@qzm4u 後は、総当りするにしても、ハッシュ化計算の計算速度が長いと攻撃しにくいってのはあるかな。実装上少しでも早く! という気持ちはわかるけど、攻撃対策という意味では長い方がうれしいなw ユーザにはログイン1回、パスワード変更1回で計算速度の違いは分からんよw
2013-03-07 10:17:13@REVI エリア88は原作準拠でもう一回つくってほしいなぁ。いっそ、全員男体化して女性向けで女性モデラーを増やすのだ
2013-03-07 10:26:33@ikutana @qzm4u ちなみにSALT固定のMD5で英数記号6文字(95^6)でAmazon EC2に計算させたら4秒で完了した。全件検索かけたとしてもせいぜい4分。秒間28億検索。お値段12円。英数記号8文字だったとしても最大25日、11万円くらい。
2013-03-07 10:36:10@qzm4u そう。なしの場合。例えば10万回繰り返したとしたら、最大4分×10万回の実施が必要になるね。そして、ソースさえ漏れなければ、何回ストレッチングしてるかも分からないので、不毛な戦いがはじまるみん。
2013-03-07 10:41:40@kng_afilia MD5ベースでパスワードリストが漏れたらセキュアじゃないと言えそうだなぁ。11万といっても、偶然SALTが一致するユーザーが複数いればその分一件あたりのコストは下がる。SALT抽出して一番多いSALTに対して攻撃をかければ、損益分岐点は下がりますね。
2013-03-07 10:55:39@ikutana 実際に全件探索するかっていうと、そこまでかからないハズだし。おっしゃるとおり、十分にランダム性を持たせていたとしても、偶然一致したらさらにコストは下がりますね。その認証情報で得られる対価を考えると・・・怖ぇっ!
2013-03-07 10:59:23@kng_afilia ユーザー数に対してSALTがユニークになるくらいの長さが必要なのかな。AMAZON、Googleクラスなら64ビットだとちょっとよろしくない。まあ、ランダムに振るんじゃなくてシーケンシャルに振れば問題は無さそうだけど。
2013-03-07 11:01:31@kng_afilia 6キャラクターパスワードを許容するシステムならすべてのSALTに対して6キャラクタ探索した方が効率はよさそうですね。
2013-03-07 11:03:32@kng_afilia ハッシュ関数がランダム関数であればそこら辺は安全だと思うけど(証明してない)あまりよろしくないのも確かかなぁ。大規模系だと個別のシステムユニークIDとその中での一貫ナンバーかなぁ。
2013-03-07 11:05:26@kng_afilia まあ、SHA256とか512とか3使うのなら、その分伸ばせるのをSALTの長さに投入するというのはありかもしれないなぁ。 もっと言うと、SALT長はハッシュ長より長くても良いかもしれない。
2013-03-07 11:08:22.@ikutana @ikutana 少なくともセッションIDはユニークにしているハズなので、同じレベルでSALTも実装させれば間違いないかと。とはいえ、そのユーザ数でやるのも大変なのは重々承知。むしろ、最初に発行するセッションIDをSALTに使って、被りがあったら再計算とか?
2013-03-07 11:08:29@kng_afilia それ、ユーザーが増えた時にかぶりの判定のための検索のコストが大きくないですかね?ソートしておけばバイナリサーチでいけるからそうでもないのかな。
2013-03-07 11:10:30@kng_afilia ランダムにやるなら長さでバースデーバウンドを保証する必要があるし、シーケンシャルにやるのなら管理は必要ってことになるかな。 いずれにせよ、プログラマが思いつきで実装していいような世界じゃないことは確か。計算コストも無視できないし。
2013-03-07 11:12:02@ikutana 新規登録時のみに走る計算なので問題なっしんぐ! なのかどうかは、実際にどのくらいの頻度で、どのくらいのユーザが登録するのかを試算しなきゃダメですけどねw
2013-03-07 11:12:39@kng_afilia evernoteみたいに、全員一斉更新とかなった時に負荷が半端じゃ無いと思います。
2013-03-07 11:13:39@ikutana 認証についての設計評価は必須ですね! 朝っぱらからお付き合いいただきありがとうございましたw ガチ業務に戻るのです! しかし、プログラマが思いつきで実装して、認証機能がヤバいことはマジで多いので、啓蒙したいですねぇ・・・。
2013-03-07 11:15:57