スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

10月14日のtwitterセキュリティクラスタ


夜中に盛り上がった、パスワードって定期的に変更するものなの? という話題。僕はだいたい変更を重ねたあげくわからなくなってリセットということが多いので、なるべく変えたくない派です。パスワードの強度って盗聴とかソーシャルとかにはあんまり意味がないんですよね。
ockeghem: 次は認証の章を書こうと思って準備していて、アノ話題に触れるかどうかで、考え中。アレとは「パスワードの定期的変更問題」 #wasbook

ymzkei5: @ockeghem ユーザIDと同じパスワードは許さないとか、英数字だけでなく記号も含めて○文字以上にしろとか、そういうパスワードポリシーの話の一環として参考までに触れる程度とか。。

ockeghem: .@ymzkei5 いや、もっと過激なことを考えていまして、無駄だからやるなとか>パスワードの定期的変更

ockeghem: 仮に、パスワードを3ヶ月毎に変更することに意味があるとする。パスワード長を一文字長くすると、組み合わせの総数が約90倍増えるから、3ヶ月×90=22.5年 で、20年に一回変更すればよいことにならないか?

ockeghem: いや、その間にCPUも速くなるから、そういう単純計算にはならないけど、では2文字増やせば…パスワードを定期的に変更するくらいなら、パスワードを2文字長くする方をとる人が多いのでは?

hebikuzure: @ockeghem 同じパスワードを長く使えば、何らかの理由で第三者に知られる危険が大きくなるからでは???

ockeghem: @hebikuzure そういう状況が大いにあり得る(パスワードが洩れているがおおっぴらには悪用されない)ならば考慮の余地がありますが、洩れないことに全力を注いだ方がよい場合が大変だと思いますけどね

ockeghem: パスワードの定期的変更が意味がある状況は2種類あると思っていて、一つは、共用アカウントを使っている場合。これは、そもそも共用アカウントを廃止すべきだけど、難しい場合は、パスワードを知っている人がチームを抜けたタイミングなどでパスワードを変更すべき。定期的ではない

hebikuzure: @ockeghem う~ん、「パスワードはメモれ」という話もありますが、その場合は手帳なりにメモした物が密かに第三者に見られていたら、とか考えないとダメなようにも思いますが。結局はケースバイケースという事になるのかもしれません。

ockeghem: もう一つは、オフラインクラック対策なんだけど、そもそもオフラインさせるなということと、 3ヶ月もつパスワードやめて100年もつパスワードにすればいいだけだと

hebikuzure: @ockeghem パスワードはメモしない、ショルダーハックもされない、ソーシャルエンジニアリングにも引っかからない、という前提なら変更するより強度の高いパスワード、というのはあるなあ。その辺りのリスクの評価でしょうかね。

ockeghem: まぁ、コラムに書く程度かなぁ。「パスワードの定期的変更は、ほとんどのケースで意味がありません」と本文に書く勇気が・・・というより、「意味がないことなら本文に書くな」というか

ten_forward: @ockeghem さん,セキュリティの問題なので,「良く言われている事だから」「人に言われたから」という理由でなく,なぜそうするべきなのかを常に考えましょう,というのを理解してほしいなと思いますね.自分がそう出来ているかというと出来てませんが^^;

ockeghem: @ten_forward 100%同意します

sonodam: すでにパスワードを盗まれていて悪用されてしまっているとき、パスワードを変えると悪用しているヤツに嫌がらせすることができる。相手が再度盗みに来てくれたら、そこで気づく可能性が出てくる。・・・その程度かな?>定期的な変更の意義

sonodam: まるっきり無意味とは思わないけど、普通の人にとっては苦労する割に得るモノが少ないかも(笑)>定期的変更

sonodam: そもそも、普通の人にとって「難しい」パスワードをどうやって運用するのか、ということと合わせて考える必要がありそうな希ガス。

sonodam: トータルリスク管理コーディネート(笑)な感じで。



そして、話はネットバンキングのパスワードの話に。三井住友から振り込むことは年に数回なので、そのときは乱数表を探し回ることになります。

hebikuzure: @ockeghem 使ってる銀行のネットバンキングで定期的なパスワード変更を求められるのだけど、これは銀行側のアリバイ作りという事なのかなあ www

ockeghem: 三井住友は警告は出ますが無視していますね。ログイン時にワンタイムパスワードも入れているし…。三井住友は色々文句があるんですけどね。きっとMBSDさんがコンサルで入ってないんでしょうね

ockeghem: 三井住友銀行のオンラインバンキングに対する文句ですぐ思いつくのは、1)ワンタイムパスワードの入力画面がマスク表示、2)振り込みなど重要操作の時には「乱数表」が必要、の2点かな。ワンタイムパスワードのトークン使っているのに、振り込みの時は乱数表ですぜ

ockeghem: あと、「パスワードの保存はハッシュにすべきで、復号可能な暗号はだめ」という「常識」にも疑問を持っています

ripjyr: @ten_forward @ockeghem カード番号を全部とか保存するのもやめてほしい、最後の桁は保存せずに置いてほしい。

ockeghem: @ripjyr カード番号の保存は話が全然別ですよね。パスワードは何らかの形(ハッシュも含めて)で保存しないとパスワードとしての要件を満たさないですから。

nouvellelune: @ockeghem 平文保存は論外としても、復号可能暗号と不可逆暗号(ハッシュ)であれば、さほど差はないということでしょうか。RT "あと、「パスワードの保存はハッシュにすべきで…"

