セキュリティ管理

パスワードに関する｢よく寄せられる質問｣

Jesper M. Johansson 著
Senior Security Strategist
Security Technology Unit

そのほかのセキュリティ管理コラムもご覧ください。

最近、私はパスワードに関する質問を受ける係になってしまいました。率直に言って、パスワードに非常に興味があるので、それはかまいません。パスワードは良く出てくる話題であり、非常に繊細な情報を保護するために使用されるので、興味を持つには適した分野だと思います。今日の、オペレーティング システムおよびアプリケーションはパスワードありきに構成されるものであり、たとえスマート カードやバイオメトリクスのシステムを使用していたとしても、すべてのアカウントは依然としてパスワードを備え、ある状況において使用することができます。特にサービスなどを実行するようなアカウントは、スマートカードやバイオメトリクスのトークンですらも使用することができません。従って、認証にはパスワードの使用が必要です。

人々は、パスワードに関して同じ質問を何度も繰り返します。そのうちの何人かに一度に回答するために、「よく寄せられる質問 (FAQ)」 を書く意味があると思いました。ここでお答えできない問題については、私のブログ (英語情報) お答えできるかもしれません。 必要な場合には、新しく出てきた基本的な新しい知識を反映するために、このコラムを更新します。

パスワードおよびパスワード攻撃に関する「よく寄せられる質問」

パスワードは Windows にどのように保存されるのですか?

Microsoft Windows のオペレーティング システムは、異なる目的のために多くのさまざまな方法でパスワードを保存します。Active Directory のドメインが含まれる Windows のネットワークで使用するために、パスワードは LM OWF および NT OWF として 2 種類の異なる方法により既定で保存されます。OWF は一方向関数という意味で、あるデータの一方向の数学的変換を表します。処理されるデータは判読しにくい形になるように一方向でのみ変換されます。この判読しにくい形のデータは、もとの形に戻すことはできません。ですから、一方向関数という言葉を使用します。 使用される OWF の最も一般的な形は、暗号化ハッシュです。ハッシュは一連の小さなデータで、より大きい一連のデータに数学的に関連しています。そのより大きい一連のデータからハッシュを計算します。もし、より大きな一連のデータが変更された場合、より小さな一連のデータ (つまりハッシュ) も変わります。ハッシュは便利です。例えば、データが通信で変更されなかったと確認するためのチェックサムとしても使用されます。暗号化ハッシュは、特定のプロパティを満たします。例えば、暗号化ハッシュは、大きなデータのセットをハッシュだけで推測するためには、妥当な時間をかけて、数学的に実行不可能な方法で作成されなければなりません。このように、同じハッシュを生み出す 2 種類のデータ セットを見つけるのは数学的に不可能です。

LM OWF は実際にはハッシュではありませんが、NT OWF は「NT hash」を生成するので、その出力は一般に「LM hash」と呼ばれています。その簡潔さのために、正確に示す言葉ではないかもしれませんが、「ハッシュ」という言葉を使用してそれぞれを示します。OWF という言葉は、ハッシュを計算するために使用する機能を意味しています。

一方向関数には多くの異なる種類があります。定義によると、すべてのハッシュの機能は一方向です。しかし、一般的に可逆な、普通の暗号関数は、一方向関数を作り出すために使用できます。これは、データのやりとりにより行なわれ、暗号機能における鍵となり、キーとしてデータを使用して、固定値であるキーを暗号化します。これが、LM ハッシュがコンピュータで計算される方法です。LM ハッシュは以下のように計算されます。

図 1 が示すのはこの全プロセスです。

図 1

LM OWF のアルゴリズムは、現在 20 年以上たっています。最初はオペレーティング システムの LAN マネージャ製品群で使用するために作られました。そしてソフトウェアの下位互換性および新たなアルゴリズムを使用できないハードウェアのために最近の Windows のバージョンにも含まれています。NT ハッシュは基本的にハッシュです。パスワードは MD 4 のアルゴリズムを使用してハッシュされて保存されます。NT OWF は Windows NT 4.0 とそれ以前のドメイン、Windows 2000 とより高度な Active Directory のドメインの両方で、ドメインのメンバによる認証に使用されます。

NT OWF のプロセスは図 2 に表示されています。

図 2

NT ハッシュも LM ハッシュもソルト処理されません。ソルト処理は、最初に UNIX ベースのコンピュータで 20 年以上前に使用されました。これらのコンピュータで、パスワードのハッシュ値は誰からも読み取れるファイルに保存されました。ユーザーはファイルから、同じ保存されたハッシュを持つほかのユーザーを簡単に検索することができます。どれかが見つかった場合、彼らが同じパスワードを共有していたことになります。この問題を解決するために、 UNIX のオペレーティング システムの設計者はパスワードを保存する前にソルト処理をすることに決めました。ソルト処理のプロセスは、OWF を算出する前にパスワードと小さい数を組み合わせます。ソルトはパスワード ファイルのクリア テキストに保存可能です。これにより、同じパスワードを持つ 2 人のユーザーが、2 つの異なるパスワード情報を保存できました。Windows は、誰からも読み取れる形式でハッシュを保存しません。そのためにソルト処理する必要がありません。

