セキュリティの都市伝説を暴く
•
101 likes•88,306 views
イベント名: セキュリティとUXの◯◯な関係 講演タイトル: セキュリティの都市伝説を暴く 2017年6月9日 ヤフー株式会社 コワーキングスペース LODGE https://connpass.com/event/55559/
![[BurpSuiteJapan]HTTP基礎入門](https://cdn.slidesharecdn.com/ss_thumbnails/http-170529011332-thumbnail.jpg?width=560&fit=bounds)
![[BurpSuiteJapan]Burp Suite実践編](https://cdn.slidesharecdn.com/ss_thumbnails/burpsuite-170529011632-thumbnail.jpg?width=560&fit=bounds)
More Related Content
What's hot (20)
Similar to セキュリティの都市伝説を暴く (20)
More from Hiroshi Tokumaru (20)
Recently uploaded (9)
![ElasticsearchでSPLADEする [Search Engineering Tech Talk 2025 Winter]](https://cdn.slidesharecdn.com/ss_thumbnails/searchtech-250228102455-ddc5ce09-thumbnail.jpg?width=560&fit=bounds)
セキュリティの都市伝説を暴く
- 2. アジェンダ • セキュリティの都市伝説とは • セキュリティの都市伝説さまざま – パスワードのマスク表示 – IDまたはパスワードが違います – パスワードの有効期間 – autocompleteの停止 – 戻るボタンの問題 • まとめ 2
- 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
- 5. セキュリティ対策の都市伝説…とは • セキュリティのために「不便」を強いられることは ありませんか? – パスワードのマスク表示 – ユーザIDまたはパスワードが違います – パスワードの有効期間 – autocompleteの禁止 – 戻るボタンの禁止 – … • それで本当に安全になるの? • 今日はそれを考えてみます 5
- 8. マスク表示は何のため? • そりゃ、背後に人がいたら覗かれるじゃないですか • でも、背後に人がいないケースもあるよね – 周囲に人がいない職場 – 一人住まいの自宅 – … • 長く複雑なパスワードをつけた場合、確認したい場 合もあるよね 8
- 10. 隠すことによるコスト 我々のモバイル機器のテストで、パスワードを隠すことは、ユーザビリティ上、特 に厄介な問題であることが判明している。モバイル機器は入力が難しいため、打ち 間違いがよくあるからである。しかし、この問題はデスクトップパソコンのユーザ にも起こっている。 ユーザがパスワードを入力するのを難しくすることで、あなたは2つの問題を作り出 してしまうが、そのうちの1つは実際にセキュリティを脅かす： • ユーザは、記入時に自分が何を入力しているか見ることができないとより多くの ミスをする。したがって、そのとき彼らは自分の入力により自信が持てなくなる。 ユーザエクスペリエンスに関するこの2つの悪化要因によって、ユーザは入力を あきらめ、あなたのサイトにログインすることをやめてしまう可能性が高い。こ のことは、結果としてビジネス機会の喪失を引き起こす（あるいは、イントラ ネットの場合はサポートコールの増加をもたらす）。 • ユーザは、パスワードの打ち込みに確信が持てなければ持てないほど、（a）シ ンプル過ぎるパスワードを使おうとし、また、（b）彼らのコンピュータ上の ファイルからパスワードをコピー＆ペーストしようとしがちである。この2つの 行動は結果的に真にセキュリティを損なう。 10 原文 https://www.nngroup.com/articles/stop-password-masking/ 日本語訳 https://u-site.jp/alertbox/20090623_passwords
- 11. IEのパスワード表示ボタン 11
- 12. まとめ • パスワード入力欄をマスク表示するのは都市伝説で はなく定説だが、つねに最適とは限らない • IEの「パスワード表示ボタン」を徳丸は評価するの で、追随するブラウザが現れないのは残念 • 「パスワード表示ボタン」をアプリケーション側で 独自実装するのは危険が伴う 12
- 16. ユーザ名とパスワードのどちらが間違いか判らない • ユーザ名とパスワードのどちらを間違えたのか分か らないのは不便 • ユーザ名が分かる場合でもやっているのはなぜ? – twitter – はてな – … • 意味なくやっている場合もあるのでは? 16
- 25. みずほダイレクト 25
- 26. 26 ゆうちょ銀行
- 27. りそな銀行 27
- 28. なぜIDとパスワードを別々に入力するか? • 以下の理由が推測される – フィッシング対策 – 利便性をあげることで、強いパスワードをつけてもらい やすくする（パスワード表示ボタンと同じ動機） • IDとパスワードを別々に攻撃されてもいいのか? – それはそれで対策する – アカウントロックとか – オンラインバンキングでは2要素認証が一般化しつつある • オンラインバンキング等は、フィッシングやマル ウェア感染される前提の対策に移行しつつある 28
- 30. まとめ • ログイン時にIDとパスワードのどちらが間違いかを 「わからないように」表示するのは都市伝説ではな く定説だが… • 最近見直しされつつある • ログインIDが公開されているサイトでは、そもそも 効果が望めない • ログインしにくいことによるデメリットもあるので、 他のコントロールがあれば、IDとパスワードを別々 に入力する仕様もあり得る 30
- 31. パスワードの有効期間 31
- 32. パスワードの有効期間とは? • パスワードに「有効期間」をもうけ、パスワードを 一定期間毎にユーザーに強制的に変更させる機能 • Windowsには設定の機能がありますね • ウェブサイトにも同様の機能があるものも… 32 厳重な本人確認 • サービスご利用の際には、パスワードなどにより契約者ご本人 さまであることを確認しています。 • パスワードなどを複数回誤って入力された場合、サービスのご 利用を一時停止いたします。 • パスワードには有効期間を設定しています。 セキュリティ｜中京銀行 https://www.chukyo-bank.co.jp/corporation/improve_efficiency/foreign_exchange/security/
- 35. IPAの文書にパスワードの定期的変更の勧め (a)パスワード作成のポイント オークション等のサービスの提供元によっては、使える文字の種類や桁数に制限 がありますが、（2）の表1-1を参考にして使える文字の種類はできるだけ多く使い、 原則8桁以上を設定するようにしてください。 ・定期的に変更する 強い（破られにくい）パスワードであると思っていても、長期間利用していると 漏えいする危険がありますので、定期的に（例えば毎月）変更することを強くお勧 めします。 なお、定期的に変更する際、2種類のパスワードを交互に使用することは、変更する 意味をなくしますので行わないでください。 35 (b)パスワード管理に関するポイント ・パスワードの保管について 長く複雑なパスワードを作成すると、記憶するのは大変で す。この場合、紙にメモしても構いませんが、ID とパス ワードは別々に保管することをお勧めします。仮にパスワー ドが知られたとしても、どの ID に対応するパスワードなの かがわからなければ意味がありません。 http://www.ipa.go.jp/security/txt/2008/10outline.html より引用
- 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
- 39. パスワードの定期的変更にまつわる誤解 • パスワードの定期的変更論争w • パスワードを定期的に変更すると、不正ログインを 防ぐ or 緩和できる…というのは誤解 • パスワードの定期的変更の効果は下記 – パスワードを変更すると、漏洩したパスワードを無効化 できる – パスワードを定期的に変更すると、漏れているかもしれ ないパスワードを無効化できる • パスワードを変更しなければ永遠に漏洩し続けるが、 パスワードを6ヶ月に一度変更すると、最長でも6ヶ 月で漏洩は止まる 39
- 40. まとめ • パスワードの定期的変更にまつわる論争がある – まさに「都市伝説」にふさわしい • パスワードの定期的変更の効果は、しばしば誤解さ れている – 過剰な期待がある • 意識高い人が自主的にパスワードを定期的に変更す るのは勝手にやればよいが、サイト側で強制するの は推奨されない 40
- 42. autocomplete とは • ブラウザの機能で、入力フォームの入力値を補間し てくれる機能 • パスワード入力欄については、サイト毎にパスワー ドをブラウザが記憶し、次回以降に自動入力してく れる • 伝統的に、パスワードのautocompleteが有効だと、 脆弱性診断の際に指摘されてきた 42
- 43. なぜ autocomplete=on は脆弱性とされたか? • パスワードはね、記録とかせずに頭で覚えるもので すよ…という伝統的な考え方 • ウイルスで漏洩するリスク • XSSとの組み合わせで漏洩するリスク • 離席中にみられたらまずいじゃないですか! 43
- 44. 最近は autocomplete は指摘しない…はず • 確かに autocomplete にはリスクもあるが、メリットもある • いくつのウェブサイトにパスワードを保存していますか? すべて覚えきれますか? 44https://www.ipa.go.jp/security/keihatsu/munekyun-pw/slideshow/index.html より引用
- 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
- 48. 「戻るボタン」の問題 48
- 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. なぜ「戻る」を禁止するのか? (1) • セッション管理との相性説 • 処理が進むに従って、セッション変数の内容は追記 され、状態が変化する • ブラウザ機能で「戻る」と、画面は戻るが、セッ ション変数の中身は変わらないので、不整合が生じ る 50 画面 セッション
- 53. 実装はどうなっているか? 53 POST リダイレクト POST リダイレクト オンラインバンキングはPOSTがお好き 見えないページ • オンラインバンキングは、入力フォーム項目のない単純な遷移 でもPOSTリクエストで遷移するものがある • 「見えるページ」は必ず「見えないページ」からのリダイレクトで 遷移 • 見えないページ以外からの直接遷移はエラー（攻撃?）として、 ログアウトしている模様
- 54. そこまでする必要ある? • 反射型XSS（罠を使うタイプのXSS）を防げるとい うのは一定のメリットだが… – オンラインバンキングの場合、自由入力欄とかあまりな いのだから、普通にXSS対策でよくない? – 「バリデーション」もしやすいわけで… • CSRF対策する必要があるページ（更新、振込等） は今のままでよい • ちと過剰だとは思うものの、オンラインバンキング を想定すると「絶対にしなくていい」とも言いにく い • ただし、ジャパンネット銀行などは「戻る」有効な ので、考え方次第かと 54
- 55. 全体のまとめ • セキュリティ対策の「都市伝説」は本当にある • 効果のあるものもあるが、効果の怪しいものも • ブラウザやウェブサーバー、規格等の変化に伴い、 過去には効果のあった「対策」が、あまり意味のな いものになるケースもある • 「保険的な対策」にはメリットだけでなくデメリッ トがあるものもある。時代により、メリットとデメ リットのバランスが変わり、推奨されなくなるもの もある • そのセキュリティ施策、本当に効果があるか、よく 考えよう 55