How Common Security Practices and Advice May Hinder Computer Security

[アーティクル]
08/25/2016

セキュリティウォッチパスワードとクレジットカード、第 1 部

Jesper M. Johansson

先ごろ、ミネソタ大学から連絡があり、学内誌のインタビューを受けてほしいと依頼されました。どうやら実社会で成功を収めている卒業生に関する特集記事を組みたいらしいのですが、だれも見つからなかったので私にお鉢が回ってきたようです。インタビューアが私の仕事の内容についてたずねてきたので、数分間、セキュリティ

インフラストラクチャソフトウェアについて説明しました。彼女は驚いたようすで、「本当に複雑なんですね。私は、セキュリティといえば、パスワードとクレジットカードくらいしか思い浮かばないものですから」と答えました。

私はこの彼女の答えについてしばらく考え、なかなかよいポイントを突いていることに気付きました。確かに、セキュリティといえば、パスワードとクレジットカードに違いありません。少なくとも、エンドユーザーにとってはそうです。我々のような IT 業界の人間はセキュリティというと、暗号化アルゴリズムや WS* の利点、Kerberos は TLS や NTLMv2 よりも優れているかどうか、パスワードハッシュにはソルトを加えるべきかどうかなど、よく話題になるあらゆる難解なトピックを思い浮かべます。確かに、私たち専門家はエンドユーザーとはまったく異なる深い洞察を持っていますが、概して、1 つの基本的な事実を忘れがちです。それは、セキュリティは、サービスの提供を受ける側にとっては、パスワードとクレジットカードという形でしか認識されないという事実です。

我々が好んで難解なトピックについて議論したり、新しいテクノロジを考え出したりするのはすべて、エンドユーザーのデータを保護することが目的であることは確かです。それでも、私たち専門家は本来の目的を見失っているように思えます。IT 業界のセキュリティ専門家たちの存在意義は、利用者の要求、つまりデータを保護するという要求に応えることにあります。それには、もちろん、IT 資産を安全に利用できるようにすることも含まれます。目的はそれだけです。

前回の記事で、ウイルス対策ソフトウェアを実行するためにコンピュータを購入する人はいないと書きました。ユーザーは、オンラインバンキングを行ったり、ゲームをしたり、メールを書いたり、宿題をしたり、その他の主要な機能を利用するためにコンピュータを購入するのです。同じように、企業が IT セキュリティ部門に予算を割いているのは、NTLMv2 を実装させるためではありません。セキュリティ部門に企業の IT 資産を保護させ、企業全体が安全に IT リソースを活用し、ビジネスの目的を達成できるようにするためです。

セキュリティ部門の使命は企業に奉仕することです。

私たちは、企業に奉仕するという意味で本当に良い仕事をしているでしょうか。それとも、実際には企業の役に立っているのではなく、むしろ邪魔をしているのでしょうか。議員や規制策定者は我々が企業の邪魔をするように仕向けているのでしょうか。私には、セキュリティ専門家たちが導入している新しい技術がすべてエンドユーザーの役に立っているとは思えません。そこで、この記事では、我々 IT プロバイダがエンドユーザーの役に立つのではなく、むしろ害を及ぼしているような領域について調べてみることにします。

私たちがユーザーに押し付けているセキュリティ上のアドバイスや多くのセキュリティ技術が、実行不可能である、間違っている、または理解不能である、あるいはこの 3 つの点のうち複数が当てはまるようなものであると感じることがときどきあります。この 3 回シリーズの記事では、セキュリティ専門家が、上記の 3 つの点のうち 1 つまたは複数が当てはまるセキュリティ上のアドバイスやテクノロジの展開を行うことによって、ユーザーを混乱させているケースについて見ていきます。

セキュリティに関する実行不可能なアドバイス

ユーザーを最も混乱させるのは、セキュリティに関する実行不可能なアドバイスです。混乱させるだけでなく、間違っているアドバイスさえあります。図 1 に、長年使用され、理論的には正しいものの、実際にはまったく役に立たないよくあるアドバイスの一部を示します。

図 1 セキュリティに関する実行不可能なアドバイス (画像をクリックすると拡大表示されます)

使用しているオンラインアカウントごとに異なるパスワードを使用すること、と書かれている箇所があります。このアドバイスは、30 年前であれば理にかなっていたでしょう。当時は、のちにインターネットとなるネットワークの利用者の数が数百人程度しかいませんでした。彼らは優秀な人たちでしたが、特別良いパスワードを使っていたわけではなかったのです。このアドバイスは不幸にも残されたままとなり、何度も繰り返し言われ続けてきました。しかし、このアドバイスの内容を現在のコンピュータの使用法に合わせて修正する努力は行われませんでした。