また、ドメイン ユーザーがドメイン メンバにログオンした際に、Windows は、ドメイン メンバでパスワードを検証する方法を備えています。この検証方法は、コンピュータがドメイン コントローラにアクセスできない場合に、ドメイン ユーザーを認証するために使用できます。Windows XP では、パスワードの検証方法はコンピュータがコールド ブートされる際に、ドメインのログインをすばやく行なうために使用できます。このパスワードの検証方法は、一般的には、キャッシュされた資格情報と呼ばれています。これは、NT ハッシュにユーザー名を連結し、MD4 ハッシュ関数でハッシュ化します。

内部的には、Windows は 256 文字の UNICODE のストリングでパスワードを示します。しかし、ログインのダイアログは 127 文字に限定されています。従って、Windows を実行しているコンピュータへの対話的なログオンに使用可能なパスワードは、最長で 127 文字です。理論的に、サービスのようなプログラムはより長いパスワードを使用できます。しかし、プログラム的に設定される必要があります。なぜなら、パスワードの変更ダイアログは 127 文字より長いパスワードを許可しないからです。

Windows で使用されるパスワードはどうですか?

ユーザーがログインした際に、ユーザーが入力したパスワードは OWF の両方の種類に変換され、LSASS のプロセスによるメモリに保存されます。もしユーザーがローカル アカウントを使用して認証していたら、NT OWF はローカルで保存された NT ハッシュに対して比較されます。そして、2 つが適合すれば、ユーザーはログオンできます。もし、ユーザーがホスト名を使用して、リソースにアクセスし、Active Directory のドメインに対して認証を行なっていたら、NT ハッシュは キー配布センター (KDC、一般的にはドメイン コントローラ) に対して Kerberos ログオンに使用されます。パスワードの検証方法は LSASS ではなく WINLOGON により計算されます。

ある状況では、Kerberos を使用することができません。以下のリストは、ほかのプロトコルを使用しなければならない場合を示しています。

これらの状況で、認証プロセスは LanMan および NTLM と呼ばれる 2 種類の異なるプロトコルを使用します。このプロセスは、認証サーバーからチャレンジを要求するクライアントにより始まります。一旦チャレンジを受け取ると、クライアントはこのチャレンジに対して応答を計算します。これは最初に2 種類のパスワードのハッシュをNULLでパディングして （それぞれ） 168 ビットにします。それぞれのハッシュの 168 ビットは 56 ビットの 3 つのチャンクに分かれます。それは、DES キーとしてそれぞれ使用可能です。 6 つの DES キーはチャレンジを暗号化するために使用されます。LM ハッシュを使用してできた 3 つの暗号文は連結され、LanMan レスポンスになります。NT ハッシュを使用してできた 3 つの暗号文は統合され、NTLM レスポンスになります。

応答を計算するために使用される機能は、マイクロソフト サポート技術情報 147706 (LMCompatibilityLevel は、Network セキュリティとしてグループ ポリシーに示される: LAN マネージャ認証レベル) で取り上げた LM の互換性レベルの設定により変更される場合があります。もし、その値が 1 またはそれより低く設定されていたら、クライアントは元の LanMan および NTLM 応答を送ります。もし、値が 2 に設定されていたら、NTLM 応答だけが送られます。もし、3 またはそれ以上に設定されていたら、両方のプロトコルの新しいバージョンが使用されます。NTLM のバージョンは NTLMv2 と呼ばれます。LanManager のバージョンは、しばしば LMv2 とされます。両方のプロトコルは応答を計算するために、NT ハッシュを使用します。そして両方が、サーバーのチャレンジの代わり、またはそれに加えてクライアント側のチャレンジを使用します。さらに、LM 互換性のレベル設定が 1 またはそれ以上に設定されていた場合、NTLM 応答はリレー攻撃を防ぐために記録されます。これが、表 1 に示されています。

表 1 クライアント側の LM 互換性レベルの影響

サーバーは特別な順番で応答を評価します。また LM 互換性レベル設定により管理されています。Windows NT 4.0 Service Pack 4 以降のすべてのサーバーはまるで NTLMv2 を使用して計算されるように NTLM 応答を評価することにより起動します。もしこれが失敗して、LM 互換性レベルが 4 またはそれ以下に設定されたら、サーバーは通常、NTLM 応答を元来の NTLM 応答であるように評価します。これが失敗し、サーバーが LM 互換性レベル 3 またはそれ以下に設定されていた場合、LanMan 応答を評価します。これらがどれも合わない場合、または LM 互換性レベルの設定がサーバーの LanMan および/または NTLM 応答の評価を妨げる場合、ユーザー名またはパスワードに問題がある旨のエラー メッセージで、認証は失敗します。これを表 2 に示します。

表 2 サーバー側の LM 互換性レベルの影響

注意していただきたいのは、LM 互換性レベル設定のサーバー側またはクライアント側の影響に関して話す場合、クライアントまたはサーバーとして動作するすべての Windows (または互換性のある) のコンピュータの影響を意味していることです。設定に関して非常に紛らわしいことのひとつに、「ドメイン コントローラの設定」と言う言葉でしばしば述べられるものがあります。実際は、サーバー側は認証データベースを持つすべてのサーバーに適用します。例えば、もしコンピュータの SAM に定義された権限を使用して Windows XP Professional を実行しているコンピュータに接続した場合、それはサーバーとして動作し、サーバー側の設定がその動作を導いているのです。

Windows NT 4.0, Service Pack 4 およびそれ以降、Windows 2000、さらに 32-bit editions of Windows XP は LM 互換性レベルを既定で 0 に設定します。Windows Server 2003 および Windows XP 64-bit edition は既定で 2 に設定します。

