JICS2014レポート(3) 1/14後編
事例から学ぶID漏洩防止
根岸征史さん @ IIJ
- 「情報漏洩事例から見えてくるユーザによるパスワード利用の実態と課題」
- パスワード
- 何十年もずーっと使われている。ずっと変わっていない
- ユーザー視点 → 根岸さん
- 攻撃者視点 → 辻さん
- サイト運営者視点 → 徳丸さん
- 情報漏洩事例(国内) 2013年
- Y! 2200万件
- OCN 400万件
- NAVER 200万件
- 海外
- Adobeの例
- 2013年10月
- 「お客様のIDは攻撃を受けたデータベースに含まれていたものの、パスワードは影響を受けなかった」→うのみにしてはダメ
- ヒント情報も漏洩している → ちゃんと書け
- 9.3Gバイトのテキストファイルに1億5千万
- メールアドレス、3DES
- ECBモード → saltがない。誰と誰のパスワードが同じかわかってしまっていた
- パスワードのヒントも平文で保存されていた
- ヒントにそのまま書いてる人もいる「1〜6」とか
- Adobeのパスワードトップ10
- 123456が190万人とかとても信じられないものが並んでいる
- トップ10だけで全体の2%くらい。これが実態です
- JPドメインのIDに限ると、少し良くなる。数字の並びが多いのが日本の特徴
- Gawker, LinkedInなどを持ってきても傾向は同じ
- IDを入れると漏洩したか調べてくれるサービス
- 2013年意識調査
- 使い回している8割
- 強いパスワード3割くらい
- まとめると
- 現実として弱いパスワードが使われている
- 現実としてパスワードが使い回されている
- 弱いパスワードの例
- 他人にかんたんに推測される
- telepassword
- 総当たりで破られる
- GRC Brute Force Search Space Calculator
- 探索空間の広さを教えてくれる
- 過去に漏洩したものを使っている
- 2億4千万件の漏洩したパスワードを売っている
- 他人にかんたんに推測される
- どういう世界が理想?
- パスワードがダメだ
- パスワードだけじゃダメ → 2要素
- 使い回しできなければいいんだ → ID連携
- ユーザーの責任だ
- ユーザーがんばる/がんばらない × サイトがんばる/がんばらない
- 両方がんばらない方法: OSやブラウザががんばる?
- 論点
辻伸弘さん @ NTTデータ先端技術
- 「パスワードの破られ方入門」
- tsujileaks.com/ntsuji.pdf
- 自己紹介 @ntsuji
- 元侵入テスター → 攻撃側視点
- 普段はanonymousあたりの観察をしたり
- はじめに
- 定期変更なんてイヤだ!
- 攻撃手法いろいろ
- brute force攻撃
- 辞書攻撃、置きかえ(1→!、a→@など)
- reverse攻撃: 弱いパスワードを固定して多数のIDを試す
- リスト型攻撃: ID、パスワードの対をリストにして、使い回しを試す
- どこから入手する? → 盗む or 買う
- ツールあれこれ
- medusa, キングギドラ(?), ncrack
- デフォルトID/パスワード対のリスト
- routerpasswords.com など
- packetstorm, johntheripperなど
- 流行としては…
- 攻撃の流行りすたり
- 最近は→リスト型
- Adobeの漏洩では「adobe123」はリストにのっていない辞書にある単語のパスワード
- 高いリスト買わなくても、辞書攻撃でいけるのでは?
- 流行はあるものの、流行だけが危ないわけではない
- 辻さん: 攻撃者はとっても有利。ぼくらが「どうすんねん」と言ってる間にどんどん弱いところをついてくる。こういう状況がずっと続いている
- さいごに
- 対リスト型攻撃 → 使い回しをやめる
- 対brute forse → 質の高いパスワードをつける
- 自分を母親が使えるような技術を採用したい
徳丸浩さん @ HASHコンサルティング
- 「サイト運営者はパスワードリスト攻撃にどこまで責任があるのか」
- パスワードリスト攻撃とは
- 脆弱なサイトを攻撃して入手したパスワードリストで脆弱性のないサイトに入力してみると、一定の確率で入れる
- 社会実験をしてみる人が多数出てきて迷惑しているw
- 脆弱なサイトを攻撃して入手したパスワードリストで脆弱性のないサイトに入力してみると、一定の確率で入れる
- 背景にあるのはネットの「格差社会」
- 2005年ごろはほとんどのサイトが均等にぼろぼろだった
- 2008年ごろから、よくできてるサイトが目立ちはじめた(格差)
- 格差を利用して弱いところから抜いて強いところを攻めるようになってきた
- ユーザー間にも格差がある
- アカウントロック
- ログインID毎にパスワード間違いを記録し、連続してN回間違えた場合、X分アカウントを無効にする
- パスワード認証の保護機能の基本
- しかしジョーアカウント、githubへの弱いパスワード攻撃などには有効でない
- githubへの弱いパスワード攻撃
- ゆっくりと、異なるIPアドレスから5回だけ試し、もう来ない
- → 検出・ブロックが困難
- IPアドレス単位での認証ロックあるいは監視
- 2段階認証 & リスクベース認証
- サイト側負担が大きい
- ログイン履歴確認
- 防御はできないが気づきがあるかも
- パスワードの辞書チェック
- パスワード変更時に弱いものをはじく
- tw, g, fb, githubが使っている → これらのサイトはIDが公開だから?
- パスワード変更時に弱いものをはじく
- 辞書、リスト、フィッシング、MITBに対する防御は、利用者の責任管あるものをサイト側が救済しようとしている
- 本当にやらないといけないことは何か?
- 長いパスワードをつけられるようにしておく
- 1文字のパスワードをつけられたら、それは脆弱性? → ユーザー責任じゃねーの
- 本当にやらないといけないことは何か?
- パスワードリスト攻撃の登場人物
- おもらししたサイト
- 攻撃されたサイト
- 攻撃者
- 不正ログインされた利用者
- 1番目 → 攻撃者
- 2番目 → おもらししたサイト → わからないので出てこない
- ハッシュ、ソルト、ストレッチで守る責務がある
- 3番目 → 利用者: 使い回しをしていた責任
- 一番悪くないのは攻撃されたサイト。正直守りようがない
- でも利用者にも言い分が「ぼくパスワード認証使いたいとは言ってないもん!」
- まとめ
- パスワード認証のタテマエとして管理は利用者の責任という考え方がある
- でもそれ無理だよね。そもそもパスワード認証したいとか頼んでないし…
- サイト運営者の努力だけでは守り切れない面がある
パネル
- 楠さん Y! ID本部長
- 就任2日目で大規模な漏洩事件が
- 「パスワード認証」50年残っているIT技術はなかなかない
- 1965年passwdファイル公開の vulnerability 報告。来年が50周年
- 主旨
- 答を出すパネルではない
- インターネットにターゲット
- パスワードとはそもそも何か?
- 合言葉、クレデンシャル
- メリット・デメリット
- 意識と記憶が正常なら安定して出力可能
- 概ね人体(=本人)のみで完結
- 任意の使い分けが可能
- 記録・複製・伝搬が可能(=残念ながら自分の意志とは別に)
- 変更時は相手との同期が必要
- 根: 本音とタテマエのところで、使い回すのは悪いが、現実そういう人はいる。一方、パスワードはここ数年ではなくならない。そういう人を救うには極端な例でもいいからどういう方法があるか出してみてはいいのでは?
- 徳: 成立してはいなくてもそこそこ攻撃を受けているサイトさんで、ユーザーがITに強くない → 1回パスワードリセットしてみては? → それ攻撃を受けたみたいだからイヤだ → 全国一済パスワードリセットデーをやってみてはどうか(無理っぽい)
- 根: リセットしてもまた同じのつけるんじゃないかな
- 根: ユーザーにパスワードつけさせるのが悪いのでは?
- 徳: それはアリ
- 徳: パスワードを表示するので回りに見られる人がいないことを確認して表示ボタンを押せ → 根: 覚えられないですよね!
- 楠: パスワードどころかIDも忘れる人もいる。サイトの都合でやれ○文字だ、使い回すなと言われても困る
- 楠: ユーザーにとってパスワードや暗証番号っていつから使っているのか。コンシューマにとってのパスワードはいつから?
- 林: ダイヤル式鍵前が4桁
- 楠: 4桁をこえるとパスワードとは呼ばないのでは? 住基パスワードリセットに30分かかって終わらない事件もあった
- 楠: 4桁PINとパスワードは違うものとは認識していないのでは
- 根: トークンをみんなに配ってとか大変。パスワードマネージャは?
- 徳: トークンハンドリングを人手でやってるのがおかしいというのはそのとおり
- 楠: 銀行カードの番号は奥さんにも教えてる。しかしY!のパスワードは教えない
- 林: パスワードマネージャで言うと、googleにはパスワードっぽいところにランダム文字列を入力する機能をもっている
- 楠: パスワードマネージャは可逆暗号なのでドキドキする。キーチェーンもiCloudなのかローカルなのかわからないので、うっかりワイプしてしまうリスクがある
- 楠: ヨメさんに知られるのがイヤなだけで米政府に知られる分にはいい
- 徳: これがダメとか言い出すとどれもダメなんで
- 楠: 魂を売るのか問題になる
- 楠: 相矛盾している神話がある。使い回すな、定期変更しろ、同じの使うな、とか。無理ゲーを強いられている
- 辻: 毎回リセットしてる「なんちゃってワンタイムパスワード」をしてるとはいる「パスワードを覚えられない人はこちら」
- 毎回リセットは覚えられない人がいるほどはめんどくさくない
- 楠: パスワードリセットできない人は時々いる。「自分の誕生日を忘れました」という人がいる。ウソの情報でアカウント作って、後でリカバリーできなくなる
- 楠: Evernoteが何で全件リセットできたかというと、到達可能なメアドが割と新しかったということ
- 徳: ひみつの質問はなんとかなんないですか?
- 楠: もう少しかかります。しかしこれもトレードオフ
- 根: 事業者ごとの判断も難しい。ここまでやっとけばOKというのを作っておかないと、事業者コストがどんどん上がる。結局損をするのはユーザー
- 楠: 生体認証はリカバリできないので、パスワードを最後の手段として残してある。一番弱いものを使わざるを得ないのが難しい
- 辻: 攻撃側はローリスクでハイリターンが欲しいので、弱いところを狙うよね
- 林: インターネットで一番弱いところがあると全部弱くなってしまうというのはショックで、みんなで歩調を合わせていかないと。これは国をまたいで攻撃が来ちゃうので、議論を進めていきたい
- 根岸さん: 他から漏洩したときに自分も対処しないといけないので難しい。今後ウォッチし続けないといけないとすると、どうします?
- 楠さん: やや緊急避難的に今回は対応しました。同様のことがしょっちゅう起こってもらっては困る
- 楠: パスワードリスト攻撃、できることはある
- 辻: 本当は攻撃したやつが教えてくれたら一番セキュアだが、それは無理
- 辻: パスワードのつけ方とか、学校の教科書にはとてもいいことが書いてある。草の根的に「今日お母さんに教えてね」ってやらないと、我々では限界
- 根: みんなでやっていかないといけない部分がある
- 徳: カンタンログインはたたきつぶす立場なのですが、UI的にはよくできている。パスワードなくしたというのが大きいと思う。カンタンログインは技術的に残念なところがあったが、良くしていけばいい。アプリ認証が万全というわけではないが普及していけばいいと思う
- 根: ID連携に乗ったらみんな幸せなのか。懐疑的なんですが
- 楠さん: ID連携みんなしたいのか。事業の根幹であるユーザーリストを預けてこっちがお金を払うとかあり得ないでしょ。twやfbがうまくいったのは書き込みしたいから。そういうはっきりした価値を示さないとフェデレーションは進まない。事業者都合やユーザーがパスワード覚えたくないだろうというだけで押そうとすると、MS Passportの失敗から学んでいないだろうと思う
- 辻: どうでもいいところだけ連携するのはどう?
- 林: そういう目的でgmailアカウント取っている人はいる。意識的にせよ無意識的にせよやっている人はいる
- 徳: 自前のパスワードつけるところには税金をかけるのはどうか
- 楠: 海外にサーバー置くだけではないか
- 林: 日本のIDって価値が上がっていると思いませんか? 日本語フィッシングメールの日本語がだんだん良くなっていますよね
- 楠: 言語バリアに守られていたが、そのコストを無視するようなメリットがフィッシングに出てきたということだろう
- 根: 格差ということにはドキッとした。これだけの対策ができるのは大手だけだよなあ、救わなきゃいけないユーザーもできてない人達なので
- 楠さん: bitcoinマイナーのASICを使うと10^18 hash/sec行けてしまう。そのへんの危機感が共有されていない
- 根岸さん: 攻撃側、解析側の能力向上がサイト運営者に伝わっていない感がある
- 徳: 徳丸本でストレッチを書いたけど、レビューアにも抵抗があったようだ。書いといてよかったー
- 根: いまはストレッチ5000、1万なんてのが普通なんですが、そういうことがわかっていない
- 楠: パスワードマネージャが流行ったとたんにPMのふりしたマルウェアが出たりすると手に負えない
- 根: PM使うとひとつのパスワードで全部やられちゃう。そういうリスクが評価できるのか。専門家しかできないだろ
- 徳: (Y!さんの)ひみつの質問と答に関する確約をいただけたのが個人的にうれしい。リセットが安全になればパスワード管理の手間が助かるなあと
- 辻: 「パスワード覚えられない人はこちら」を生みだせたのが今日の収穫w 使えない人が追いてけぼりを食ってしまうものだけは、なくしていきたい。それがITかな、セキュリティーかな、と思っている
- 根: 普段は専門家としての立場から見ているけど、パスワードというのが使いにくい世間になってきている。うまい落としどころをさがしていく、答はないけどみんなでさぐっていくのが大事と思った
- 楠: おととしの秋くらいから兆候があった。十数年やってきたパスワード管理のバランスが変わってきてしまった。過去からの経緯でこうなっているが、道具がそろっているのに惰性で続けてきたことが怪しくなってきている。これまでぼくらはわかっていながら何をやってこなかったかをよく振り返ってみたい
ジェネラルパネル: ビッグデータの可能性と現実
- 参加者
- モデレータ: 佐々木さん
- パネリスト
- 喜蓮川さん: NII所長
- 板倉さん: 弁護士
- 吉井さん: SBテレコム
- 喜蓮川さん
- 吉井さん
- 板倉さん
- 半導体でかつて勝っていた → 負けた
- Social Machines
- 佐々木さん: 何を突破すれば次のステップに進めるのか。今後のビジネスの突破口は?
- 喜蓮川さん: 人間の行動と IoTをfusionする
- 佐々木さん: チャネルになっていればいいが、レイヤーだとどのレイヤーかわからない
- 喜蓮川さん: データは国の財産だ。なにかというと「cool」に行ってしまう風潮はどうかと思う
- 佐々木さん: コンテンツより流通構造が重要なはず
- 吉井さん: bigdataやりたいが社内でも止めたがる
- 名寄せしたい ← やめなはれ
- privacy commissioner を置いてほしい
- こういう使い方をしたいですよ、と見せると、OKとかNGとか言ってほしい
- 気持ち悪さだけで話してほしくない
- 佐々木さん: 顔認識カメラ実験 → 法的には問題ないのにキモチワルさで怒る人が多い
- 板倉さん: 個人情報保護法でもそうだが、合意は無敵。一方で小さい字で書いて押させる流れは自爆的
- 本人にリーチできるんだから、ちゃんと説明し、後からこんなことしてたとは知らなかったと言わせないようにする透明性が必要
- わかんない、言わないでやった → キモチワルイの元
- クリックさせればいい、ではなく、わかってもらうことが大事。UIデザインも重要
- 佐々木さん: 医療学会では症例が出てみんなで学ぶ・共有することが求められている
- 個人情報は削除するが、共有が前提である。一方で難病になるほど名寄せされやすく、共有が必要なのに難しくなる
- 喜蓮川さん: オープンガバメント、オープンデータ
- 「この人には開示する」をどうコントロールするかという問題。
- 枠組をちゃんとつくるのが、少なくともヘルスケアには大事
- 板倉さん: 日本は相当厳密な手続きで開示している。医療は別途法律をとりまとめるとして話が進まないままになっている
- 包括して検討するには、やはりケースを持ってきてもらうしかない
- 喜蓮川さん: IDとか公開していいものはもっとあるはずだ
- 名寄せしないことにはビジネスは進まないよね
- 吉井さん: 公共権という考え方がある。
- 佐々木さん: BT LEではペアリングなしでつながる。iPhone持って店に入るとすぐわかるようになる
- 佐々木さん: プライバシー法制度の問題とキモチワルさの問題、これは構造的になんとかなるのではないか
- 喜蓮川さん: マナー、は拘束力がないので、やってもしょーがないという許容範囲を考えたい
- しかしPasmoの乗車履歴のような情報は、人が殺められる可能性まである。これは規制したい
- 自分が言ったことで起こりますというと、誰もせめられない
- こういう世の中になったんですよ、説明していくしかない
- → 教育の問題として考えるべき
- 吉井さん: 技術的に言うと日本人の平均的なプログラミング能力は高くない
- その教育によってITの仕組みや名寄せのタイミングなどが理解できるようになるだろう
- 板倉さん: バカッターはデータ保護法制で救うべき範囲ではない
- 喜蓮川さん: 教科情報が大学入試にとりあげられていない
- 「大学入試に出ない科目をどうして勉強するのか」と言われるとぐぅ…となってしまう
