More Related Content
More from Joe_noh
More from Joe_noh (20)
Password security
- 1. パスワード認証の話
- 3. 3 あじぇんだー ● パスワードのハッシュ化 ● パスワードクラック ● 対策 ● ハッシュアルゴリズム ● まとめ ● 不正アクセス事例
- 5. 5 ハッシュ関数
- 6. 6 ハッシュ関数の要件 ● 一方向性 ➜ 出力値から入力値を求めることが困難（現実的に無理）であること ● 第二現像困難性 ➜ 与えられた入力値と同じ出力値が得られる入力を求めることが困難であること ● 衝突困難性 ➜ 出力が同じになる入力ペアを求めることが困難であること 衝突困難性を満たせば、一方向性と第二現像困難性も満たしている
- 7. 7 ざっくりパスワード認証 DB Hash ● 登録 ● ログイン Hash Match? “password” 0x14f7de8a ...
- 9. 9 なぜハッシュ化？ ● 一方向性が保証されていれば ➜ DBのデータが流出してもパスワード自体は守られる ● 暗号化と違って ➜ 復号できない ➜ 鍵の管理が要らない ● 運営者もパスワードが分からない ➜ 良からぬ従業員も悪さできない
- 10. 10 パスワードクラック
- 11. 11 オンライン攻撃 ● ブルートフォース ➜ 総当たり。力技。ゴリ押し。 ➜ あるパスワードを全ユーザに試すのは「逆ブルートフォース」 ● 辞書攻撃 ➜ よくあるパスワード、英単語に当たりをつけて試行する ● Joeアカウント狙い ➜ ユーザ名 = パスワード
- 12. 12 オフライン攻撃 ● オンラインとの大きな違い ➜ DBデータは流出済でハッシュ値が見えてる ➜ ハッシュアルゴリズムとかもバレてるかも ● オンライン攻撃と同じ手法も使える ● レインボーテーブル ➜ 膨大な数のハッシュ値を予め計算しておく ➜ GPUとか丸一日ブン回すとド偉い数（10^15とか？）のハッシュ値が作れる ➜ 還元関数とか頭いい
- 13. 13 対策
- 14. 14 講じるべき対策１ ● アカウントロック ➜ 何回かログインに失敗したら1時間くらいロック ➜ オンライン攻撃対策 ✔ 本物ユーザにも影響しちゃうかもしれないけどログインされるより100倍マシ
- 15. 15 講じるべき対策２ ● ログインIDとユーザ名を別にする ➜ 会員ならばユーザ名の入手は簡単（なサービスが多いはず） ➜ 例えばメールアドレス＋パスワードでログインさせる ➜ オンライン攻撃対策 ✔ ログインIDの秘匿化
- 16. 16 講じるべき対策３ ● ストレッチング ➜ ハッシュ化を何回も繰り返す ➜ 10,000回とか常識だそうです ➜ 総当たり対策 ✔ 総当たりに要する時間が増えて攻撃者がダルくなって諦める ✔ ユーザにパスワード変更を促す時間を稼げる
- 17. 17 講じるべき対策４ ● ソルティング ➜ ソルト ＝ 適当な文字列 ➜ ソルトとパスワードを連結してからハッシュ化（単純な連結は良くないらしい） ➜ ユーザ毎に異なる、長めのソルトが好ましい ➜ レインボーテーブル対策 ✔ 同じパスワードでも違うハッシュ値になる ✔ 長さ数十文字のランダム文字列レインボーテーブルを作るのは結構しんどい ✔ キーボードから入力できる文字95種でつくれる1~50文字の文字列は だいたい10^100個くらい（計算合ってる？）
- 18. 18 ソルト＋ハッシュ DB Hash ● 登録 ● ログイン Hash Match? “password” 0x14f7de8a ... ＋ ＋ “salt” “salt” “salt” 0x14f7de8a ...
- 19. 19 HMAC ● Hash-based Message Authentication Code ➜ ハッシュ関数に衝突が見つかっても大丈夫な可能性が高い ➜ 定番？ : 0x5c5c5c … 5c5c : 0x363636 … 3636 : 秘密の鍵
- 20. 20 ハッシュアルゴリズム
- 21. 21 どれ使えばいいのさ ● DES ➜ 話にならない ● MD5 ➜ よくない ● SHA1 ➜ よくない ● SHA2 ➜ これは今んとこOK ※ 単体で使うのは論外
- 22. 22 有力候補として紹介されてるもの ● PBKDF2 ➜ ソルト化ハッシュとかHMACとかストレッチングとか ➜ まとめて色々やってくれるらしい ● bcrypt ➜ Blowfish暗号化を利用 ➜ 入力は72文字（72Byte）までらしい ● scrypt ➜ メモリむしゃむしゃするアルゴリズム ➜ Stronger Key Derivation via Sequential Memory-Hard Functions
- 23. 23 ちょっと寄り道 C. Percival. Stronger Key Derivation via Sequential Memory-Hard Functions. BSDCan 2009
- 24. 24 結局のところ ● クラックのコストを高めるための工夫 ➜ 現実的に不可能なレベルまで高めることはできる ● 弱いパスワードは破られやすい ➜ 短い、辞書にある、単純なパスワードは登録させない ➜ 他のサービスと共通のパスワードが狙われている ● 強くて覚えやすいパスワード ➜ 文字種より長さが大切 ➜ 文章みたいなパスワードは十分に強いという意見もあるそうです
- 25. 25 まとめ ● ハッシュ関数の性質でパスワードを守る ● パスワードがバレるよりはユーザロック ● ユーザID≠ログインIDが好ましい ● ソルティングやストレッチングで計算コストを高くする ● 強いパスワードの設定を促す
- 26. 26 不正アクセス事例 ● NAVER ➜http://linecorp.com/press/2013/0719581 ● 任天堂 ➜ http://www.nintendo.co.jp/support/information/2013/0705.html ● JAXA ➜ http://www.jaxa.jp/press/2013/07/20130702_security_j.html ● goo ➜ http://help.goo.ne.jp/help/article/2037/
- 27. 27 魚拓
- 28. 28 魚拓
- 29. 29 参考 ● 本当は怖いパスワードの話 http://www.atmarit.co.jp/fsecurity/special/165pswd/01.html ● Storing Passwords Securely http://throwingfire.com/storing-passwords-securely/ ● 算術演算をベースとするハッシュ関数安全性評価に関する調査報告書 http://www.ipa.go.jp/files/00013899.pdf ● RainbowCrack Project http://project-rainbowcrack.com ● Wikipedia (English)