ockeghem: @nouvellelune 復号可能暗号の運用が難しいのは、鍵の管理が難しいところですが、そういう議論なしに、不可逆暗号が万能みたいな議論が気に入らないですね。不可逆暗号を安全に使うのもそれなりに難しいです

nouvellelune: 「暗号化して保存→定期的に復号して別な鍵で暗号化(前の鍵は破棄)」のサイクルを回せれば、むしろ可逆暗号保存のほうがハッシュ保存より強度が高くなるのでは…。

ockeghem: 「パスワードはハッシュで保存するのが常識だろ」と言うのは簡単ですが、復号可能な暗号化する場合とどのように安全性に差があるのかとか、ちゃんと考えている人は少ないように思えますね。発言の内容から推測するに

ymzkei5: @ockeghem 暗号化を許すと、暗号の強度の話とか、鍵の保管の話とか、鍵を変更した場合のデータの更新の話とか、色々考えなきゃいけなくて、正直、面倒くさいのかも?w 通常は元の文字列に復元できるようにする必要が無いのだから、ハッシュ化が一番マッチするのでは。

ymzkei5: @ockeghem カード番号をDBに保存する際、(DB側での暗号化はともかく、)Webアプリ側で暗号化しているサイトはあまり見かけないですね。(←そういうサイトのご支援をする案件が多いからかも知れませんが。(^-^;)



チームsutegoma2がHITB2010のCTFに参加されていたようです。結果最下位だったそうですが、一瞬1位になったり惜しいところもあったようです。お疲れ様でした。
sutegoma2: チームsutegoma2は、今年もCTFに参戦します。明日10:00競技開始です。 #HITB2010KL http://twitpic.com/2x12qe

sutegoma2: 現在2位。いくつかのチームは攻撃可能な状態になつでいて、膠着している感じです。 #HITB2010KUL http://twitpic.com/2x7dco

tessy_jp: 現在279500で@sutegoma2 暫定1位!ただ、攻撃1発で最下位という接戦状態!

yoggy: というわけで、1時間の延長戦の末、最下位で終了w。おつかれさまでしたー

tessy_jp: CTF Final score! #HITB2010KUL http://plixi.com/p/50547907



IEでのXSSについて。IEってXSSだけを考えると他にない面白ブラウザみたいなのですが、どうして人気が下がってるのでしょう。
ockeghem: 画像やファイルダウンロードによるXSS脆弱性の保険的対策として、画像などを別ドメインにわけるというのを書きかけたんだけど、IE7以前限定だし、そこまですることはないかと、思いとどまった

hasegawayosuke: @ockeghem IE8でもダウンロード指令を無視してXSS発生できます。丹念に探せば、方法も公開されてます。また、JSONやatomのような非HTMLをHTML 扱いさせてXSSさせる方法も健在です。

ockeghem: .@hasegawayosuke ありがとうございます。書き方が難しいですね。工夫してみます

hasegawayosuke: @ockeghem ドメインを分ける、URLを推測できないものにする、というくらいしか対策は取れないと思います。

masa141421356: @ockeghem セキュリティ上の理由でアップロードされたファイルを別ドメインに分ける実例がこれですね。http://www.bugzilla.org/security/2.22.6/



京大なのに…
rakugodesi: tetsutalowさんが頭抱えてたりして!(^^)! RT @Dullahan: #librahack #iedu_is 図書館事件に関してあまりにもひどいエントリを読んだので、カウンターとして書いてみた。> http://bit.ly/afUiZV



ハニーポットじゃなくってXPのバグだそうです。
HyoYoshikawa: 格さんだな、これ。RT @flyer_to: よく見かける[Free Public WiFi]の正体はコレだったのか。 > 「無料公衆WiFi」の正体&繋いじゃいけない理由 http://t.co/G2NIxKT via @gizmodojapan



あと気になったこと。

ntsuji: Yahoo!JAPAN障害、原因は負荷分散サーバの不具合 - ITmedia News - http://bit.ly/djiMjC


_shimizu: "JSF,Ruby on Rails,ASP.NET に影響する「パディングオラクル」" http://bit.ly/aJSlVr DEMO動画が上がってた→http://bit.ly/9JFK9q


a4lg: …とはいえ、今回の PacSec における発表はかなり長い間取り組んだ成果が含まれている。バイナリ変換に関する見識は去年の AVTokyo 以前からあったアイデアだし、リバースエンジニアリングの効率化というのも自分の数年にわたる AD/HD と「やりたがり」を考えれば必然。


スポンサーサイト

テーマ : セキュリティ
ジャンル : コンピュータ

トラックバック


この記事にトラックバックする(FC2ブログユーザー)

yahoo 障害 yahooきっず

毎日変わる、新しい情報をチェック!話題に困ったら………******トレンドが1分でわかる。毎日更新情報!******食欲の秋ですね~***本日のおすすめ***贈物にいかが!季節毎に替わる美しいベリー達が彩るタルト!御誕生日にメッセージをいれてプレ...おすすめお取り寄せ【

コメントの投稿

非公開コメント

プロフィール

bogus

Author:bogus
FC2ブログへようこそ!

最新記事
最新コメント
最新トラックバック
月別アーカイブ
カテゴリ
検索フォーム
RSSリンクの表示
リンク
ブロとも申請フォーム

この人とブロともになる

QRコード
QR
カレンダー
06-2017
SUN MON TUE WED THU FRI SAT
- - - - 1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 -

05   07

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。