皆さんはオンラインアカウントをいくつお持ちでしょうか。私は、厳密には把握していないものの、約 115 のオンラインアカウントを持っています。図 1 のアドバイスによれば、私は 115 の異なるパスワードを作成する必要があるだけでなく、30 ～ 60 日ごとにそれらのパスワードを変更しなければなりません。つまり、毎日 2 ～ 4 個のパスワードを変更しなければならないことになります (計算してみると、年間 690 ～ 1,380 個のパスワードを作成することになります)。

このアドバイスを書いた一部のサイトの技術担当者は毎日 4 つのパスワードを思いつき、115 の現行パスワードを短期記憶に留めておくことができるのかもしれませんが、一般的な大半のインターネット利用者には、そんなことはできないでしょう。

すべてのアカウントで異なるパスワードを使用するというアドバイスは、建前としては正しいし理にかなっています。すべてのパスワードを 30 ～ 60 日ごとに変更するというアドバイスについても同じことが言えます。しかし、このアドバイスは実行不可能なのです。今日のユーザーが使用するパスワードの数の多さを考えると、このアドバイスに従うのは、紙に控えるとかソフトウェアに記憶させるなど、何らかの補助手段を使用しないと無理です。次のような例もあります。

実行不可能かつ間違ったアドバイス

図 2 に示したアドバイスは、世界最大規模の銀行の Web サイトに掲載されているものですが、実行不可能なだけでなく間違っています。"Read our password advice (パスワードに関するアドバイス)" という見出しのこのページには、「すべての場所に異なるパスワードを使用せよ」という言い方が繰り返し出てきます。また、パスワードを決して書き留めたりしないように推奨しています。

図 2 実行不可能かつ間違ったアドバイス (画像をクリックすると拡大表示されます)

私は 115 の異なるパスワードを持っていますが、毎日 4 つのパスワードを作成する必要があり、しかもそれらを書き留めることが許されないというのです。私は最初、パスワードをすべて憶えることができないのは、自分が優秀ではないためだと思っていました。しかし、実際には、だれもが同じようにパスワードを憶えるのに苦労していることを知りました。人間には 115 ものパスワードを憶えることなどできません。人間が憶えて処理できる情報の塊は 7 つまでに制限されます。人間の脳はそのように作られているのです。インターネット上に存在するパスワードに関するほとんどのアドバイスに従うとなると、人間の処理能力ではパスワードを 1 つ作成するのにも足りません (George A. Miller が書いた「The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information (魔法の数 7±2: 我々の情報処理能力のいくつかの限界)」(musanim.com/miller1956) を参照)。

残念ながら、パスワードのアドバイスに関しては、IT 業界は、何度となくユーザーを誤った方向に導いています。われわれセキュリティ専門家がすべての場所で異なるパスワードを使用すべきだとユーザーに忠告するなら、その方法について、つまり、パスワードをどこか安全な場所に記録し格納するという点についても教える必要があります。紙に書き留める方法、セキュリティ保護されたドキュメントを使用する方法、または PasswordSafe (sourceforge.net/projects/passwordsafe) などの特殊なツールを使用する方法があります。パスワードをすべて記憶するか、どこでも同じパスワードを使用するかのどちらかしか選択肢はないのだ、という事実を認識する必要があります。実際、最近行われた調査によると、ユーザーの 88% が認証を必要とするすべてのシステムで同じパスワードを使用しているといいます (msnbc.msn.com/id/24162478 を参照)。

パスワードを書き留めてはならないというアドバイスが、このような結果を招く一因となっていることは間違いありません。セキュリティ専門家たちは、パスワード (およびその他の機密データ) を一切管理してはならないなどと非現実的な忠告をするのではなく、そうした情報の効果的な管理方法をユーザーに教える必要があります。そうすれば、ユーザーがパスワードなどの資格情報を危険にさらすことも少なくなります。

理解不能なアドバイス

前出の 2 つの図では、言い古されたアドバイスを繰り返しています。こうしたアドバイスは、だれもがオンライン接続し、Web ベースのサービスを使用するようになる前の、1960 ～ 1980 年代には有用でした。こうした古いアドバイスについて声高に異を唱える人はまだだれもいません。こうしたアドバイスは一般に広く受け入れられている知恵だからです。

