正しいハッシュ化
こんばんわ！！
koutaです！！
本日は正しいハッシュ化についてです。
その前に。。。
衝突が見つかったようです。
論理的には昔からあると言われていましたが。。。
https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html?m=1
衝突というのは、違う値でもハッシュ化後の値が一致してしまうことです。
なんかネットで見てると
膨大な施行が必要なので差し迫った対応は必要ない。
的な記事もありました。
確かに。。。
9,223,372,036,854,775,808回(いくつやねん)
の試行が必要で、
第一フェーズには6500年のCPU計算
第二フェーズには110年のGPU計算
だそうな。
英語が苦手な私は、
CPU何個でやねん。
と突っ込んでしまいそうです。
誤訳しているかもしれませんが。。。
30日後にはコードと共に公開するそうです。
公開されてしまうので差し迫った対応をしましょう！！
先日、SHA2のアルゴリズムも危ないということを書きました。
ハッシュ化 ＋ ソルト
という話ですが
もう一つ追加してほしいのが、
ストレッチング
です。
ハッシュ化した値とソルトをまたハッシュ化してほしいのです。
何度もストレッチングを繰り返すことでハッシュ化を重ねます。
なのでハッシュ化したい場合下記のようにするとよいです。
(わかりにくい数式でごめんなさい)
1.ハッシュ化文字列＝ハッシュ関数(対象文字列 ＋ ソルト)
2.ストレッチング文字列＝ハッシュ関数(ハッシュ化文字列 ＋ ソルト)
3.ストレッチング文字列＝ハッシュ関数(ストレッチング文字列 ＋ ソルト)
以降ストレッチングの繰り返し。
数百から数万の繰り返しが良いみたいです。
何故こんなことをするかというと。
脆弱対策をしても、どれだけ気をつけても、流出するときは流出します。
仮に、私みたいな立場の人間が悪意を持ってやったらうちの会社の情報は簡単に出せます。(やりませんが)
流出は前提として。
流出した場合に被害に合う前に対策をうつ時間稼ぎの為です。
ちなみにストレッチングのいいところは独自の暗号化アルゴリズムを考えなくて良いところです。
ハッシュ前の文字列とソルトが流出したところで、
ストレッチングの回数まで合致しないとハッシュ値が合致しないので十分対策時間が取れると思います。
先程のgoogleの記事にMD5のアルゴリズムは1つのスマホで30秒で解析可能と書いてありました。
頭の固いおっさんがいたら突きつけてやってください。
情報流出した場合のコストはハッシュ化アルゴリズムを変えるコストに比べたら微々たるものですよと。
具体的数値を突きつけて説明してやってください。
1万人流出したとして、500円補填したら500万円の損失で。。。
評判が下がるとこによる副次的効果を入れたら。。。
対策したほうが良いに決まってます。
お金が絡むと状況によりますけど。
ということで、
ブログを読んだ皆さんは、
- ハッシュ化はSHA256より強いもの
- ソルトを使う
- ストレッチングする(複数回やる)
ということでお願いします。