LMCompatibilityLevel を変更した場合、何が切断されますか?

コンピュータの LMCompatibilityLevel を変更した場合、多くが切断されます。もし、着信 NTLMv2 (つまり level 5) が必要な場合、以下が切断されます。

もし、みなさんが LMCompatibilityLevel を 3 またはそれ以上に設定していたら、SMB サーバーを搭載したサード パーティのハードウェア機器の問題に直面する可能性があります。これらの多くが NTLMv2 を使用した着信トラフィックを認証できません。従って LMCompatibilityLevel を 3 またはそれ以上に設定した場合に切断することになります。

パスワードはどのように攻撃されるのですか?

いくつかの考えられるパスワードの攻撃方法があります。最も簡単な方法は、おそらく最も効果的なものです。もし、みなさんが誰かのパスワードを知りたかったら、ただ尋ねてください! 2004年の調査 (英語情報) で質問を受けた 70% の人がパスワードと引き換えにパスワードが保護している組織的な機密以上の価値があるとする、クレジット カードの情報、銀行口座番号または資産などと引き換えにすると答えています。取引のために、チョコレートを価値のある資産として使用した調査に関しては、http://news.bbc.co.uk/1/hi/technology/3639679.stm (英語情報) をご覧ください。

この調査はまさに重要なポイントを際立たせています。パスワード ベースのセキュリティ システムにおける最も脆弱なつながりは人です。事実、かつて私が冗談半分でお話した、パスワードの問題を解決するには人を排除することであるということです。パスワードは、セキュリティの提供に失敗しています。なぜなら、人々は頻繁に弱点のあるパスワードを作成したり、うっかりまたは故意にそれを手放したりするからです。とはいえ、問題の大部分はパスワード ベースのコンピュータに対する絶対的な過負荷と、ほとんどの人がパスワードの管理方法を学んだことがないという事実です。しかし、そのトピックはほかのコラムのためのもので、おそらくより社交術を身に付けた方が書かれる方が良いでしょう。

パスワードの技術的な攻撃方法を純粋に見てみると、最初に、ログオンのプロンプトからローカルあるいはリモートで推測することです。このアプローチは非常にお粗末なパスワードに対して成功します。そして非常に時間がかかるものです。パスワードが攻撃者にとって無作為である場合、その攻撃は可能性のあるパスワードが標的となるパスワードと一致するようにひとつひとつ無作為に送ります。従って、統計的には攻撃者は、正しいパスワードに一致する可能性のある、すべてのパスワードの半分を試さなければなりません。もちろん、最初に試したパスワードが標的となるパスワードに一致する可能性もあります。しかし、単語や特に短いパスワードでない場合には、その可能性はほとんどありえない確率 (可能性のあるパスワード数分の 1 の確率) です。従って、パスワードが任意で 8 文字選択され、4 種類 (大文字、小文字、数、記号) のうち少なくとも 3 種類を使用して構成されている場合、パスワード推測攻撃はツールの速さに応じて 1,500 年から 140 万年かかります。低い数字は私の知っている中で、最速のものをベースにしており、一秒間に 1,700 の推測が可能です。

パスワード攻撃の 2 番目の方法は、チャレンジ・レスポンスのペアを入手し、クラックすることです。クラックは一般的な言葉であり、基本的に、パスワードを推測しようとする多くの異なる方法が含まれています。これらの方法のすべては試行パスワードの作成、本物が実行されるであろう同じアルゴリズムでの実行、そして入手した値と結果の比較などによるものです。例えば、攻撃者が LanMan のチャレンジ・レスポンスのペアを入手した場合、パスワードが password1 であると推測して始める可能性があります。この場合、攻撃者は password1 の LM ハッシュをまず計算します。それから、サーバーにより送られたチャレンジと LM ハッシュ を使用して、応答を計算します。この応答がクライアントの送信したものと一致した場合、パスワードが見つかります。もし違う場合は、このプロセスを新たな試行パスワードで初めから行います。この種類のクラックは、パスワード推測攻撃よりも非常に早く行なうことができますが、依然時間を消費するものです。LM ハッシュは、異なる 5 つの DES 関数計算を用います。それぞれは非常に遅いものです。速いコンピュータは一般的には、最適化されたアルゴリズムで、1 秒間に約 3 百万の LanMan のチャレンジ・レスポンスのペアを計算します。LanMan のチャレンジ・レスポンスの計算で使用されていた場合、上で触れた 8 文字のパスワードを解読するのには、攻撃者が単にすべての可能性のあるパスワードを試す総当り攻撃を使用して約 3 年かかります。同じコンピュータは 1 秒間に約 150 万の NTLMv2 または LanManv2 のチャレンジ・レスポンスのペアを計算可能です。NTLMv2 および LanManv2 のチャレンジ・レスポンスは、大文字と小文字を区別しているハッシュを使用しているので、解読までの時間はこれらのプロトコルを使用して 70 年まで増加します。

NTLM のチャレンジ・レスポンスのクラックは、文字セットおよびパスワードの長さによって実際よりも早くなる可能性があります。NTLM のチャレンジ・レスポンスは、3 種類の DES の計算と MD4 のハッシュがひとつです。MD4 のハッシュを計算するのは、DES の暗号を計算するよりずっと早くできます。しかし、NTLM のチャレンジ・レスポンスは大文字小文字を区別したハッシュを使用して計算されます。つまり、考えられる選択はより多くなります。大まかな計算では、同じコンピュータで 1 秒間に 450 万の NTLM チャンレンジ応答のペアを試行できます。その結果、解読するのに 8 文字のパスワードで 23 年間必要となります。

