4月21日のtwitterセキュリティクラスタ

パスワードのストレッチングとSALTについてのお話。どちらがよいというものでもないと思いますが、対話により違いと利点と欠点がわかって勉強になりました。

ockeghem: ストレッチングについては徳丸本のP327に説明していますが、あまり詳しくはありません。背景の説明は多いです。徳丸本でもstretchingの回数は千回を目安にしています。 #wasbook / ECナビ　エンジニアブログ : Rails… http://htn.to/xkRYB2

ockeghem: まぁ、stretchingそのものはハッシュを繰り返すだけだから詳しく説明しようがないか。なぜ必要かが重要

tomoki0sanaki: 認証処理が重たくなりますね。 QT @ockeghem stretchingそのものはハッシュを繰り返すだけ・・・

ockeghem: @tomoki0sanaki 処理が重くなることは、stretchingの本質ので仕方ないですね。攻撃者にとって重く、正規処理には軽いという方法があればよいのですが、それは無理ということで

tomoki0sanaki: SALT だけでいいんじゃないですか? ストレッチを+1回するなら、SALTを+1文字長くした方が効率的だと思います。 QT @ockeghem 攻撃者にとって重く、正規処理には軽い・・・

s_hskz: いつか論議が始まるといいなぁと期待してました。SALT vs ストレッチ

ockeghem: @tomoki0sanaki saltが攻撃者に分かるという前提で総当たり攻撃や辞書攻撃に対する耐性を高めることがstretchingの目的です。saltを一文字増やしても総当たりのコストはあまり変わりません

ockeghem: vsというか、両方必要ですね RT @s_hskz: いつか論議が始まるといいなぁと期待してました。SALT vs ストレッチ

s_hskz: @ockeghem そうでしたね。ご教示ありがとうございます。 @tomoki0sanaki さんとの直接的な対話が始まるとどこに違いがあるかわかりやすいかなーと常日頃から思っていました。

tomoki0sanaki: なるほど、そこに違いがありますね。 QT @ockeghem saltが攻撃者に分かるという前提で・・・

tomoki0sanaki: SALTばれてる前提でも、SALT があるだけで、RainbowCrack はかなり厳しくなる。

tomoki0sanaki: 例えば、8文字のRainbowTableを作っても、SALT2文字だと、6文字のパスワード解析までしかできないようなもの。SALT256文字とかは鬼だな。

tomoki0sanaki: さらに、256文字以上のRainbowTable は現実的ではない。・・・というか、8とか、9文字のRainbowTable が現実的ではない。

tomoki0sanaki: あ、文字種は、英大小文字/数字/記号もたくさん。だと、8文字とか9文字のRainbowTableは非現実的。

tomoki0sanaki: 3DES の中間一致攻撃の考え方が、ストレッチに対しても適用できるような気がする。

tomoki0sanaki: 中間一致攻撃を考慮すると、3DES の有効ビット数は、58bit(56+1+1)程度。繰り返すことで、1ビットしか増えない。

tomoki0sanaki: ストレッチの耐性が、"線形" 程度にか変化しないということが気に入らない。

ockeghem: @tomoki0sanaki それは、ハッシュ値、ソルト、ハッシュの計算方法が全部既知という前提で、かつ総当たりというローテクな方法に対抗するためには仕方ないですよ。何か秘密情報を使っていいという前提なら簡単ですけどね

tomoki0sanaki: パスワードファイルの漏洩の事前対策として、ストレッチならば、「パスワードの定期変更」もパスワードファイルの漏洩時には効果あるんだけどな。

tomoki0sanaki: だって、SQL Injection とかでパスワードハッシュが漏洩したりしたら、「速やかにパスワード変えてください」ってアナウンスがあるわけだし・・・

tomoki0sanaki: ローカルパスワードクラックに成功したけど、その時には既にパスワードが変更されてました。って事になればよい。

tomoki0sanaki: というか、その程度のことを必須だとか言われても・・・と思うわけです。 "線形" だし・・・無意味ではないから、実装したいやつらだけが実装すればいいとは思うけどね。それは「パスワードの定期変更」も一緒。

