Endpoint Protection

 View Only

パスワードの管理について 

May 01, 2013 05:58 AM

今では、データ侵害の事例をほぼ毎週のように見かけるようになりました。そのたびに膨大なユーザーアカウントと、おそらくはそれ以外にも重要なデータが危険にさらされていますが、ほとんどの人はそうした報道に驚きさえしなくなっています。データ侵害はそれほど日常茶飯事になりつつあるからです。

データ侵害に使われる攻撃のなかでも特に多いのが、SQL インジェクションです。SQL インジェクションは、Web アプリケーションの欠陥ランキング OWASP Top 10 でも、長年にわたってトップの座を占め続けています。SQL インジェクションを防ぐ手段はいくつも知られているはずですが、残念ながらアクセス数の多いサイトでも SQL インジェクションの発生は後を絶ちません。さらに、Web サーバーの設定不備やリモート管理ツールの脆弱性を狙えば、攻撃者はシステムにアクセスし、潜在的に重要なファイルを読み取ることができます。

最も確実なパスワードの保存方法については長い間さかんに議論されてきましたが、今でもその結論は出ていません。データベースに平文でパスワードを保存するのは好ましくない、というのは大多数の一致するところですが、実際には今でも至るところで行われています。言い訳として返ってくるのは、「データベースには誰も読み取りアクセス権を持っていないのだから、何も問題ないでしょう?」といった言葉です。歴史が繰り返し証明しているように、この言葉がいつまでも当てはまることはありえません。

一般のユーザーは、自分のパスワードがサービス上でどのように保存されているのか知らないのが普通です。パスワードリセットの機能を利用するという鮮やかな手口も考えられます。なかには、ユーザーのパスワードを平文で記載したメールを送信してくるサービスもありますが、それだけでもパスワードが平文で保存されていることは明らかです。疑問に思ったら、サービス会社に問い合わせてみることもできますが、たいてい「パスワードは最新の暗号化技術で保護されています」と請け合うだけで、それ以上のことは知らされないでしょう。

それでも、キーワードは間違っていません。ほとんどのシステムでは、一方向の暗号化関数が導入されているからです。パスワードの保存には、MD5 や SHA1 など、いわゆるハッシュ関数が使われています。注意したいのは、これがパスワード保護の関数ではなく、通常はメッセージダイジェストを作成するための関数だということです。これをパスワードに利用し、ハッシュ値だけを保存することで、平文パスワードの問題は消え去るように見えます。ところが攻撃者には、パスワードとそれに対応するハッシュ値のペアをあらかじめ計算した「レインボーテーブル」を作成するという手があります。最近のクラウドサービスを使えば、レインボーテーブルの生成にそれほど時間はかからず、組み合わせの値も簡単に保存できます。こうした仕組みを利用すれば、簡単なルックアップだけで一般的なパスワードはすべて瞬時のうちに破ることができるのです。

レインボーテーブルでもパスワードを簡単に破ることができないように、ソルト(salt)を使う方法があります。ソルトとは、ランダムな長い文字列で、これをハッシュ化する前にパスワードと組み合わせます。ユーザー単位でこれを使うと、文字列は一気に複雑になります。仮に 2 人のユーザーが同じパスワード(たとえば、123456)を使ったとしても、結果的にテーブルでは異なるハッシュとして生成されます。しかも、攻撃者は想定されるソルトごとにレインボーテーブルが必要になるので、多数のユーザーのパスワードを同時に解析することは大幅に難しくなります。それでも、特定の 1 ユーザー(たとえば管理者)のパスワードを総当たりで突き止めることは、依然として可能です。

ここで登場するのが、イテレーション(反復)またはキーストレッチです。ハッシュ関数を何度も何度も繰り返すと、全体のプロセスは遅くなります。通常の使い方でログオンする場合には、多少の遅延もそれほど問題になりませんが、総当たり攻撃となれば、パスワードの解析に要する時間は数千年に達するかもしれません。簡単に組み込める例が、bcryptPBKDF2 です。もちろん、2 要素認証を使うだけでも障壁を高くすることはできます。シマンテックの VIP サービスもその一例です。

パスワードの保存にどのような機能が使われるとしても、サービスごとに異なるパスワードを使うようにするのが理想的であることは変わりません。すべてのサービスで同じパスワードを使っている場合、そのひとつでも破られてしまうと(おそらくはパスワード保存のしかたが悪いために)、他のパスワードもすべて攻撃者に知られてしまうことになるからです。データ侵害に成功するたびに、攻撃者は他のサービスに対しても電子メールパスワードの組み合わせを試そうとするものです。あわよくば、という期待程度にすぎませんが。

そもそも強力なパスワードを使うことが必須であることは、言うまでもありません。「123456」は、もちろん強力なパスワードとはほど遠く、けっして使うべきではありません。パスワードを変えたらすべて覚えていられない、というのであれば、パスワードマネージャを使うという手があります。そうすれば、パスワードをスマートフォンに保存して、いつでも確認できます。もちろん、そのスマートフォンを紛失した場合には誰もパスワードマネージャにアクセスできないようにしておく必要がありますが、それはまた別に考えるべき問題です。

 

* 日本語版セキュリティレスポンスブログの RSS フィードを購読するには、http://www.symantec.com/connect/ja/item-feeds/blog/2261/feed/all/ja にアクセスしてください。

Statistics
0 Favorited
0 Views
0 Files
0 Shares
0 Downloads

Tags and Keywords

Related Entries and Links

No Related Resource entered.