パスワード認証に関すること その2 メインは"Security through Obesity" 一部の英数字フォントが意図しないものになってしまった

1. パスワード認証の話 ２

2. 今日の内容
http://opine.me/a-better-way-to-store-password-hashes/

3. まずは
前回のおさらい
3

4. ハッシュ関数（理想）
4

5. ざっくりパスワード認証
●
登録
“password”
●
Hash
0x14f7de8a ...
DB
ログイン
Hash
Match?
5

6. なぜハッシュ化？
●
一方向性が保証されていれば
➜ DBのデータが流出してもパスワード自体は守られる
●
暗号化と違って
➜
➜
●
復号できない
鍵の管理が要らない
運営者もパスワードが分からない
➜
良からぬ従業員も悪さできない
6

7. パスワードクラック
7

8. オンライン攻撃
●
ブルートフォース
➜
➜
●
総当たり。力技。ゴリ押し。
あるパスワードを全ユーザに試すのは「逆ブルートフォース」
辞書攻撃
➜
よくあるパスワード、英単語に当たりをつけて試行する
● Joeアカウント狙い
➜
ユーザ名 = パスワード
8

9. オフライン攻撃
●
オンラインとの大きな違い
➜ DBデータは流出済でハッシュ値が見えてる
➜
ハッシュアルゴリズムとかもバレてるかも
●
オンライン攻撃と同じ手法も使える
●
レインボーテーブル
➜
膨大な数のハッシュ値を予め計算しておく
➜ GPUとか丸一日ブン回すとド偉い数（10^15とか？）のハッシュ値が作れる
➜
還元関数とか頭いい
9

10. 対策
10

11. ソルト＋ハッシュ
●
登録
“salt”
“salt”
0x14f7de8a ...
“password”
Hash
＋
“salt”
●
DB
ログイン
＋
Hash
Match?
0x14f7de8a ...
11

12. 有力候補として紹介されてるアルゴリズム
● PBKDF2
➜
ソルト化ハッシュとかHMACとかストレッチングとか
➜
まとめて色々やってくれるらしい
● bcrypt
➜ Blowfish暗号化を利用
➜
入力は72文字（72Byte）までらしい
● scrypt
➜
メモリむしゃむしゃするアルゴリズム
➜ Stronger
Key Derivation via Sequential Memory-Hard Functions
12

13. ここからが
本題
13

14. ひとことで言うと
防衛
保証
Security through Obesity
〜のために
〜によって
肥満
14

15. 肥満による防衛
15

16. 16

17. 違います
17

18. 手法
●
データベース
user_id
user_name
salt
hash
1
John
abc...
3bb...
2
Bob
2a3...
76a...
3
Nick
4bf...
4de...
Hashのテーブルは別
18

19. 手法
●
ユーザ新規作成・パスワード変更
➜
➜
●
ランダムなソルトを生成してUPDATE
ハッシュを計算してINSERT
ログイン
➜
入力されたパスワードとDBのソルトからハッシュ計算
➜ DBにそのハッシュ値が存在するかチェック
●
前処理としてダミーハッシュでDBを埋めておく ← これ重要
19

20. なにが違うの？
●
ブルートフォースするとき
➜
ハッシュテーブルを総ナメする必要あり
➜
でっかいRAMが必要
➜ GPUベースのブルートフォースをやりにくい ← ボクこのへん詳しくない
➜
●
１人のユーザだけ狙っても（前の手法に比べれば）破りにくい
ハッシュテーブルが巨大
➜ USBメモリとかには到底入らない
➜
持ち出しにくい
20

21. ハッシュは衝突しないの？
1.0E+00
1.0E-02
1.0E-04
衝突確率
1.0E-06
サメに喰われる確
率
1.0E-08
1.0E-10
1.0E-12
家に隕石が落ちる確率
1.0E-14
1.0E-16
1.0E-18
1.0E+15
1.0E+16
1.0E+17
1.0E+18
1.0E+19
1.0E+20
1.0E+21
160bit ハッシュの数
1.0E+22
1.0E+23
1.0E+24
1.0E+25
21

22. まとめ
●
肥満 = 膨大な量のハッシュ
●
ダミーで10 個まで増やしてもほとんど衝突しない
17
➜
ただし
160bit × 1017 = 2×1018 Byte = 2EB（えくさばいと）
22