ストレッチング採用の理由
2011年5月25日(水曜日)
ストレッチング採用の理由
更新: 2011年5月30日10時50分頃
徳丸さんに誘われ、徳丸本 (www.amazon.co.jp)
翌日に徳丸さんはこんなつぶやきをしておられますが、
同じく昨日の一言。「パスワードのストレッチングについては効果を疑問視する声もあったが、『教科書』にベストプラクティスとして載っている以上、最低限そこまではやるべきと主張して、徳丸本の通りに実装することにした」<こういう声は嬉しいですね
これは私の発言ですね。せっかくなので、もう少し流れを補足しておきます。
サーバ側でパスワードを保存する際、パスワードそのものではなく、ハッシュ関数を通したハッシュ値を保存することが良く行われます。これによって、たとえDBの値が漏洩しても、生のパスワードが漏れることがなくなります。とはいえ、攻撃者はハッシュ値を作りながら総当たりをすることも可能ですし、事前にハッシュ値のデータベースを作っておいて攻撃するような手法もあります。
そこで考えられたのが、ハッシュ関数を何度も使った結果を保存するという手法です。こうすると、攻撃者がハッシュ値をつくりながら攻撃をするのに時間がかかるようになり、総当たりに必要な時間を増加させることができるようになります。この、ハッシュ関数を何度も使うことによって時間を稼ぐ方法を「ストレッチング」と呼んでいます。
※時間を稼ぐほかに、ハッシュ値生成のアルゴリズムが分かりにくくなるという効果も無くはないのですが、DBの値が漏れているような状況ではソースコードが漏れている可能性もありますし、攻撃者は自らアカウントを取得してハッシュ値がどうなるかを調べることもできます。アルゴリズムはばれている前提で考えるべきです。
さて、実は今、社内であるシステムを開発しているのですが、パスワードを保存する際の仕様ががっちりと決まっていなかったので、どうするのか議論になりました。ソルトをつけてハッシュ値を保存するところまでは良いとして、ストレッチングのような処理が本当に必要なのかどうか、というのが議論のポイントです。
セキュアプログラミングの要素の多くは、議論の余地無く採用されるものです。XSSやSQLインジェクションは単なるバグで、その対応はアプリケーションの正常動作ために必要です。CSRFへの対策も、その必要性は明らかです。
しかし、このストレッチングはアプリケーションの動作に必須のものではありません。DBの中身が漏洩する事故が起きて初めて意味を持ちますが、それにしても必要性がどの程度あるのか疑問です。長めのソルトをつけてハッシュしてやれば、それだけで十分なのではないかとも思えます。メリットがいまいち分かりにくい上に、平時はCPUパワーを浪費したり動作が遅くなったりするデメリットもあります。
※動作を遅くすることが目的なので、プログラミングの工夫で速くすることもできません。
というわけで、技術的にはメリットとデメリットの両方があって何ともいえず、採用するかどうか決められませんでした。にもかかわらず採用することに決めたのは、技術的な必要性というよりも、政治的な必要性があったからです。何かセキュリティ事故が起きて、「十分な対策を行っていたか?」と問われたときに、「よく知られた手法があるのに、それを採用していなかったではないか」と責められると厳しいでしょう。つまり、「有名書籍に肯定的に書かれている」ということ自体が採用の理由になっています。
※2011-05-30追記: ちょっと語弊があった気がするので補足しておきます。「技術的に不要だと判断したのに政治的な理由で無理矢理実装させられた」というネガティブな話ではなくて、単に「技術的には要・不要の決断ができなかったので、政治的な理由で決定に至った」ということです。本文も少し修正しました。
- 「ストレッチング採用の理由」にコメントを書く
- 前(古い): JUGEM管理画面、セッションID漏洩の問題を修正
- 次(新しい): 原発労働記