ockeghem: @tomoki0sanaki 英数字8文字のパスワードハッシュを676コアのクラスタで計算すると3日で総当たり可能、という例が徳丸本に書いてあります。ボットネットで計算させるとか…定期的変更でかわすにしても、ある程度時間を稼ぐためにストレッチングは有効です。必須と言えないにしても

ockeghem: まぁ、Amazonみたいに、128文字まで、文字種制限なしのパスワードにして、皆が強固なパスワードつければ、ストレッチは要らないと思いますけどね

tomoki0sanaki: ボットネットなどの大規模分散処理も考慮すれば、RainbowCrackよりも普通の総当り攻撃の方が脅威なのかも知れない。・・・まぁ、RainbowTable をその大規模分散処理で生成するという合わせ技もあるかもしれないが・・・

kitagawa_takuji: 個人で4096コアのクラッキング用サーバ自作している人もいます。http://bit.ly/hd0ekx　RT @ockeghem: @tomoki0sanaki 英数字8文字のパスワードハッシュを676コアのクラスタで計算すると3日で総当たり可能、という例が徳丸本に書いてありま

ockeghem: @kitagawa_takuji これはすごいですね

mt7080: @tomoki0sanaki 暗号学者は一生懸命軽い実装のハッシュ関数を考えてるのにストレッチングとか言って何万回も繰り返し使うとか意味ねーじゃんと、某隣のH君が言ってますた。

tomoki0sanaki: 御意。ストレッチには美学を感じないんですよね。 RT @mt7080 暗号学者は一生懸命軽い実装のハッシュ関数を考えてるのにストレッチングとか言って何万回も繰り返し使うとか意味ねーじゃんと、某隣のH君が言ってますた。

やっぱり7年も同じパスワードだと、強度は問題なくてもいろんな理由で漏れたり解析されるリスクは高まっちゃうわけですかね。ということでパスワードの定期変更について。

tamiyata: こんなことになってるとは知らなかった…韓国はセキュアOSの展開が速いと聞いていましたが、最後はやはり人の脆弱性なのか／「7年間同じ管理者パスワードだった」銀行システムに大非難：趙 章恩「Korea on the Web」 http://ow.ly/4ENcF

ockeghem: rootなどの管理者パスワードは「定期的に」変更するのではなく、担当者の異動や退職のタイミングで変更すべき。それが難しい場合の次善の方法が定期的変更 / 「7年間同じ管理者パスワードだった」銀行システムに大非難：趙 章恩「Korea o… http://htn.to/gGQo1W

kitagawa_takuji: 担当者以外が知っていることも知ってしまうことも結構ある。そういった人を振り落とすには定期変更も必要では？RT @ockeghem: rootなどの管理者パスワードは「定期的に」変更するのではなく、担当者の異動や退職のタイミングで変更すべき。それが難しい場合の次善の方法が定期的変更

ockeghem: その状況を管理して変更すべきであって、定期変更で対応することは、変更されるまでの期間「危険な状態」を受容していることになりますね RT @kitagawa_takuji: 担当者以外が知っていることも知ってしまうことも結構ある。そういった人を振り落とすには定期変更も必要では？

kitagawa_takuji: 本来はその状況を管理すべきだけど出来ないのが人間だからシステムによる定期変更で保険を掛けるしかない。管理者が気付かないうちに知られてしまうこともある。RT @ockeghem: その状況を管理して変更すべきであって、定期変更で対応することは、変更されるまでの期間「危険な状態」を受

引き続きEvernoteのmalaさんによる調査が。今度はChromeです。

bulkneets: あー。。 http://bit.ly/fqLLsh

bulkneets: 代用手段はあります http://bit.ly/gQZtEd

bulkneets: 拡張機能のコンテクストからCookieの操作が出来ない → 普通にWeb画面開いて拡張機能とメッセージパッシングで通信して認証に必要なトークン受け渡すなどすれば良い

bulkneets: 拡張機能、サードパーティCookie送信もオフだとログインできない、サードパーティCookie受信オフだとパスワード毎回入力ログインできるけど警告出る