第 3 番目のパスワードの攻撃方法は、ハッシュを保存しているコンピュータに侵入することです。そして、これらのハッシュはチャレンジ・レスポンスのペアを入手した場合と基本的に同じ技術を使用してクラックされますが、使用される計算量はかなり減少されます。8 文字のパスワード例を使用して LM ハッシュの全スペースを総当りするのに 6 日しかかかりません。これは、不十分です。なぜなら動作するための DES の計算は 2 種類しかないからです。しかしスピード アップの大部分は LM ハッシュが 8 文字のパスワードを 7 文字のパスワードひとつと、1 文字のパスワードひとつとして保存したことです。この 2 つは別々にクラックされる可能性があります。8 バイト チャンクとして保存されたパスワードは解読に 1 年以上かかることになるでしょう。

Rainbow tablesとは何ですか?

古い攻撃に関する新たな展開は、2004 年に起こりました。長年の間、セキュリティの分析家は、クラッカーが入手したハッシュをすでに既存のパスワードから計算されたハッシュと単純に比較した場合、クラックの時間が桁違いに短くなるだろうと認識してきました。事前計算によるハッシュ攻撃として知られるこの攻撃は、パスワードがソルト処理されていない場合のみ行なわれます。さもないと、同じパスワードが多くの異なるハッシュを持つことになるのです。もし、この方法が上手くいけばかなりの時間短縮になります。最初のこのような攻撃が実行されたのは、おそらく 1988 年 の Quakenbush Password Appraiser と呼ばれた製品であったと思います。このアプローチでの問題は、多くの計算された OWF の保存場所が必要となることです。そして、すべてを計算するのに多大な時間がかかるのです。2004 年に Philippe Oechslin が前の問題の解決策を発見しました。すべてのハッシュを保存する代わりに、Rainbow table はハッシュを作ると知られているパスワードとハッシュの 1 部分を保存します。クラッカーは現在、単純に保存されているハッシュの一部を見て、そのハッシュを作り出すものであると知られているパスワードのためだけにハッシュを計算します。このアプローチは大幅にクラックのスピードを短縮しました。あまり完成度の高くない攻撃でさえ、57 日間とかからず、1 時間内に解読されてしまいます。このアプローチは RainbowCrack のツールに使用されました。

Rainbow tables は LM ハッシュ および NT ハッシュに関して同じように上手くいきます。NT ハッシュに必要な保存場所である caveat は 8 文字より長いパスワードのためのハッシュが望まれる場合、LM ハッシュよりも桁違いに大きなものになります。しかし、LM ハッシュの保存はほとんどのユーザーが使用可能な範囲内にあります。英数字の keyspace から計算した LM ハッシュの Rainbow tables のセット、そして米国英語のキーボード上にある 14 の記号を保存するには約 17 GB です。米国英語のキーボードの全文字域から計算した LM ハッシュの Rainbow tables のセットは保存に約 47 GB 必要です。

Rainbow tables は依然として、計算に長い時間がかかります。巨大な数字の計算が必要とされており、最適化された好ましいツールは現在ありません。ツールがさらに向上すれば、その機能に多くの改善が期待できるはずです。それに加えて、Rainbow tables は過去 1 年にわたりオンライン ショッピングで購入できました。そして、さまざまなファイル共有サービスのユーザーは現在、サービスで一般的に利用できる音楽、映画およびソフトウェアと並んで Rainbow tables をダウンロードできます。実際、多くのセキュリティの研究者がテーブル作成をより早く行なうための改善された作成技術を開発しました。

クラックを心配するべきですか?

答えは、条件付きのノーです。入手したハッシュに対するクラックは興味深い攻撃ではありません。ハッシュは Windows およびほかのオペレーティング システムの両方における、今日のチャレンジ・レスポンスのプロトコルで使用される唯一の秘密です。ハッシュを持った攻撃者はユーザーとして認証されるためのすべてを持っているので、クラックはただの時間の無駄です。pass-the-hash 攻撃として知られているこの種類の攻撃を行なうツールは、インターネットですでに利用できます。ツールは依然として比較的不安定で、信頼しにくいので、パスワードがより強化されたらその品質も著しく改善することが予想されます。さらに、ハッシュを入手するために、攻撃者は認証サーバーに侵入しなければなりません。それは一般的に Windows ベースのネットワーク上のドメイン コントローラです。これが起こった場合、ネットワークはすでに完全に侵害されており、パスワードのクラックは同じユーザーが同じパスワード (絶対に避けるべき行動です) を使用しているほかのネットワークを攻撃するためにのみ役立つだけです。Windows は、暗号化されていないチャンネルにあるネットワーク上を決してハッシュに通過させません。従って、ネットワークの転送でハッシュを入手することはあまりあり得ません。