この種のアドバイスはユーザーを混乱させます。どこかにパスワードを保管しなければならないことにユーザーが罪の意識を感じる可能性もあります。セキュリティ専門家たちは、この種のアドバイスをすることによって、ユーザーが必要なことをきちんと行うように仕向けるのではなく、むしろユーザーに害を及ぼしています。結局のところ、セキュリティを管理する方法を考え出すのはユーザーの責任ではないのです。それは、セキュリティ専門家の責任です。我々は、ユーザーが自分のオンラインアカウントを管理するために行ってもよいと思える方法を考え出す必要があります。しかし、ほとんどのセキュリティガイドでは、一昔前のアドバイスが相も変わらず繰り返されているだけなので、ユーザーはやむなく、付箋紙に書き留めたり、スプレッドシートに保存したりして、多数のパスワードを忘れないようにするという手段をとっています。

認証メカニズムとしてのパスワードにはさまざまな可能性があります。しかし、パスワードが抱える一番の問題は、人間はパスワードを記憶するのが苦手であるという点です。この人間の持つ特性にかかわる問題を解決するため、IT 業界ではパスワードに替わるさまざまな新しいしくみを考え出してきました。その中には、置き換えるどころかパスワードを増やしてしまうものもありました。こうしたしくみのせいで、ユーザーはますます混乱しています。

ある金融サービスのサイトに前回アクセスしたときには本当に驚きました。ログイン画面にユーザー名のテキストボックスしか表示されていなかったためです (図 3)。

図 3 パスワードの入力場所は?

最初は、偽サイトに接続したのかと思いました。それですぐにサイトを検証してみたところ (そのサイトは証明書を提示していたので検証は簡単でした)、確かに本物のサイトであることがわかりました。問題は、利用者の側が、サイトにログインするとき、ユーザー名とパスワードの 2 つのテキストフィールドが表示されることに慣れきっている点にあります。何年も同じ手順でログインしてきた結果です。そのため、ユーザー名だけをたずねるサイトに出くわすと、驚いて手を止めてしまうのです。このケースでは、フィッシング攻撃を防ぐため、写真を使ってユーザーがサイトを認証する技術をプロバイダが提供していたことがわかりました。ユーザー名を入力すると、識別可能な写真が画面に表示されます (図 4 を参照)。

図 4 ユーザーによるサイトの認証に画像を使ったサイト (画像をクリックすると拡大表示されます)

この方法のポイントは、どの画像がどのサイトと対になっているかをユーザーが知っているところです。正しい画像が表示されなかったら、そのサイトは偽サイトであるとわかります。それ自体は、理にかなった考え方です。どの画像がどのサイトと対になっているかをユーザーが知っているという前提の下では、この手法はある程度有効です。

勘の鋭い方は、図 4 でアドレスバーが緑色になっていることにお気付きのことと思います。これは、このサイトが SSL と Extended Validation (EV) 証明書を使用していることを意味します。アドレスバーが緑色になっているのはそのためです。これは同時に、サイトの認証に画像を使用するという前提自体が、フィッシング対策として新たな価値をもたらすものではないことを意味します。このような画像は、少なくとも一部のエンドユーザーにとっては、混乱が増すだけです。このサイトは既にユーザーに対する自身の認証を行っています。会社名、Web サイトのアドレス、信頼できる発行者の名前が明記された証明書を提示しているためです。アドレスバーが緑色であるということから、その会社が EV 証明書を導入するために、わざわざ通常の 3 倍もの高い料金を支払っていることもわかります。

そして、当然ながら、写真が偽物である可能性もあります。ユーザーが自分の写真を送信できるなら、使用されている画像を攻撃者が推測する方法が存在します。ユーザーがすべてのサイトで同じ画像を使用する可能性も大いにあります。その場合、攻撃者はユーザーにとって、(たとえば皆さんも容易に思いつくような) 価値のあるコンテンツを提供するサイトを開設し、そのサイトの認証に使用する画像をユーザーにたずねればよいだけです。ユーザーがすべてのサイトで同じ画像を使用していれば、この偽サイトは、ユーザーが取引銀行で使用している画像を手に入れることができます。

使用する画像を選択できるサイトもあれば、画像ライブラリを使用しているサイトもあります。たとえば、図 4 のサイトでは、318 枚の写真から選択できます。ユーザーが自分の選択した画像をアップロードできないサイトでは、上記の攻撃方法は使えません。しかし、ユーザーが自分で画像を選択できないとなると、あまり頻繁にアクセスしないサイトでどの画像を選択したかユーザー自身が忘れる可能性もあります。正直なところ、私は図 4 に示したサイトで自分が選択した写真を憶えていません (図 4 の画面に表示されている写真ではないことは確かですが)。