bulkneets: 大多数の人がブラウザのデフォルト設定のままで使うわけで、その結果手抜き実装になる。デフォルト設定に戻せ(Chrome)と言ったりデフォルト設定変えろ(IE)と言ったり一貫してない。

bulkneets: どうせ今セットアップしてる人は入れなおさないことには直せないので書くけどWebクリッパーのブックマークレットの実装、EN_CLIP_HOSTがグローバル変数なので__defineGetter__など使ってサイト側から挙動変えられる http://bit.ly/gVkteQ

bulkneets: どういう影響があるかっつーと説明するのが難しいな、ブックマークレットを使うと Evernoteかと思ったらEvernoteじゃないサイトが表示されるかもしれない。ただし悪意のあるサイト上で起動した場合のことで、悪意のあるサイトを訪問した時点で悪いことはできるのだから軽微といえば軽微

bulkneets: scriptタグ追加してページ内にiframe表示するようなタイプのブックマークレットの共通の問題でもある

bulkneets: ブラウザがトラッキング拒否の仕様をつくりはじめたせいで、Cookieは便利サービスのためにサードパーティ含めて全許可!!行動トラッキング嫌な人はオプトアウト!! みたいな感じになってしまっている…

その他に気になったことはこのあたり。

bulkneets: 引っかかる人そうそういないだろうけど共有してるドキュメントのリンクでfile://とか添付ファイルダブルクリックで実行形式ファイル動く http://bit.ly/fPTnvU

wikileaksjp: また一つオンラインサービスが陥落: ドロップボックスが規約変更、皆が手を引く時がきた - データは政府に手にわたると http://is.gd/hidDhK #wikileaks #wikileaksjp #wl_jp

nao_pcap: インターネット接続サービスにおける児童ポルノ・ブロッキングの開始について〈別紙〉 2011年 KDDI株式会社 http://www.kddi.com/corporate/news_release/2011/0421/besshi.html

takesako: SQL Injectionにより、Comodoリセラー(RA)に侵入、IISに侵入後、脆弱性を利用してSYSTEM権限を取得、TrustDll.dllをデコンパイルし平文パスワードを奪取、API経由でSSL偽証明書に署名 http://bit.ly/i2qhX6

MasafumiNegishi: 脆弱性対策情報データベース「JVN iPedia」を機能強化 http://bit.ly/fHyRZ4

bulkneets: 少し前にSkype for MacのHot fixが出てます。自分が把握してる範囲で割と深刻なバグがあったので5.1.0.922より低いバージョンの人は手動アップデートした方がいいです(アップデートが浸透するまで詳細が書けない) http://bit.ly/fmAzKF

ymzkei5: ■「一度公開した情報は、完全に削除できないことを理解」　大和ハウス、ソーシャルメディアポリシーを公表 - ITmedia ニュース http://bit.ly/fvUGP9 、 http://bit.ly/hWBR6Z

msaitotypeR: 保存してるだけじゃなく送信してたんだ。「iPhoneは実際のところ1日に2度、Appleにあなたのロケーションを送信している」 http://blog.f-secure.jp/archives/50592175.html

tomoki0sanaki: だれかれとなく・・・・ 基本的に document と location と innerHTML と .html() [JQuery] を監視しています。ひっかかったら JavaScriptのソース見る。という感じ。・・・prototype.js は!?...orz

tomoki0sanaki: やっぱり、ちょっといじったリクエストを送るとアカウントを無効化する Web アプリって、すごいと思うんだ....(T_T)。 セッション切るだけで勘弁して...m(_ _)m

bulkneets: RT: XSSでお困りのみなさん！今ならリップクリーム差し上げるだけで、あのmalaさんのコンサルティングが受けられるチャンスですよ！

hasegawayosuke: おれの使いかけのリップクリームでよければ。

mincemaker: 「セキュリティのことなので詳細には書けませんが、そう簡単に侵入できない作り、ならびに、複合化出来ない作りにしております。」に吹いた。キチガイすぎ。 http://twitter.com/ocn_kakeibo/status/60936034522890240

mincemaker: 「そう簡単に侵入できない作りにしております」は土曜日のプレゼンで出してくる人がいると予想する!