2005 年 1 月以来、保存されたパスワード検証方法 (キャッシュされた資格情報) に対するクラックは、侵害されたコンピュータから検証方法を得るため一般に利用可能なツールが公開されたために、新たな利点を得ることになりました。パスワードのクラックは、NT ハッシュに対するよりも、およそ 3 倍長くかかるので、かなり効果があります。しかし、これもあまり興味深い攻撃ではありません。まず、検証方法は少なくとも元のハッシュの倍の回復機能があるハッシュです。次に、パスワード検証方法はユーザー名でソルト処理されるので、2 人のユーザーが同じパスワードを使用しているのでさえ珍しいことです。事前に計算されたハッシュ攻撃は最初の計算をスピード アップするために使用されることが可能なので、2 番目のハッシュに対しては役に立ちません。最後に、パスワード検証方法は、非常に重要な目的を果たします。それなしでは、ドメインから切断されている時には、ドメインの権限を使用する場合に、コンピュータにログオンする際には、ユーザーはローカルの権限を使用しなければなりませんが、接続している場合にはドメインの権限を使用しなければなりません。明らかに、このプロセスはユーザーにとって不快なものです。しかし、より重要なのは、入手したハッシュに関する影響です。大多数のユーザーが両方のアカウントに同じパスワードを使用していることは、ほとんどのセキュリティの研究者が同意するだろうと思います。攻撃者がローカルの権限を持ち、それがドメインの権限を一致するコンピュータを侵害した場合、攻撃者は、ユーザーとしてドメインに認証されるために必要な情報をすべて持ち、ひとつもパスワードを破る必要がなくなるのです。ローカル アカウントのためにローカルで保存された OWF の代理は 2 つが同じパスワードを持っていた場合、ユーザーのドメイン アカウントに保存されたものと同一のものになります。明らかに、人間とコンピュータの対話の力学が意味するのは、パスワード検証方法がおそらく減少させる代わりにセキュリティを強化させるであろうということです。従って、パスワード検証方法に対する攻撃もまた興味深いものではないのです。

しかし、入手したチャレンジ・レスポンスのペアに対するクラックは依然として興味深い攻撃ですが、LM の互換性レベルのスイッチを使用して、LanMan のチャンレンジ応答のペアを送信しないで効果的に無効にすることが可能です。これは、ほとんど全ての環境で有効なアプローチです。LMCompatibilityLevel の問題のいくつか (すべてである可能性は低いです) は上に挙げられたものです。これらの問題の影響を受けない場合は、LMCompatibilityLevel を 5 に設定することを推奨します。

なぜ、そんなに影響を受けるのに LM ハッシュは保存されるのですか?

LM ハッシュは下位互換性のために保存されます。多くの環境はもはやそれを必要としません。そしてその値の保存を無効にすることができます。マイクロソフト サポート技術情報 299656 ではこの動作を設定するために使用できるレジストリ値について取り上げています。これは入手した LM ハッシュを侵害された認証サーバーの攻撃から防ぎます。しかし、これは一連の認証中にコンピュータが LanMan のレスポンスを送信することを防ぐものではありません。サポート技術情報 299656 で取り上げているレジストリ値の設定に加えて、LM ハッシュの保存は 14 文字より長いパスワードの使用またはパスワードに特定の Unicode の文字を使用することにより防ぐことができます。どの Unicode の文字が LM ハッシュに保存されなくなるかについては、今回のコラムの範囲外ですが Johansson および Riley による Windows 2000 Security Hardening Guide (英語情報) と Protect Your Windows Network (英語情報) の両方で詳細について取り上げられています。

実際のところ、LM ハッシュに保存されないというセキュリティの意味は、高度な技術に熟達した攻撃者の前では取るに足らないものだということに注意してください。これを防ぐ唯一の攻撃は侵害された認証サーバーから入手した LM ハッシュのクラックに頼っているものだけです。上述したように、そのようなハッシュのクラックは巧みな攻撃者にとっては時間の無駄と考えられるはずです。まず、NT ハッシュはクラックなしにユーザーとして認証するために絶対に必要です。実質的な意味では、LM ハッシュを使用して保存された 1 文字のパスワードと NT ハッシュを使用して保存された高度に複雑な 127 文字のパスワードにおけるセキュリティの価値に関する違いはありません。両方ともユーザーとしての認証に必要なハッシュを作り出します。そしてもし LM の互換性レベルの値が標的となるサーバー上で 4 またはそれ以上に設定されていたら、どちらにしても LM OWF は役に立ちません。

パスワードを守るために何をすべきですか?

パスワードを保護するために最も重要なことは、良いパスワードを使用することです。良いパスワードは、入手したハッシュを使用した攻撃を除く、上のすべての攻撃に勝ります。ハッシュを使用した攻撃を失敗させるのは、認証サーバーを適切に守ることだけです。良いパスワードの特徴は以下の通りです。

このすべての条件、そして私たちすべてが多くの異なるパスワードを持っているとして、そのパスワードが長く、複雑で一度しか使用されないなどというものであった場合に、どうやってそれらすべてを記憶するのでしょうか? 残念なことに、セキュリティの業界はパスワードを書き留めるのはセキュリティの侵害であるという概念が残っています。これは事実とまるでかけ離れています。パスワードを書き留めるのは、書き留めたものを十分に防御する限り、素晴らしい考えです! そうすることでより多くの優れたパスワードを覚えておくことができます。従ってセキュリティの鈍化ではなく強化となるのです。もちろん、ポストイットに書き留めてモニターに貼っておくようなことは、双眼鏡攻撃の影響を受けることになります。しかし、ポストイットに書き留めて財布に入れておくのは、かなり良く防御されていることになります。パスワードを管理するソフトウェア製品は豊富です。ほとんどは、作成したパスワードを単に保存するものです。その多くは、Web サイトで自動的に入力します。優れた製品のいくつかは、みなさんのために実際にパスワードを作成するもので、そのパスワードは平均的な人間が作成するより複雑なものになります。進行中に、既知の入力からパスワードを作成するものもあります。そして何も保存する必要はありません。これらのツールにある基本的な考え方は、すべてのコンピュータを守る 1 つの秘密を保持するための機能を維持する間、どのコンピュータにもその秘密が公開されないというものです。そのようなツールのひとつが Protect Your Windows Network (英語情報) にあります。

