いまさら聞けないパスワードの取り扱い方
•
135 recomendaciones•56,998 vistas
OWASP Japan 7th Chapter Meeting
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Destacado
Destacado (20)
Similar a いまさら聞けないパスワードの取り扱い方
Similar a いまさら聞けないパスワードの取り扱い方 (20)
Más de Hiroshi Tokumaru
Más de Hiroshi Tokumaru (20)
Último
Último (8)
いまさら聞けないパスワードの取り扱い方
- 2. 本日お話ししたいこと • パスワードの器の要件 • パスワードの中身の要件 • パスワード入力画面の要件 • 認証エラーメッセージの要件 • パスワードの保存方法 2Copyright © 2013 HASH Consulting Corp.
- 3. パスワードの器の要件 3https://direct3.smbc.co.jp/servlet/com.smbc.SUPRedirectServlet 半角英数字4桁～8桁 英字4桁で 大丈夫か?
- 4. SMBCダイレクトはアカウント回復に手間をかけることで対応? 4Copyright © 2013 HASH Consulting Corp. http://www.smbc.co.jp/kojin/otetsuduki/anshou/saihakko/index.html • SMBCはアカウントロック後のアカウント回復を書面あるいは電話とする ことで、オンラインのパスワード攻撃に対策していると考えられる。 • 自動的にアカウント回復するサービスの場合は、パスワードの要件を厳し くすることで、オンラインパスワード試行に対抗した方がよい • twitterの場合は6文字以上、任意のASCII文字 • 英数字に限る場合は 8 文字以上を要求した方がよい • オフライン攻撃を考慮すると、英数字記号の12文字以上が最低要件と考 える…が難しい場合はストレッチング等で防御力を高める（後述） • パスワードの「最大長」はハッシュ値での保存を考えると上限を制限する 根拠はないが、Amazonのように maxlength=128くらいでよいのでは?
- 5. パスワードの中身の要件 5Copyright © 2013 HASH Consulting Corp. twitterはパスワードの「辞書」によるチェックをしている 最近は、facebookやtwitterもパスワードの辞書チェックをしている
- 6. パスワード入力画面 • パスワードはマスク表示が「常識」と言わ れているが… • 「良いパスワード」すなわち、記号混じりの 長いパスワードを入力する場合は、入力 を確認したい • IE10 のパスワード入力欄には「目のアイ コン」があり、押下時のみパスワードを表 示する • ショルダーハッキングの可能性があるの で、デフォルトではマスク表示 • 他のブラウザも追随してくれるとうれしい 6Copyright © 2013 HASH Consulting Corp.
- 7. パスワード入力時のエラーメッセージ • りそなダイレクトのログイン画面 • まずログイン画面を確認して、存在するログインであればパスワード入力画 面に進む • ログインIDとパスワードを別々に確認できて、攻撃しやすいw • 通常は、ログインIDとパスワードを同時に入力して、ログインエラーの場合 は、「IDまたはパスワードが違います」というエラーメッセージを表示する 7Copyright © 2013 HASH Consulting Corp.
- 8. パスワードの保存方法 8Copyright © 2013 HASH Consulting Corp.
- 9. そもそも、パスワードだけ保護する理由は? • パスワードが漏れている状況では、他の個人情報も漏れて いる可能性が高い • しかし、情報漏洩だけが「困ること」ではない – 利用者の権限で使える機能の悪用 – 利用者のアカウントでの投稿など • オバマ大統領に成りすましてtwitterでつぶやく、とか • パスワードを他のサイトでも使い回ししている利用者がいる – サイト運営者は、パスワードを使い回ししている利用者のせいにして はいけない – パスワードリスト攻撃が現実のものに ← イマココ • パスワードを可能な限り保護することは、サイト運用者の責 務 9Copyright © 2013 HASH Consulting Corp.
- 10. パスワードリスト攻撃 10Copyright © 2013 HASH Consulting Corp.
- 11. どうして暗号化ではなくてハッシュなの? • 暗号化の場合、鍵の管理が難しい • アプリケーションは鍵を使わなければならないが、攻撃者には鍵を見せ たくない • PSNの事件では、権限昇格されたことになっているので、暗号鍵も盗まれ ていると想定せざるを得ない • ハッシュだと鍵を使わないので、鍵管理のわずらわしさがない • パスワードをサイト管理者にも知られたくないというニーズも – 暗号化されたパスワードだと、サイト管理者やヘルプデスク担当者がパスワ ードを知り得るのが嫌だ – ヘルプデスクに見せないようにするには、サポート用画面の機能次第で可 – 管理者の悪事は総合的な対策が必要で、パスワードの問題だけではない • PCI-DSS2.0 8.4項には「8.4 強力な暗号化を使用して、すべてのシステムコ ンポーネントでの伝送および保存中のすべてのパスワードを読み取り不 能にする」とあり、ハッシュを求めてはいない 11Copyright © 2013 HASH Consulting Corp.
- 12. ハッシュで保存されたパスワードは本当に安全なの? • 一般的に、（暗号論的）ハッシュ値から平文を「復元する」ことはできない – 「password」のMD5ハッシュ: 5f4dcc3b5aa765d61d8327deb882cf99 • しかし、パスワードの場合は特別な事情がある • 例：4桁の暗証番号をハッシュ値で保存している場合 – 全ての可能性は1万通りしかないのだから、総当たりで確認すれば、平文の 暗証番号はすぐに判明する • 原理は8桁パスワードでも同じ • ハッシュ保存の場合、アルゴリズムは攻撃者が知っている前提で安全な 設計とする – 平文パスワード以外は、すべて「ばれている」想定を置く • 攻撃者にとって未知であることが保証された情報があれば、それを鍵とし て暗号化すればよい。現実にはそのような保証がないから暗号化を用い ない 12Copyright © 2013 HASH Consulting Corp.
- 13. ハッシュから平文パスワードに戻す方法はないの? • 「徳丸本」で紹介している方法 • 総当たり攻撃 • 辞書攻撃 • レインボークラック • ユーザDBにパスワード辞書を作る 13Copyright © 2013 HASH Consulting Corp.
- 14. 総当たり攻撃・辞書攻撃 • オフライン型のパスワードクラックツールが該当 – John the Ripperなど • さまざまなパスワードの「候補」からハッシュ値を求めて照合する • 「辞書」の内容としては、よく使われるパスワードの他、ユーザIDそのもの （Joeアカウント）、組織名なども含める 14Copyright © 2013 HASH Consulting Corp. 総当たり攻撃のイメージ 辞書攻撃のイメージ aaaaaa aaaaab aaaaac aaaaad aaaaae ... password 123456 qwerty pokemon root ...
- 15. 総当たり攻撃って遅いんでしょ • そうでもない • ハッシュ関数は高速性が求められる – 電子署名などの用途では、高速であるほどよい – DVD-ROMイメージ全体のハッシュ値を求めたりする • パスワード保護の目的では、高速性は要らない – むしろ、平文解読も「高速」になってしまう • こういう記事も 15Copyright © 2013 HASH Consulting Corp.http://slashdot.jp/security/article.pl?sid=11/06/06/0023219 より引用
- 17. テスト1:"password" （続き） パスワード人気ランキングで常に上位にいる「password」という文字列をMD5でハッシュ化した 「5f4dcc3b5aa765d61d8327deb882cf99」を解読してみました。文字種の指定はデフォルトの英小文字としました。 f:id:sen-u:20110629085027p:image c:¥> ighashgpu.exe -h:5f4dcc3b5aa765d61d8327deb882cf99 -t:md5 -c:s -max:8 （略） Found 1 CAL device(s) Starting brute-force attack, Charset Len = 26, Min passlen = 4, Max passlen = 8 Charset (unicode -> 0) [abcdefghijklmnopqrstuvwxyz] Charset in HEX: 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 75 76 77 78 79 7a Starting from [aaaa] Hash type: MD5, Hash: 5f4dcc3b5aa765d61d8327deb882cf99 Device #0: [Juniper] 860.00 Mhz 800 SP Hardware monitoring enabled, threshold temperature is 90°C. CURPWD: umggwqur DONE: 87.12% ETA: 14s CURSPD: 1842.9M Found password: [password], HEX: 70 61 73 73 77 6f 72 64 Processed 190 350 098 432 passwords in 1m 34s. Thus, 2 034 328 660 password(s) per second in average. 1分34秒であっさりと解読できてしまいました。1秒で約20億回も試行してるんですね。 17Copyright © 2013 HASH Consulting Corp.
- 20. MD5なら危険で、SHA-1なら安全なんでしょ? • ハッシュ値から平文パスのワードを求める手法は、いずれも MD5固有の特性（脆弱性）を使っていない • いずれも、総当たり攻撃、辞書攻撃やこれらの変形である • したがって、既知のハッシュ関数であれば、前述の攻撃手法 が適用可能 • たまに、「MD5によるパスワード保存は危険」とか「SHA-1によ るパスワード保存もそろそろ危険」とか書いている文書があ るが、たいてい間違い • LinkedInから漏洩したパスワードはSHA-1ハッシュで保存され ていたが… 20Copyright © 2013 HASH Consulting Corp.
- 22. 650万件のパスワードハッシュのうち540万件が1週間で解読 22http://securitynirvana.blogspot.jp/2012/06/final-word-on-linkedin-leak.html より引用 https://twitter.com/jmgosney/statuses/213212108924522496 より引用 Surviving on little more than furious passion for many sleepless days, we now have over 90% of the leaked passwords recovered.
- 23. Saltってなに? • ソルト（Salt）とは、ハッシュの元データ（パスワード）に追加する文字列 • 見かけのパスワードの長さを長くする →レインボーテーブル対策 • ユーザ毎にソルトを変えることで、パスワードが同じでも、異なるハッシュ 値が得られる – ソルトがない場合、パスワードの組み合わせ回数分ですむが、ソルトがある と、×ユーザ数 に試行回数が増える – LinkedInの場合は、試行回数が 650万倍に ! • ソルトの要件 – ある程度の長さを確保すること – ユーザ毎に異なるものにすること • ソルトには乱数を用いることが多いが、乱数が必須というわけではない （暗号論的に安全な乱数である必要はもちろんない） • ソルトは秘密情報ではない。ソルトは、通常ハッシュ値と一緒に保存する 23Copyright © 2013 HASH Consulting Corp.
- 24. Stretchingってなに? • ストレッチング（Stretching）とは、ハッシュの計算を繰り返すこと • ハッシュの計算を遅くすることにより、辞書攻撃や総当たり攻撃に対抗する • 1万回ストレッチすると、「 GPUモンスターマシンで20分掛かる」が20万分に なる計算 – 20万分 = 139日 … • 「悪い」パスワードまで救えるわけではない – 「password」というパスワードをつけていたら、100万回ストレッチしてもすぐに解 読されてしまう • 十分長いパスワードをつけてもらえば、ストレッチングは必要ない – 1文字パスワードを長くすることは、約90回のストレッチングに相当する。パスワ ードを2文字長くしてもらえば… – ストレッチングは、「弱いパスワード」の救済の意味がある • ストレッチングはメリットとデメリットがあるので、導入の有無と回数をよく検 討すること 24Copyright © 2013 HASH Consulting Corp. むむ、これだとパスワードの定期的変更か?
- 25. パスワードをハッシュで保存する場合の課題 • 「パスワードリマインダ」が実装できない – 「秘密の質問」に答えるとパスワードを教えてくれるアレ – パスワードリセットで代替 • ハッシュの形式（アルゴリズム、ソルト、ストレッチ回数）の変更 – 生パスワードが分からないのでハッシュの方式変更がバッチ処理ではできな い – ユーザの認証成功の際にはパスワードが分かるので、その際に方式を変更 すると良い – 緊急を要する場合は、現在パスワードを無効にして、パスワードリセットで – ハッシュ値あるいは別フィールドに「方式番号」をもっておく – PHP5.5のpassword_hash関数が便利 （ソルト・ストレッチング内蔵） $1$d641fdabf96912$4b3c3e95dfab179ebfef220172f58171 25Copyright © 2013 HASH Consulting Corp. 方式番号 ソルト ハッシュ値
- 26. password_hash 関数 (PHP5.5から) 26http://php.net/manual/ja/function.password-hash.php より引用 <?php echo password_hash('rasmuslerdorf’, PASSWORD_DEFAULT); 【結果】 $2y$10$.vGA1O9wmRjrwAVXD98HNOgsNpDczlqm3Jq7KnEd1rVAGv3Fykk1a
- 27. 結局どうすればよいの? • パスワード認証は、利用者とサイト運営者が責任を分かち合 っている • 利用者に、よいパスワードをつけてもらうのが本筋 • オンライン攻撃に備えて、以下を実施する – アカウントロックの実装 – SQLインジェクションなどの脆弱性対処 – でれきば…二段階認証、リスクベース認証 – Googleなど認証プロバイダの活用 • オフライン攻撃対策は中々決め手がない – ソルトなしのハッシュは、レインボーテーブルで元パスワードが簡単 に求められる – ソルトは必須。できるだけストレッチングもする(password_hash関数な ど) – DBのパスワード欄に余裕を持たせ、方式を改良できるようにしておく 27Copyright © 2013 HASH Consulting Corp.
- 28. まとめ • パスワードの器の要件 – 12文字以上（できれば、もっと）のパスワードが入力できること • パスワードの中身の要件 – パスワードの中身はユーザの責任 – しかし、「悪いパスワード」のチェックも必要になりつつある • パスワードの入力画面 – 「パスワードを見せる」という新しい考えかた • 認証エラーメッセージ – 基本は「IDまたはパスワードが違います」 • パスワードの保存方法 – 最低ライン: ソルト付きハッシュ – できれば：ソルト付きハッシュ × ストレッチング • 定期的なパスワード変更をしないですむ安全なパスワード保存を 28Copyright © 2013 HASH Consulting Corp.
- 29. ご清聴ありがとうございました