こうした画像を用いたアプローチの問題点は、攻撃者がたとえば 318 枚のうち任意の 1 枚を表示したり、Flickr などの写真共有サイトからランダムに選択して提示すれば、多くのユーザーが提示された画像を自分の選択した画像だと思いこむことです。大半の人が画像とサイトの組み合わせを憶えておくことができるなら、フィッシングやセキュリティ関連のさまざまな問題は起こっていないはずです。

サイトが証明書によって既に認証されているのに、ユーザーにサイトが本物であることを証明するためになぜわざわざ写真を使用するのでしょうか。証明書を使用してサイトを検証する方法をユーザーに教えれば済むことなのに、なぜそうしないのでしょうか。サイトが本物であることは証明書によって既にユーザーに証明されているのです。

もちろん証明書を取得するプロセスは、ユーザーのサイト認証用画像を取得するプロセスよりもはるかに安全です。EV 証明書を使用しているサイトに Internet Explorer® 7 または Firefox 3 でアクセスすると、ブラウザのアドレスバーに該当する証明書情報が強調表示されます。ただし、残念ながら、強調表示されるのは料金の高い EV 証明書だけです。

画像を用いたサイト認証の落とし穴

画像による認証技術には多くの問題があります。まず、サイトからユーザー名を簡単に入手できることです。実際、図 4 に示したサイトで、間違ったユーザー名を入力すると、図 5 のようなダイアログが表示されます。ここで秘密の画像を既に選択しているユーザーの正しいユーザー名を入力すると、そのユーザーの秘密の画像を見ることができるのです。秘密の画像は、ユーザーに関する情報を入手しようとしている攻撃者にとってきわめて価値の高い情報です。

図 5 画像による認証を行うサイトでは、ユーザー名を簡単に入手できる

ここで紹介したタイプの実装には、事実上、セキュリティ上の価値はありません。攻撃者は、偽のサイトでログオンの手順を簡単に再現できてしまいます。偽のサイトはユーザー名をたずねた後、本物のサイトに制御を渡すだけです。クライアント上で AJAX を使用してフォームをリアルタイムに更新することで、外観をよく見せることもできます。さらには、本物のサイトがログオンフォームに対するクロスサイトリクエスト偽造攻撃の対策をしていなかったり、ブラウザがクロスサイト XML-HTTP リクエストの安全対策をしていなかったりする場合は、AJAX のコードで本物のサイトに直接リクエストを送信することも可能です。

本物のサイトから結果が返されたら、攻撃者はそのデータを解析し、写真を抜き出して、エンドユーザーに表示できます。言い換えると、偽のログインサイトをユーザーに提示できる攻撃者はだれでも、ユーザーの秘密の画像を表示できることになります。要するに、画像によるサイト認証にはまったく意味がないということです。ユーザーがサイトから認証される前に画像が表示されるため、攻撃者は正規ユーザーのユーザー名を取得できた場合は秘密の画像を手に入れることができます。

ユーザーがフォームを送信する前に証明書を確認するように教えられていないとすると (画像によるサイト認証自体がこれと同じ前提に基づいていることを考えると、このように想定しておくのが安全でしょう)、ユーザーからユーザー名を取得するのは簡単です。また、画像を用いたサイト認証方式では、ほとんどの場合、正式なユーザー名を入力したときと無効なユーザー名を入力したときの反応が異なるため、ユーザーから直接入手できなくてもそうしたサイトから正式なユーザー名を容易に入手できます。攻撃者は、実際の攻撃を開始する前に、アウトオブバンド (コンピュータを使わないソーシャルエンジニアリング的な行為) でユーザー名を入手することも可能です。

結局、ユーザーは、自分は安全だと信じるか、ただ混乱させられるだけです。我々は画像を用いたサイト認証の実装に多額の投資をしてきましたが、悪意のあるユーザーがエンドユーザーを騙して偽のサイトに資格情報を送信させる行為を防ぐことはまったくできていません。

今回のセキュリティウォッチはここまでです。次回は、ユーザーを間違った方向に導くセキュリティ上の習慣や質の悪い認証の実装について、さらに具体例を挙げながら解説する予定です。

Jesper M. Johansson は、セキュリティソフトウェアの開発に取り組むソフトウェアアーキテクトで、TechNet Magazine の編集にも携わっています。MIS の博士号を持ち、コンピュータセキュリティの分野で 20 年以上の経験があります。また、エンタープライズセキュリティの分野で Microsoft MVP を受賞しています。最新の著書には、『Windows Server 2008 Security Resource Kit』があります。

目次

その他のリソース