スマート カードを使用することは、複雑なパスワードよりもより優れた考えでさえあります。Windows 2000 以降の Windows のバージョンは Active Directory のドメインへのログオンにスマート カードを使用する機能があります。スマート カードについての完全な議論は、このコラム外の話です。しかし、注意すべき重要な事実がひとつあります。対話的なログインにスマート カードが必要な場合でさえ、それぞれのユーザーは依然としてパスワードを持ち、ネットワークのログオンの目的のために使用されることができるのです。この先 10 年の間に完全にパスワードのない使用可能なコンピュータを見る可能性はほとんどないと言ってもよいでしょう。そして電子メールや Web サイトのサービスが何百万あったとしても、パスワードが使用され続けるでしょう。明らかに、パスワードにつきもののリスクおよびそのより良い使用方法を学ぶことは価値のある努力です。

パスフレーズについては?

約 1 年前、パス フレーズはパスワードより優れているのかに関してコラムを書きました。このコラムでは原則的に、パス フレーズはパスワードよりも優れていると考えていると述べましたが、科学的な証拠はありません。

こちらでわかっているのは、みなさんがパスワードに置き換えた文字を使用する傾向があるということです。つまり、文字を別の文字に置き換えるのです。例えば、s を $ に置き換えます。最初にこの考えを思いついた時、何て自分は賢いのだろうかと思いました。攻撃者達はすでにその時までにこれを思いついていた訳ですが。もし、みなさんのパスワードが Seattle1 であったら (ところで、これは固有のルールによると、複雑なパスワードになります)、s に置き換える $ はひとつだけです。そして正しいパスワードを見つけるためには、攻撃者は 2 種類のパスワードをチェックするだけです。

しかし、みなさんのパスワードが私のパスワードに使用しているような非常に強力なパス フレーズであったらどうでしょう? 大文字と、いくつかの小文字そして記号が含まれているので、これもまた複雑なものです。また、s が 9 文字があります。みなさんがひとつ以上の文字を $ で置き換えたと疑う攻撃者は正しいパスワードを見つけるために、512 の組み合わせを試さなくてはなりません。パス フレーズはパスワードにおいて非常に重要な利点があります。桁が多くなることにより、文字の置き換えの価値が増大します。

パス フレーズは、フレーズでない場合に覚えられるよりも長いものが覚えられます。パスワードを長くすることは、それを強力なものにするための基本的な要素です。以前のコラムのシリーズでいくつかパス フレーズを依頼しました。その多くにはスペースがなく、単につながっているもので、長いものでした!平均的な長さはだいたい 31 文字でした。それを前述のコラムのシリーズにある、以前の研究による平均的な 9 文字の長さのパスワードと比較します。75 % のパス フレーズが基本的に個人的なことを表すものでした。つまり、それに関するソースを認識することが出来なかったということです。次の最大のカテゴリは文学作品です。これは、少なくともパス フレーズの 6 % に上ります。

パス フレーズの使用における、別の良い点は、簡単に覚えることが出来て、事実上誰でも使用できるということです。私は、一番上の子供が 6 才の時にパス フレーズを使わせました。K%Dsi&7e の様なパスワードを試してみてください。これでも、彼が使っているパス フレーズほど強力ではないのです。

サービスアカウントのパスワードについてはどうすれば良いですか?

サービス アカウントは興味深い状況を生み出します。ほとんどの場合、サービス アカウントに必要なパスワードは対話的でなく、プログラム的に使用されるだけです。つまり、実際には、対話的に使用されるパスワードよりも非常に強力である可能性があります。例えば、グラフィカルなログオンのインターフェイスのダイアログ ボックスは、127 文字までのパスワードをサポートするだけです。しかし、Windows 2000 とそれ以降のバージョンでは、内部的には 256 文字の長さまでのパスワードが許可されます。ほとんどのサービス アカウントのように、プログラム的のみに使用される必要のあるアカウントに関しては、対話的に使用されることのできないパスワードを設定するために、実際にこれを利用可能です。パスワードが人間に入力される必要のない場合、それが許可されている限り、設定しないという理由はありません。注意しておいていただきたいのは、GUI で 127 文字より長いパスワードは設定できないということです。そうするために、NetUserChangePassword または NetUserSetInfo API を直接に呼ぶツールが必要です。GUI にのみ長さの限度があり、API にはありません。

第 2 番目のサービス アカウントの特別な問題点は、一般的に言って、サービス アカウントのパスワードの有効期限が切れて欲しくない、または、ロックアウトされたくないことです。パスワードの有効期限が切れた場合、またはアカウントがロックアウトされた場合は、そのアカウントを使用しているサービスは始まりません。従って、必ずサービス アカウントでパスワードの期限を無効にしなければなりません。その代わりに、定期的にこれらのパスワードの変更のプロセスを持つべきです。アカウントのロックアウトの懸念については下記で述べています。

