セキュリティの都市伝説を暴く

セキュリティの都市伝説を暴く

1. 1. セキュリティ対策の都市伝説を暴く EGセキュアソリューションズ株式会社 徳丸 浩
2. 2. アジェンダ • セキュリティの都市伝説とは • セキュリティの都市伝説さまざま – パスワードのマスク表示 – IDまたはパスワードが違います – パスワードの有効期間 – autocompleteの停止 – 戻るボタンの問題 • まとめ 2
3. 3. 徳丸浩の自己紹介 • 経歴 – 1985年 京セラ株式会社入社 – 1995年 京セラコミュニケーションシステム株式会社(KCCS)に出向・転籍 – 2008年 KCCS退職、HASHコンサルティング株式会社(現社名:EGセキュアソリューションズ株式会 社)設立 • 経験したこと – 京セラ入社当時はCAD、計算幾何学、数値シミュレーションなどを担当 – その後、企業向けパッケージソフトの企画・開発・事業化を担当 – 1999年から、携帯電話向けインフラ、プラットフォームの企画・開発を担当 Webアプリケーションのセキュリティ問題に直面、研究、社内展開、寄稿などを開始 – 2004年にKCCS社内ベンチャーとしてWebアプリケーションセキュリティ事業を立ち上げ • 現在 – EGセキュアソリューションズ株式会社 代表 https://www.eg-secure.co.jp/ – 独立行政法人情報処理推進機構 非常勤研究員 https://www.ipa.go.jp/security/ – 著書「体系的に学ぶ 安全なWebアプリケーションの作り方」(2011年3月) 「徳丸浩のWebセキュリティ教室 」(2015年10月) – 技術士（情報工学部門） 3
4. 4. セキュリティ対策の都市伝説…と は何か? 4
5. 5. セキュリティ対策の都市伝説…とは • セキュリティのために「不便」を強いられることは ありませんか? – パスワードのマスク表示 – ユーザIDまたはパスワードが違います – パスワードの有効期間 – autocompleteの禁止 – 戻るボタンの禁止 – … • それで本当に安全になるの? • 今日はそれを考えてみます 5
6. 6. パスワードのマスク表示 6
7. 7. パスワードのマスク表示とは? 7 これです
8. 8. マスク表示は何のため? • そりゃ、背後に人がいたら覗かれるじゃないですか • でも、背後に人がいないケースもあるよね – 周囲に人がいない職場 – 一人住まいの自宅 – … • 長く複雑なパスワードをつけた場合、確認したい場 合もあるよね 8
9. 9. パスワードを隠すのをやめよう ユーザがパスワードを打ち込んでも、黒い点の列でしかフィードバックが返ってこ ないとき、ユーザビリティは損なわれている。パスワードを隠したからといって、 セキュリティは強化されないことが多く、逆に、ログインの失敗によって、あなた のビジネスに悪影響を及ぼす。 ユーザがパスワードを打ち込んでいるとき、ほとんどのパスワードをはっきりとテ キストで示すべき時期が来ている。フィードバックを提供し、システムの状態を視 覚化することは、常にもっとも基本的なユーザビリティの原則の１つである。ユー ザが複雑な暗号を入力している間、どれも同じ形の黒い点を見せるというのは、間 違いなくその原則に違反している。 ほとんどのウェブサイトは（そして多くのアプリケーションでも）ユーザがパス ワードを入力している最中、パスワードを隠してしまう。そして、それによって、 理論的には、不心得者がユーザのパスワードを覗き込むことを防ぐことになってい る。しかし、言うまでもなく、本当にスキルのある犯罪者は、キーボードを見るだ けでどのキーが押されているかわかる｡つまり、パスワードを隠すことはパスワード を嗅ぎ周る相手からの十分な防御には全くならないのである。 さらに重要なことには、あなたがウェブサイトにログインするとき、たいていの場 合、そこには覗き込む人など誰もいない。その場にいるのはあなただけで、オフィ スにたった一人で座っているのに、心配する必要のないものからの防御のために ユーザビリティを犠牲にして不便を被っているというわけだ。 9 原文 https://www.nngroup.com/articles/stop-password-masking/ 日本語訳 https://u-site.jp/alertbox/20090623_passwords
10. 10. 隠すことによるコスト 我々のモバイル機器のテストで、パスワードを隠すことは、ユーザビリティ上、特 に厄介な問題であることが判明している。モバイル機器は入力が難しいため、打ち 間違いがよくあるからである。しかし、この問題はデスクトップパソコンのユーザ にも起こっている。 ユーザがパスワードを入力するのを難しくすることで、あなたは2つの問題を作り出 してしまうが、そのうちの1つは実際にセキュリティを脅かす： • ユーザは、記入時に自分が何を入力しているか見ることができないとより多くの ミスをする。したがって、そのとき彼らは自分の入力により自信が持てなくなる。 ユーザエクスペリエンスに関するこの2つの悪化要因によって、ユーザは入力を あきらめ、あなたのサイトにログインすることをやめてしまう可能性が高い。こ のことは、結果としてビジネス機会の喪失を引き起こす（あるいは、イントラ ネットの場合はサポートコールの増加をもたらす）。 • ユーザは、パスワードの打ち込みに確信が持てなければ持てないほど、（a）シ ンプル過ぎるパスワードを使おうとし、また、（b）彼らのコンピュータ上の ファイルからパスワードをコピー＆ペーストしようとしがちである。この2つの 行動は結果的に真にセキュリティを損なう。 10 原文 https://www.nngroup.com/articles/stop-password-masking/ 日本語訳 https://u-site.jp/alertbox/20090623_passwords
11. 11. IEのパスワード表示ボタン 11
12. 12. まとめ • パスワード入力欄をマスク表示するのは都市伝説で はなく定説だが、つねに最適とは限らない • IEの「パスワード表示ボタン」を徳丸は評価するの で、追随するブラウザが現れないのは残念 • 「パスワード表示ボタン」をアプリケーション側で 独自実装するのは危険が伴う 12
13. 13. IDまたはパスワードが違います 13
14. 14. 認証エラー時のメッセージ 14 これです
15. 15. 従来の説明 15安全なWebアプリケーションの作り方 P339より引用
16. 16. ユーザ名とパスワードのどちらが間違いか判らない • ユーザ名とパスワードのどちらを間違えたのか分か らないのは不便 • ユーザ名が分かる場合でもやっているのはなぜ? – twitter – はてな – … • 意味なくやっている場合もあるのでは? 16
17. 17. 最近の Googleのログイン画面 (1) 17
18. 18. 最近の Googleのログイン画面 (2) 18
19. 19. 最近の Googleのログイン画面 (3) 19
20. 20. 最近の Googleのログイン画面 (4) 20
21. 21. 最近の Googleのログイン画面 (5) 21
22. 22. 最近の Googleのログイン画面 (6) 22
23. 23. 最近の Googleのログイン画面 (7) 23
24. 24. 最近の Googleのログイン画面 (8) 24
25. 25. みずほダイレクト 25
26. 26. 26 ゆうちょ銀行
27. 27. りそな銀行 27
28. 28. なぜIDとパスワードを別々に入力するか? • 以下の理由が推測される – フィッシング対策 – 利便性をあげることで、強いパスワードをつけてもらい やすくする（パスワード表示ボタンと同じ動機） • IDとパスワードを別々に攻撃されてもいいのか? – それはそれで対策する – アカウントロックとか – オンラインバンキングでは2要素認証が一般化しつつある • オンラインバンキング等は、フィッシングやマル ウェア感染される前提の対策に移行しつつある 28
29. 29. みずほ銀行のトランザクション署名 29 口座番号を入力 してOKを押す 8桁トークンをWeb フォーム側に入力 ③を押す 13769297
30. 30. まとめ • ログイン時にIDとパスワードのどちらが間違いかを 「わからないように」表示するのは都市伝説ではな く定説だが… • 最近見直しされつつある • ログインIDが公開されているサイトでは、そもそも 効果が望めない • ログインしにくいことによるデメリットもあるので、 他のコントロールがあれば、IDとパスワードを別々 に入力する仕様もあり得る 30
31. 31. パスワードの有効期間 31
32. 32. パスワードの有効期間とは? • パスワードに「有効期間」をもうけ、パスワードを 一定期間毎にユーザーに強制的に変更させる機能 • Windowsには設定の機能がありますね • ウェブサイトにも同様の機能があるものも… 32 厳重な本人確認 • サービスご利用の際には、パスワードなどにより契約者ご本人 さまであることを確認しています。 • パスワードなどを複数回誤って入力された場合、サービスのご 利用を一時停止いたします。 • パスワードには有効期間を設定しています。 セキュリティ｜中京銀行 https://www.chukyo-bank.co.jp/corporation/improve_efficiency/foreign_exchange/security/
33. 33. オンラインクラックとオフラインクラックをごっちゃにした記事の例 33 http://www.itmedia.co.jp/enterprise/articles/1012/07/news010_2.html より引用 これはオフラインクラック を想定している これはオンラインクラックの文脈 だが、1秒間に1000万回は無理
34. 34. よく引用・参照されるIPAの資料から… 34http://www.ipa.go.jp/security/txt/2008/10outline.html より引用 (2)強いパスワードとは オークション等のサービスを提供するウェブサイトでは、パスワードを作成する際、「英 字、数字、記号をランダムに組み合わせて、8文字以上にしましょう」という注意事項が記 載されているケースがよくあります。これは強い（破られにくい）パスワードを作成するポ イントとなります。
35. 35. IPAの文書にパスワードの定期的変更の勧め (a)パスワード作成のポイント オークション等のサービスの提供元によっては、使える文字の種類や桁数に制限 がありますが、（2）の表1-1を参考にして使える文字の種類はできるだけ多く使い、 原則8桁以上を設定するようにしてください。 ・定期的に変更する 強い（破られにくい）パスワードであると思っていても、長期間利用していると 漏えいする危険がありますので、定期的に（例えば毎月）変更することを強くお勧 めします。 なお、定期的に変更する際、2種類のパスワードを交互に使用することは、変更する 意味をなくしますので行わないでください。 35 (b)パスワード管理に関するポイント ・パスワードの保管について 長く複雑なパスワードを作成すると、記憶するのは大変で す。この場合、紙にメモしても構いませんが、ID とパス ワードは別々に保管することをお勧めします。仮にパスワー ドが知られたとしても、どの ID に対応するパスワードなの かがわからなければ意味がありません。 http://www.ipa.go.jp/security/txt/2008/10outline.html より引用
36. 36. よく引用・参照されるIPAの資料から… 36http://www.ipa.go.jp/security/txt/2008/10outline.html より引用 (2)強いパスワードとは オークション等のサービスを提供するウェブサイトでは、パスワードを作成する際、「英 字、数字、記号をランダムに組み合わせて、8文字以上にしましょう」という注意事項が記 載されているケースがよくあります。これは強い（破られにくい）パスワードを作成するポ イントとなります。 これに注目
37. 37. 記号混じり6桁のパスワードを54日で総当りするには… • 93種の文字6桁のパスワードの総数 93 ^ 6 = 646,990,183,449 (約6470億通り) • これを54日で総当りする秒間試行回数は 646,990,183,449 ÷ (54 * 24 * 60 * 60) = 138,672 試行/秒 • ということで、約14万試行/秒 が必要だが…通常の ウェブサイトでは、そんなに高速に試行できない • PCの高速化でパスワード試行も速くなる…というの は誤解で、ウェブサイト側の性能による 37
38. 38. 「パスワードは定期的に変更してはいけない」--米政府 2017年5月23日（火）15時00分 AJ・デリンジャー ＜アメリカの電子認証専門機関が、定期的なパスワード変更の推奨をやめ ると決めた。エンドユーザーもいずれ、代わりの新しい「パスフレーズ」 を要求されるようになるはすだ＞ 米政府機関はもう、パスワードを定期的に変えるのを推奨しない。アメリ カの企画標準化団体、米国立標準技術研究所（NIST）が発行する『電子認 証に関するガイドライン』の新版からルールを変更する。 ウェブサイトやウェブサービスにも、サイトが乗っ取られたのでもない限 り、「パスワードが長期間変更されていません」などの警告を定期的に表 示するのを止めるよう勧告するという。銀行や病院のように人に知られて はいけない個人情報を扱う機関も同じだという。 実は近年、情報セキュリティー専門家の間でも、特別の理由がない限り、 ユーザーにパスワード変更を求めるべきではないという考え方が増えてき た。なぜなら、ユーザーは新しいパスワードをいい加減に作る傾向がある からだ。どうせ数カ月後に変更を求められると思えばなおさらだ。 38http://www.newsweekjapan.jp/stories/world/2017/05/-----2.php より引用
39. 39. パスワードの定期的変更にまつわる誤解 • パスワードの定期的変更論争w • パスワードを定期的に変更すると、不正ログインを 防ぐ or 緩和できる…というのは誤解 • パスワードの定期的変更の効果は下記 – パスワードを変更すると、漏洩したパスワードを無効化 できる – パスワードを定期的に変更すると、漏れているかもしれ ないパスワードを無効化できる • パスワードを変更しなければ永遠に漏洩し続けるが、 パスワードを6ヶ月に一度変更すると、最長でも6ヶ 月で漏洩は止まる 39
40. 40. まとめ • パスワードの定期的変更にまつわる論争がある – まさに「都市伝説」にふさわしい • パスワードの定期的変更の効果は、しばしば誤解さ れている – 過剰な期待がある • 意識高い人が自主的にパスワードを定期的に変更す るのは勝手にやればよいが、サイト側で強制するの は推奨されない 40
41. 41. autocompleteの停止 41
42. 42. autocomplete とは • ブラウザの機能で、入力フォームの入力値を補間し てくれる機能 • パスワード入力欄については、サイト毎にパスワー ドをブラウザが記憶し、次回以降に自動入力してく れる • 伝統的に、パスワードのautocompleteが有効だと、 脆弱性診断の際に指摘されてきた 42
43. 43. なぜ autocomplete=on は脆弱性とされたか? • パスワードはね、記録とかせずに頭で覚えるもので すよ…という伝統的な考え方 • ウイルスで漏洩するリスク • XSSとの組み合わせで漏洩するリスク • 離席中にみられたらまずいじゃないですか! 43
44. 44. 最近は autocomplete は指摘しない…はず • 確かに autocomplete にはリスクもあるが、メリットもある • いくつのウェブサイトにパスワードを保存していますか? すべて覚えきれますか? 44https://www.ipa.go.jp/security/keihatsu/munekyun-pw/slideshow/index.html より引用
45. 45. 最近のブラウザは autocomplete=offにできない • As of Internet Explorer 11, the autocomplete property is no longer supported for input type=password fields. https://msdn.microsoft.com/library/ms533486.aspx • As we’ve previously discussed, Chrome will now offer to remember and fill password fields in the presence of autocomplete=off. (Chrome 34以降) https://chromereleases.googleblog.com/2014/04/stable- channel-update.html • <form autocomplete=“off”> no longer prevents passwords from being saved (Firefox 30以降) https://www.fxsitecompat.com/en-CA/versions/30/ • 今でも一部の脆弱性診断業者は、autocomplete=onを指摘す るが… 45
46. 46. 公開された脆弱性診断報告書サンプルの例 46http://www.gax.jp/sec/report_sample_01.pdf より引用
47. 47. まとめ • セキュリティのため、autocomple=offにせよという 伝説があった • ブラウザの進化により、本当に伝説になった 47
48. 48. 「戻るボタン」の問題 48
49. 49. 「セキュリティ上の理由から」戻るボタンを禁止しているサイトがある • JavaScriptでブラウザの「戻る」機能を禁止しているサイトは多い – だが、多くの場合、キーボード操作等で戻れてしまう • もっと積極的に、サーバー側で「戻る」を検知し、エラーにしているサ イトもある – オンラインバンキングに多い 49 Q: ログイン中に、「戻る」「進む」ボタンで操作を行うと、エラーが表示されてしまいます A: 他者からの悪用を防止するため、マイゲートは「戻る」ボタンや「進む」ボタンがクリックさ れると、エラーが表示され、自動的にログアウトします。 エラーが表示された場合は、再 度ログインすることでご利用いただけます。 http://faqresona.resona-gr.co.jp/faq/show/155 Q: 『お客さまの安全のため、お取引を中断させていただきました。』といったメッセージが 表示され、操作が中断されました。 A: 以下の対応をご検討ください。 １ ゆうちょダイレクト画面上のボタンで操作する ブラウザの「戻る」または「進む」ボタンを使用した場合、お手続きが中断され、改めてロ グインが必要となりますので、ご注意ください。 http://direct-faq.jp-bank.japanpost.jp/faq/show/93
50. 50. なぜ「戻る」を禁止するのか? (1) • セッション管理との相性説 • 処理が進むに従って、セッション変数の内容は追記 され、状態が変化する • ブラウザ機能で「戻る」と、画面は戻るが、セッ ション変数の中身は変わらないので、不整合が生じ る 50 画面 セッション
51. 51. なぜ「戻る」を禁止するのか? (1) • セッション管理との相性説（続き） 51 画面 セッション 画面 セッション
52. 52. なぜ「戻る」を禁止するのか? (2) 52 正規の画面遷移 罠の ページ 正規の画面遷移 XSS CSRF 元々「戻る」を禁止する意図は なかったが、画面遷移を「ガチ ガチ」に制限した結果、副作用 として戻るが禁止された…説 「横入り」防止説
53. 53. 実装はどうなっているか? 53 POST リダイレクト POST リダイレクト オンラインバンキングはPOSTがお好き 見えないページ • オンラインバンキングは、入力フォーム項目のない単純な遷移 でもPOSTリクエストで遷移するものがある • 「見えるページ」は必ず「見えないページ」からのリダイレクトで 遷移 • 見えないページ以外からの直接遷移はエラー（攻撃?）として、 ログアウトしている模様
54. 54. そこまでする必要ある? • 反射型XSS（罠を使うタイプのXSS）を防げるとい うのは一定のメリットだが… – オンラインバンキングの場合、自由入力欄とかあまりな いのだから、普通にXSS対策でよくない? – 「バリデーション」もしやすいわけで… • CSRF対策する必要があるページ（更新、振込等） は今のままでよい • ちと過剰だとは思うものの、オンラインバンキング を想定すると「絶対にしなくていい」とも言いにく い • ただし、ジャパンネット銀行などは「戻る」有効な ので、考え方次第かと 54
55. 55. 全体のまとめ • セキュリティ対策の「都市伝説」は本当にある • 効果のあるものもあるが、効果の怪しいものも • ブラウザやウェブサーバー、規格等の変化に伴い、 過去には効果のあった「対策」が、あまり意味のな いものになるケースもある • 「保険的な対策」にはメリットだけでなくデメリッ トがあるものもある。時代により、メリットとデメ リットのバランスが変わり、推奨されなくなるもの もある • そのセキュリティ施策、本当に効果があるか、よく 考えよう 55
56. 56. アンケートにご協力ください https://goo.gl/JGpnHF