パスフレーズ vs. パスワード Part 1
公開日: 2004年10月27日
Jesper M. Johansson, Ph.D., ISSAP, CISSP Security Program Manager Microsoft Corporation
皆さんは情報セキュリティの分野に興味深い議論があることをご存知でしょうか？議論される問題の重要度はさまざまですが、そういった議論を考察していると、この分野はいまだ成長の過程にあって、とてもエキサイティングであることに気付かされます｡こういった議論のいくつかを要約して紹介し、私の意見を少々述べてみたいと思います｡まず手始めとして、パスワードのもろさについて、そしてパスフレーズとパスワードの対比について、今回は話をしてみようと思います｡
さて、「パスフレーズ vs. パスワード」論争は、「実にすばらしい」議論の 1 つなのか、それとも「気にかける人も少ない、つまらない」議論なのでしょうか？パスフレーズとパスワードは、どっちがよりセキュリティ的に優れているのか？実はこの問いは、明快な答えが「ポン」と出せるほど単純なものではないのです。
パスフレーズとパスワードを的確に比較分析するために、3 回シリーズのコラムとして論じていきたいと思います。まず第 1 回目、今回は、パスフレーズとパスワードの基本的な部分、両者はどのように保存されるか、について触れていきます｡次回は、強度の比較について、そしてより強度の高いのはどちらかを数学的なアプローチで論じる予定です｡そして最終回は、まとめとパスワードの選び方とパスワード ポリシーの構成に関する提案をしたいと思います｡
基本的な部分
まず、パスワードとパスフレーズの違いを理解することが肝心でしょう。皆さんはパスワードを決めるとき、どうしますか？大多数の人は「Password」のようにひとつの単語を使用する、「X2!aZ@<dF:」のような記号の羅列を使う、または「P@s$w0rd」のような単語と記号の組み合わせを使うことでしょう。パスフレーズとは、「This is a really complex pass phrase.」のようなフレーズのことです。パスフレーズは、ほとんどの場合パスワードより長く、空白を含んでいます｡人によってはフレーズに含まれる単語の最初の文字をとってパスワードにする場合もあるでしょう｡そのようなパスワードはパスフレーズではなく、おもしろいロジックで作成されたパスワードと理解してください。これに対してパスフレーズは、トークン ベースのパスワード形式をしています。トークンとは、文字コード セットにある記号ではなく単語を指します。パスフレーズはセンテンスになっていたり、正しいつづりであったりする必要はありません。また、パスワードの例として最後にとりあげたもののように記号を代用する必要もありません。
パスワードとパスフレーズの主要な違いは、
(1) パスフレーズは通常、スペース (空白) を含むが、パスワードは含まない
(2) パスフレーズは、ほとんどの単語と比較して非常に長く、一般人が記憶できる羅列された文字の長さよりも長く、理解しやすい
パスフレーズは単にとても長いパスワードと考える事もできますが、通常は、連続した単語によって構築され、言葉に似ているものです。ここで説明されているパスフレーズは Windows 2000 またはそれ以降の OS で使用するのに適しています｡他の製品では、別の特性をもったパスフレーズを使用したり、またはまったくサポートしていなかったりするので注意が必要です。
つぎに、パスワードの推測 (ブルートフォース攻撃) とパスワード クラックの違いを理解する必要があります｡パスワードの推測は、誰かがコンソールの前に座って、またはリモート コンピュータでパスワードを試す場合のことを言います｡パスワードの推測についてはこのコラムでは触れないつもりです。なぜなら、比較的複雑なパスワードが使用されている場合には、推測による攻撃はうまく行く事がないためです。パスワードをめでたく推測できたとしたら、それは攻撃者が超ラッキーだったか、パスワードがあまりにも弱かったかのどちらかしか考えられません｡
次の例を見てみましょう｡はじめに、4 つのカテゴリに属する記号を使用したパスワードを考えます｡大文字、小文字、数字、英数字以外の記号が素材としてあります。英数字以外の記号には、キーボードから入力できる記号、キーボード上に書かれていない記号、たとえば Unicode 文字が含まれています｡人によっては Unicode 文字とキーボード上の記号は別のカテゴリと考えているかもしれませんが、このコラムでは同じものとして扱います。さらに、「文字」という用語は、4 つのカテゴリすべてを総称するものと定義します。たとえば、パスワードは辞書にある単語であってはならず、8文字で最低 3つのカテゴリの文字を含み、70 日で期限切れになると仮定したとします。そのようなパスワードに関する予備知識がない攻撃者が、ネットワークを介して、パスワードの期限が切れる前にパスワードを推測するためには、53,000 T-3 (各 44,736 Mbps) のネットワーク帯域幅を持ったコンピュータ環境が必要になります｡これはパスワードとして使用可能な組み合わせの中のたった 1/2 を試すために必要な認証トラフィックを送信するだけでいっぱいいっぱいなのです。
パスワードに使用する文字を 76 の最も一般的な記号から選択するように限定し、パスワードは無作為に選択するか、攻撃者からみれば無作為に選択されているようにみえるパスワードを使用すると仮定した場合であっても、1.11 x 10^15 個の 8 文字パスワードを作成する事ができるのです。現実的な仮定ではありませんが、攻撃者が 1 秒間に 300 のパスワードを推測できたとした場合、どんな優れたプログラムを使用しても、パスワードの推測に 58,783 年という途方もない時間が必要となります。
一方、パスワード クラックは、攻撃者が加工されていないハッシュ (ハッシュとは、パスワードを保存するために使用される数学的な情報に置き換える仕組み。詳細については後ほど) を取得して行われる行為です。攻撃者はテスト用のパスワードを作成し、ハッシュ値を生成し、保存されているハッシュ値と比較するのです。クラッキングは、パスワードを推測するよりも断然手っ取り早く、中級クラスのハードウェアを使用している場合でも、攻撃者は 1 秒間に 3,000,000 パスワードを生成し検証することができます。使用可能な文字を 76 に限定し、8 文字パスワードをクラックするのにかかる期間は、上記の処理速度で考えると、6 年です。もちろん、多くのパスワードは 6 年もかからず、もっと短期間でクラックされることでしょう。統計的に言うと、半分の時間でパスワードはクラックされると考えられます。パスワード長が 7 文字の場合は、わずか 28 日でクラックされることになるのです。
攻撃者がどうやって未加工のハッシュを手に入れるのかが問題として残っていますね｡Windowsの場合を考えてみましょう｡ドメインのパスワードをクラックするためには、ドメイン コントローラへのシステム レベルのアクセス権が必要となります｡攻撃者がすでにドメイン コントローラを侵害してしまっている場合には、パスワードのクラックは 2 次的に行われる行為と考えられます。なぜなら既にドメインコントローラで最も重要なアカウントの情報を得ているのですから…。しかしながら、なぜ攻撃者はパスワードのクラックを続けるのでしょうか？ ほとんどの場合、攻撃者は別ドメインに同じユーザー名、同じパスワードを持つアカウントを見つけようとします｡これは管理上の依存性としてこのような運用が多く行われていることが知られています｡このトピックについては、また別の機会にお話したいと思います。さらに、チャレンジ レスポンス プロトコルの肝となる部分はパスワード ハッシュ自体であるため、パスワードをクラックすることは意味がありません。なぜならアカウントにアクセスするのにはハッシュがあれば十分なのです。にもかかわらず、攻撃者は通常パスワードを入手しようとクラックします。そしてその成功率は深刻な問題に発展します。
最近のオペレーティング システムは、当たり前ですがプレーン テキストでパスワードやパスフレーズを保存しないことは覚えておいてください｡通常保存されている値は、ハッシュのような一方向関数で求められる結果です。Windows NT ベースの OS (Windows 2000、XP、Windows Server 2003 を含む) では、パスワードはいくつかの異なる方法で保存されます｡主要なものに LM ハッシュと NT ハッシュがあります。ここでは、これらがどのように動作するものなのかを正確に知る必要はなく、次の 3 点を押さえていただければとおもいます。
LM ハッシュは 大文字小文字を区別しない。NT ハッシュは区別する
LM ハッシュは 142 文字の文字コードセットに限定されている。NT ハッシュは Unicode 文字のほぼすべて 65,536 文字を含む
NT ハッシュはユーザーが入力したパスワード全体からハッシュ値を生成する。LM ハッシュはパスワードを 7 文字ずつ 2 つに分け､必要な場合はパディングを行って文字数を埋める
どちらのタイプのハッシュも 128 bit 長のハッシュ値を生成します。現存するパスワード クラッカーのほとんどは、まず LM ハッシュをクラックし、そしてLM ハッシュでクラックされた大文字小文字を区別しないパスワードからすべての大文字小文字の組み合わせのバターンを試す事で、NT ハッシュをクラックしようとします。
LM ハッシュは非常に弱い一方向関数を使用していると言わざるを得ません｡もともと LAN Manager オペレーティング システムのために開発された技術であり、LM ハッシュの計算方法が原因で 142 文字の文字コードセットから7文字を使用したパスワードの方が、LM ハッシュで作成したパスワードよりも強い現象が発生してしまいます。それでも尚 Windows NT に LM ハッシュが搭載されている理由は、下位互換性を維持するためなのです。
LM ハッシュの破棄
LM ハッシュがストアされていないか確認する方法はいくつかあります｡ひとつは、15 文字以上のパスワードまたはパスフレーズを使用してみる方法です。また、Windows Server 2003 および Windows XP ではグループ ポリシーで「ネットワーク セキュリティ : 次のパスワードの変更で LAN Manager のハッシュの値を保存しない」を設定することで、NoLMHash スイッチを使用することもできます。このスイッチを全体に対して使用すると､全アカウントの LM ハッシュ値の保存を無効に設定できます。この変更は次回パスワードを変更した時から有効になりますが、すでに存在する LM ハッシュ値はこのスイッチでは削除されません。加えて、スイッチがすぐに有効にならないことも考えられるので、LM ハッシュの保存を無効にすることで生じる可能性のある相互運用性の問題に、すぐに気が付かないかもしれません。詳細は、マイクロソフト技術情報 299656 を参照してください。
パスワードに特定の文字を使用することで LM ハッシュを削除する事も可能です。「Alt 文字」をパスワードに含めると LM ハッシュ値は生成されません。実際に特定の Unicode 文字だけが LM ハッシュを消す事が可能です｡たとえば Unicode の 0128 から 0159 の間の文字は、LM ハッシュを生成させることができません。これは、Unicode 文字のいくつかはハッシュ生成される前に他の文字と結合されるためです。
とはいえ、LM ハッシュの削除によってシステムを壊してしまう可能性があります｡ LM ハッシュがインストール直後の時点で有効になっている 1 つの理由として、RPC の UDP ベースの認証を使用するアプリケーションに影響を与えないための措置ということがあります。Windows Cluster Services、Real Time Communications Server などがこれに含まれます。このような問題は、Windows Server 2003 のグループ ポリシーの「ネットワーク セキュリティ : セキュア RPC を含むクライアント ベースの NTLM SSP 最小のセッション セキュリティ」でNtlmMinClientSec 設定を有効にすることで解決することができます。NtlmMinClientSec は少なくとも「メッセージの整合性が必要」と「NTLMv2 セッション セキュリティが必要」(0x80010) を設定する必要があります。NTLMv2 認証を使用するよう RPC を設定すると NT ハッシュが使用されます｡その他のアプリケーションでも LM ハッシュがないことでうまく動かない可能性があります｡たとえば、Outlook 2001 for Mac を使用するためにはすべてのアカウントで LM ハッシュが有効でなければなりません｡Windows 3.x は LM ハッシュなしでは正常に動作できないのです。 Windows 95、98 ではある種の使い方をしていると正常に動作しないことも起こりえます。加えて、ネットワークに接続するストレージ デバイスなどのサードパーティ製品でも LM ハッシュが必要な場合があるのです。
.jpg)
この記事は、マイクロソフト セキュリティ ニュースレターで配信しました。