サービス アカウントに関して覚えておく最後の点は、パスワードというよりアカウント自身に関することです。攻撃者がサービス アカウントを使用している特定のコンピュータを侵害した場合、攻撃者はそのサービス アカウントのためのパスワードにアクセスします。つまり、攻撃者は今、そのサービス アカウントを信用しているほかのコンピュータを侵害することになるのです。これは、サービス アカウント依存と呼ばれます。しかし、サービス アカウントのパスワードに特に関係していませんので、興味のある方は Protect Your Windows Network の、8 章でこの問題を深く取り上げていますので、ご覧ください。

ビルトインの Administrator アカウントのパスワードをどう管理すれば良いのですか?

ビルトインの Administrator アカウントに強力なパスワードを設定すべきなのは、誰でも知っていることです。しかし、そのアカウントの使用の許可を受けたいかどうかでさえも疑問であるかもしれません。通常これは、コンピュータが設定された後に必要でありません (注: Windows Small Business Server は注意すべき例外です。そのプラットフォームではビルトインの Administrator アカウントは必要ありません)。アカウントが必要でない限りは、コンピュータの設定を完了した後、それを無効にすることができます。コンピュータを管理するすべての人は、独自の管理者のアカウントを持つべきです。彼ら全員がビルトイン アカウントを使用している場合、彼らが行なっていることを監視する方法はありません。(みなさんは、実質的に承諾すれば、管理者である彼らを監視できることに留意してください。もし、彼らが望めば、監視のエントリを無効または変更できるのです。結局のところ彼らは管理者なのです。)独自の管理者アカウントを使用しなければ、みなさんは管理者のすべての責任を失います。

また、ビルトインの Administrator アカウントに独自のパスワードを設定することが重要です。今日ほとんどの組織はそれを行なっていません。我々は、クライアントやサーバーを構築する規準のスクリプトを持っています。そしてそれらすべてに、ハードコードされたパスワードが含まれています。最終的に、その環境にあるすべてのコンピュータはローカルの Administrator アカウントに同じパスワードを持ちます。これらのコンピュータのうちのひとつでも侵害されたら、攻撃者はこのパスワードのハッシュを持ちます。そのハッシュはそのアカウントで同じパスワードを使用するほかのコンピュータにログオンするために使用可能です。これはまさに、攻撃における最大の恩恵の本質です。すべてのネットワークはネットワークで最もセキュアでないコンピュータよりもセキュアではありません。我々がしなければならないのは、それぞれのコンピュータのビルトインの Administrator アカウントに独自のパスワードを設定することです。これを行なうのは複雑ですが、非常に価値のあるものです。直接の経験はありませんが、User Manager Pro (英語情報) がこれを行なうみなさんの助けになると教えられました。

また、パスワードを設定できるコマンド ラインのツールも使用可能です。もし、アカウントを使用したければ、パスワードを回復させることができるはずです。つまり、それを書き出すかそれを回復させられるツールを使用するということです。そのようなツールのひとつに Protect Your Windows Network (英語情報) にあるパスワード ジェネレータがあります。これはネットワーク上で一般的なアカウントやサービス アカウントに疑似乱数のパスワードを設定するように設計されました。パスワードは完全に乱数または既知の 2 種類の入力を基にできます。コンピュータまたはアカウントの独自の識別子、そして一般的なパス フレーズです。一般的なパス フレーズは世界的な秘密ですが、その秘密で守られたどのコンピュータにも保存されていません。従って、数千のコンピュータ上の管理者のパスワードを守るよりもずっと容易です。

ローカルの Administrator アカウントでパスワードなしで使用しようと考えるかもしれません。サーバーでは特に、ラックによって物理的にセキュリティで保護されていますが、これは合理的なオプションです。既定で、Windows XP および Windows Server 2003 はネットワーク上でパスワードのないアカウントへのログオンを許可しません。サーバーが物理的にセキュリティで保護されていて、この機能が無効にされていない限り、ネットワーク上では使用できませんが、必要であればローカルで使用可能なローカルの Administrator アカウントを持つことができます。

アカウントのロックアウトを何に設定すべきですか?

スイッチをオフにするべきです。アカウントのロックアウトは、ある一定の回数、誤ったパスワードでログオンをしようとした後にアカウントが締め出される機能です。脆弱なパスワードに対してコンピュータを保護するために設計されたものです。その脆弱なパスワードの問題は、アカウントのロックアウトに関係なく、どちらにしても最終的に攻撃を受けるということです。賢い攻撃者は、アカウントのロックアウトを招かない方法で単に攻撃を変更するのです。アカウントのロックアウトが使用された場合、脆弱なパスワードはそのような攻撃に対して長く抵抗しますが、やはり最終的に破られてしまいます。

さらに、アカウントのロックアウトにより、さほど洗練されていない攻撃者であってもコンピュータを完全に無効にするのを、些細なことにしてしまいます。簡単なバッチ ファイルはコンピュータのすべてのアカウントのロックアウトに使用されることが可能です。その結果、機能が損なわれることになりました。アカウントのロックアウトは、脆弱なパスワードを保護するために設計されましたが、その代わりにくだらないサービス拒否攻撃が行われれてしまうという状況を生み出しました。

アカウントのロックアウトは、少なくとも Windows では、オール オア ナッシングの設定です。アカウントのロックアウトを受けるために、特定のアカウントだけを選択することはできません。つまり、悪いパスワードを持つ特定のアカウントのみを保護したい場合は、すべてのアカウントのロックアウトを有効にしなければなりません。これによりコンピュータのすべてのアカウントが先に述べたサービス拒否の脆弱性にさらされることになります。例えば、コンピュータのアカウントのロックアウトが有効にされ、攻撃者がサービスを始動するために使用するアカウントをロックアウトした場合、サービスは始まりません。これによりアップタイムだけでなく、アカウントが経営または収益を上げるために使用されていた場合は、組織の経営目標と収益源において、悲惨な結果となる可能性があります。

脆弱なパスワード問題に対する真の解決策は、より優れたパスワードを使用することです。上で指摘したように、優れたパスワードを考え出し、アカウントのロックアウトを強制する環境でパスワードが完全に不必要になるには数千年かかります。さらに、アカウントのロックアウトはしばしばヘルプデスクへの問い合わせを必要とします。これら問い合わせの費用はそれぞれ 30 ドルから 70 ドルの間と見積もられます。

ある議論では、人から自分自身を守るためにアカウントのロックアウトが必要であると言います。なぜなら、我々が何をしたとしても人々が常に悪いパスワードを選択するからです。その人達自身の意思に任せるとおそらくそうなるでしょうが、それを防ぐために制限を導入することが可能です。パスワードのポリシーは強力なパスワードを主張します。もし、みなさんが望むのであればより強力な制限でさえも行なうためにパスワード フィルタを使用可能であり、人々に辞書の単語を使用させない、また辞書の単語の置換でさえも行なわないように制限します。別の人達のパスワードが優れたものであると信用できない場合は、スマート カードまたは RSA SecurID のような別の認証トークンのようなものを使用して優れたパスワードを得ようとするのを防がなければなりません。人々が優れたパスワードを選択しないという恐れのために、アカウントのリセットのためにヘルプデスクの予算のかなりの部分を費やすことになる前に、問題を注意深く考えてください。結局、脆弱なパスワードはやはり失敗するのです。正しい解決策は人がそれを使用しないように教えることです。

人は一番弱い部分であり、最強の防御です。

人々が最低限セキュリティ志向であるように実際に訓練することができるという考えにおいて、私は楽観的です。 現在、その因子から人を取り除こうと試みるスマート カードのような技術的な解決策があります。また、これらの解決策はネットワークの安定性を侵害することなしに行なうアカウントのロックアウト対策の必要性を取り除きます。問題は、多くのアプリケーションがそれらをサポートしていないので、スマート カードは完全な解決策ではないことです。前に言及したように、アカウントは常にパスワードを持ちますが、スマート カードを使用できないアカウントもあるということです。にもかかわらず、スマート カードの使用は問題のいくつかを緩和します。つまり、依然としてアカウントのロックアウトよりましだということです。しかし、これらの技術的な対策のどれも人を悪用するソーシャル エンジニアリング攻撃に対して効果がないのです。チョコレートのためにパスワードを引き換えにする人は、攻撃者に対する値段は高くなるでしょうが、おそらくチョコレートのためにスマートカードも引き換えにするでしょう。最終的に、すべての人的コンピュータ システムにおいて人が弱い部分となるのです。そして、攻撃者は人への攻撃において徐々に熟練していくのです。

アカウントのロックアウトをオンにする必要があるというすべての意見を含む、現在一般的に受け入れられているパスワードに関する見識の多くは、人に優れたパスワードの使用を訓練できないという仮定に基づくものです。しかし、推測攻撃に対して回復力のあるパスワードの使用を訓練させることができなかった場合、最初に尋ねた人に対してパスワードとチョコレートを交換しないように、その人達を訓練することはできません。別の人達を訓練するすべての望みをあきらめなければならない場合は、セキュリティは永久に負け試合でしょう。攻撃者は常に人を悪用することにより、方法を見つけようとしています。そして人々は常に弱い部分であるままです。人に焦点を当てている攻撃者は技術的な攻撃に焦点を当てている攻撃者よりも、より成功する可能性があります。そして、これを防ぐことはできません。人々に基本的なセキュリティを意識した行動を行なうように訓練することが可能であるという考えは、私の仕事の支えです。それを台無しにさせないでください。

もし、みなさんの社員の訓練に成功したら、みなさんの持っている最強の防御線になるはずです。彼らは、情報保護の必要性を理解し、それを実施するために合理的な方法をと行なうでしょう。彼らは、人とコンピュータに対する攻撃に気づきます。そしてそれは非常に効果的な侵入探知 (と防御) のシステムなのです。また、故意または偶然に人間が犯す間違いに対処するために我々が整備した、面倒な技術的なセキュリティのいくつかの必要性を取り除くのは彼らなのです。人間のセキュリティにおける投資は、みなさんが義務を負う最重要なセキュリティ投資です。そしてパスワードはその波の正面に乗っているのです!

詳細情報を得る

みなさんが、本当にパスワードに興味がある場合は、Protect Your Windows Network (英語情報) の 11 章を読んでください。人々が実社会で使用しているパスワードの種類、パス フレーズがパスワードより優れている/いない理由などの深い議論が含まれています

いつものように、これはみなさんのためのコラムです。読みたいものがありましたら、下の「このコンテンツを評価する」のボタンをクリックして、質問、ご意見をお寄せください。また、私のブログ (英語情報) を通して連絡いただくこともできます。この特別なコラムに関するディスカッションを引き続きお話するスレッドを見つけられます。

この記事は、マイクロソフト セキュリティ ニュースレターで配信しました。

ページのトップへ