セキュリティ
ワンタイム パスワード ソリューションによる認証の強化
Dan Griffin
この記事の内容 : :
- パスワードに関する問題
- ワンタイム パスワードの生成
- Web サービス ベースの OTP ソリューションを構築する
- OTP をテストおよび展開する
|
この記事は次のテクノロジを使用しています:
IIS 7.0、SQL Server
|
コンテンツ
パスワードはセキュリティ上の重要な役割を果たし、 その管理性は企業の IT 管理者の悩みの種です。ユーザーは、多くの場合、単純なパスワードを作成するか、パスワードを忘れないように書き留めています。また、パスワードをリセットするためのセキュリティ上安全で効率的な手順はあまりありません。
これらの制限を念頭に置き、リモート ユーザーがネットワークにアクセスする場合にこの種のセキュリティの問題を軽減する方法を考えてみましょう。多くのユーザーがパスワードを書き留めている現状を考えると、会社のパスワード ソリューションを強化するにはどうしたらよいでしょう。以下では、C# および C で標準ベースのテクノロジを使用してワンタイム パスワード (OTP) の概念実証を開発する方法を示します。まずは、視野を広げて、パスワードに代わるテクノロジについて簡単に説明します。
リモート ユーザーの標準パスワードを不要にする方法がいくつかあります。証明機関を使用してユーザーに証明書を発行することが可能ですが、それには公開キー基盤 (PKI) が必要なため、設定や保守にコストがかかります。特にスマート カードなどのハードウェア ベースのトークンを使用している場合には、リモート ユーザーの証明書の管理も困難になる可能性があります。セキュリティを高度化する場合、このような高コストなトレードオフが共通の課題になります。
代わりに、RSA のワンタイム パスワード ソリューションである SecureID を使用することもできます。ただし、SecureID は標準に基づいていないため、非互換性の問題やライセンス付与のためのオーバーヘッドが生じる可能性があります。
3 つ目の選択肢は、標準ベースの OTP ソリューションを使用することです。では、どのような種類のワンタイム パスワード オプションが存在し、なぜ従来のパスワードと比べて OTP の方が優れているのでしょうか。それについて、これから説明します。
ワンタイム パスワード
通常、従来の静的パスワードは必要なとき (期限切れになったときや、忘れたためにリセットする必要がある場合) にのみ変更されます。パスワードはコンピュータのハード ドライブにキャッシュされ、サーバーに保存されるため、クラッキングされる可能性があります。このことは、盗難が容易なラップトップ コンピュータの場合に特に懸念されます。
多くの企業は従業員にラップトップを支給し、社内ネットワークにリモート アクセスできるようにしています。企業では、非正規従業員やベンダも雇用されています。このような環境では、単純な静的パスワード ソリューションは不利になる可能性があります。
静的パスワードと異なり、ワンタイム パスワードはユーザーがログインするたびに変更されます。パスワードは 2 つの方法 (時間同期またはカウンタ同期) のいずれかで生成されます。どちらの方法も、通常はユーザーがサーバーと同期する小型のハードウェア デバイスを (多くの場合はキー チェーンで) 携帯する必要があり、どちらも一般にパスワード生成のアルゴリズムを使用します。
時間同期 OTP は広く導入されていますが、時刻のずれによる問題が生じる可能性があります。つまり、認証サーバーとユーザー トークンの時間が同期していない場合、予期される OTP 値が生成されず、ユーザー認証は失敗します。時間同期 OTP では、通常、ユーザーはパスワードが期限切れと判断されて新しいパスワードが生成されるまでの一定時間内にパスワードを入力する必要があります。
カウンタ同期 OTP ソリューションでは、クライアント デバイスとサーバーとの間でカウンタを同期します。カウンタは、デバイスの OTP 値が要求されるたびにインクリメントされます。時間同期 OTP の場合と同様に、ユーザーはログオンする際、デバイスに現在表示されている OTP を入力します。
チャレンジ ベースの OTP は特殊なケースであり、多くの場合、ハードウェア デバイスも使用します。ただし、OTP を生成するには、ユーザーが暗証番号 (PIN) などの既知の値を指定する必要があります。この種の OTP は、現在ヨーロッパでクレジット カードやデビット カードへの認証機能の追加のために展開されています。現在使用されている OTP ソリューションはすべて何らかの種類の暗号処理を使用して構築され、同期パラメータ (時間値またはカウンタ値)、秘密キー、および場合によっては PIN から現在のパスワードを生成します。
たとえば、ハッシュ ベースの OTP では暗号化ハッシュ アルゴリズムを使用してパスワードを計算します。ご存知のように、暗号化ハッシュは任意の長さのメッセージを固定長のダイジェストにマップする一方向の機能です。そのため、ハッシュ ベースの OTP は入力 (同期パラメータ、秘密キー、PIN) で始まり、一方向の機能を使用して実行され、固定長のパスワードを生成します。
では、どのメソッドを選択するべきでしょうか。その答えを得るために、筆者は 1 つのソリューションを作成し、テストしました。次に、RFC 2104 および RFC 4426 標準の規定に従って、IIS 7.0 とキー付きハッシュ メッセージ認証を使用してカウンタ同期 OTP を作成する方法を示します。詳細については、RFC 2104「HMAC: メッセージ認証用のキー付きハッシュ」(
go.microsoft.com/fwlink/?LinkID=112151) および RFC 4226「HOTP: HMAC ベースのワンタイム パスワード アルゴリズム」(
go.microsoft.com/fwlink/?LinkID=112153) を参照してください。
テスト展開であるため、単純なクライアント アプリケーションを使用して OTP を作成します。前述のように、実際の環境では、この展開を耐タンパー性を備えたハードウェア デバイスと統合することができます。このソリューションに必要な基本事項を検討し、手引きとしていくつかのリソースを紹介します。
完全な OTP ソリューション
これから説明する OTP ソリューションを作成するには、SQL Server® を使用し、ASP.NET に統合された標準ベースの OTP 認証 Web サービスを作成する必要があります。また、各クライアント コンピュータにインストールする OTP ジェネレータを作成します。ユーザーはこの OTP ジェネレータを実行して新しい OTP を生成します。
ユーザーは、Web ブラウザから要求されたときに OTP 値を入力し、[Submit] ボタンをクリックして認証します。OTP プラグイン モジュールが IIS によって通知された後、Web サービスを呼び出して認証の試行を検証します。Web サービスはユーザーのキーとカウンタの値を SQL Server テーブルから検索し、OTP の計算を確認して、認証の成功または失敗を応答として返します。
図 1 は、サンプル ソリューションのアーキテクチャです。実稼動環境では、クライアントとサーバーとの間に信頼関係を構成したり、無効なログオンの試みを削除するなどの操作により、サービス拒否 (DoS) 攻撃に対してこのアーキテクチャのセキュリティをさらに強化する必要があります。
.gif)
図 1 ワンタイム パスワード ソリューションのコンポーネント
この記事に付属している MSDN® Magazine Web サイトのダウンロード セクションのサンプル コードは、OTP (HmacOtpDll) を生成する C++ DLL を含む Visual Studio® 2005 ソリューションで構成されています。この DLL は OtpClient と Web サービスで使用されるため、筆者は system32 フォルダに配置します (ビルド後のイベントで自動的にコピーしています)。サンプルには OTP の値を生成する OtpClient という名前のコンソール アプリケーションも含まれています。OtpClient は XML ファイルを使用して秘密コードとカウンタを保存します。アプリケーションを再ビルドするたびにプロジェクトのルートから XML がターゲット ディレクトリにコピーされ、カウンタは 0 にリセットされます。
IIS7Module という名前の IIS モジュールは OTP 認証サービスを提供し、WebService という名前の Web サービスを使用して OTP の値を検証します。この Web サービスは App_Data に配置されている SQL Server Express データベースを使用しています。TestWebsite プロジェクトの Web ページは、ソリューションのテストに使用します。
テスト用 OTP ジェネレータ クライアント
テスト用 OTP ジェネレータ クライアント アプリケーションは、ユーザーが OTP 認証値を取得するための自己完結型ツールです。このツールは、実際の展開では通常必要とされるハードウェア デバイスとチャレンジ (PIN 要求など) に代わる機能を果たします。このクライアント コンポーネントでは、OTP を計算するために、認証 Web サービスと共有されている DLL を使用します。このサンプル アプリケーションでは、ユーザーがツールを実行して次の OTP を作成し、その値を手動で Web ブラウザ上のフォームに入力します。この処理を C# と部分的に C を使用して実行します (C を使用したのは、OTP 暗号化の低水準実装のためです)。
ユーザー レベルでの OTP の動作は確認しました。では、このソリューションの機能レベルでの動作はどうなっているでしょうか。このハッシュ ベースの OTP ソリューションは 2 つの入力値 (キーとカウント) をとります。このほかに、OTP ソリューションには、認証時にユーザーが入力する必要があるキーの長さや予期される OTP 値の長さなどの実装に関連するメタデータもあります。
このサンプルでは、長さ 6 文字の OTP を生成し、最大 8 文字まで指定可能になっています。説明を簡潔にするため、この実装ではキーの長さを最大 64 バイトに制限する固定長バッファを使用します。キーに高品質の暗号化された乱数を使用することを前提にすると、キー スペースは膨大になります。実稼動の展開では、このようなキーを脆弱なリンクにはしません。最近のランダム キーの一般的なサイズは 256 ビット (32 バイト) です。
ユーザー (または技術的にはキー) によって認証が試行されるたびにカウント値がインクリメントされます。OTP ソリューションのセキュリティではカウント値を再利用しないことが重要であり、この処理は OTP サーバーで行われます。この実装では、カウントは 64 ビットの符号なし整数です。前述したように、このソリューションのもう一つの展開方法にサーバーとの時間同期があります。
キー付きハッシュ メッセージ認証コード (HMAC) はキー ベースの暗号化ハッシュです。つまり、HMAC は任意のメッセージとキーを取得し、このメッセージを固定長のダイジェスト値 (たとえば 20 バイト) にマップし、同じキーを持つユーザーのみが同じメッセージから同じダイジェスト値を生成できるようにします。
HMAC-OTP の最初の計算手順は、カウント値を取得し、HMAC 計算用の入力メッセージとしてエンコードすることです。この実装では、メッセージはカウンタ値が設定された 8 バイト バッファです。図 2 は、この手順とその後の 2 つの手順を示しています。次の手順として、前述のメッセージの HMAC をユーザーのキーを使用して計算します。この実装では、RFC に準拠するようにバイト オーダーに対処しています。
.gif)
図 2 ワンタイム パスワードの流れ (画像を拡大するには、ここをクリックします)
20 バイトの HMAC の結果が OTP 値に変換されます。変換結果は、HMAC 結果を 10 進数エンコードした値です。この場合、実用上の要件が 2 つあります。まず、ビット落ちがあると計算が暗号化攻撃にさらされるため、HMAC 計算のなるべく多くのビット、できれば OTP の結果全体 (この例では 6 桁の数字) を保持する必要があります。2 つ目には、なるべく多様な入力デバイスと互換性のある OTP を作成する必要があります。サンプルでは、この互換性要件を満たすために 10 進数エンコードを実装しています。ちなみに、この強力な認証の実装にはダイヤル式電話との互換性もあります。
サンプル Web サイト
目的は、ユーザーが OTP でのログインに成功したか、失敗したかを示すサイトを適切にデザインすることです。テストを簡素化するため、この OTP ソリューションにはサンプル Web サイトが用意されています。サイトの最初のページは Default.htm です。このページは認証されたユーザーのランディング ページであり、非 ASP.NET ページも含めて OTP モジュールでページを保護する方法を示します。現在認証されているユーザーの名前を示す Test.aspx ファイルと、Test.aspx ページが認証されたユーザーの名前を System.Web.UI.Page.User プロパティから取得する方法を示した Test.aspx.cs ファイルも用意されています。また、OtpModule への参照を含む web.config ファイル、および IISModule.dll ファイルへの参照を含む Visual Studio プロジェクト ソリューションも付属しています。
IIS HTTP OTP プラグイン モジュールは Web サイトのコンポーネントです。このモジュールは IIS とのインターフェイスの役割を果たし、ユーザーをユーザー名と OTP を入力する Web フォームにリダイレクトします。ユーザーがユーザー名と OTP を送信すると、その入力内容を確認し、成功または失敗を示す適切なページにユーザーをリダイレクトします。また、このモジュールは、ユーザーの認証ステータスとユーザーのセッションを組み合わせます。
管理性とサポート可能性を確保するため、このモジュールを C# で作成して管理可能にしています。プラグイン モジュールは認証 Web サービスのクライアントです。次に、これについて説明します。
OTP モジュールは IHttpModule インターフェイスを実装します。このモジュールはきわめて単純で、3 つのパブリック メソッドのみで構成されています。まずは、次のような Init メソッドです。
public void Init(HttpApplication application)
{
application.BeginRequest += new EventHandler(application_BeginRequest);
}
ご覧のように、モジュールはこのメソッドを使用して BeginRequest のハンドラ、application_BeginRequest を登録します。OTP BeginRequest ハンドラの目的は、すべての HTTP 要求が認証されたユーザーからのものであることを確実にすることです。この処理は、いくつかのヘルパ関数を使用して行います。使用するヘルパ関数には、呼び出し元が認証されているかどうかを確認する 1 つの関数と、呼び出し元が未認証の場合に認証を実行するいくつかの関数があります。BeginRequest イベントで要求をインターセプトした場合、ASP.NET アプリケーションで使用される標準の認証パターンに従わないということにも注意する必要がありますが、それでも、他のモジュールに要求を参照させたくない場合は、認証の前に要求をインターセプトするようにデザインされている場合でも、この方法をお勧めします。
IsAuthenticated ヘルパ関数は、要求が認証されたユーザーを示しているかどうかを確認します。この処理を行うために、適切に暗号化された認証 Cookie のアプリケーション コンテキストを System.Web 名前空間内で HttpContext、HttpCookie、Security.FormsAuthenticationTicket の各クラスを使用して確認します。Cookie が存在し、適切に暗号化が解除されていれば、呼び出し元は認証されていると判断されます。それ以外の場合は、処理する必要がある OTP 認証要求であるか、無効な (未認証の) Web クライアント要求であるかのいずれかの状態であるため、ログイン フォームが表示されます。
OTP モジュールには LoginPage.htm という名前のログイン フォームが組み込まれています。このフォームは 5 つの HTML 要素 (初期時に空のエラー メッセージ フィールド、ユーザー名フィールド、パスワード フィールド、送信ボタン、および hdLoginForm という名前の非表示入力フィールド) で構成されます。
呼び出し元が認証済みの場合、モジュールはそれ以上の処理を行いません。要求の処理が続行されます。この例では、Default.htm ページが読み込まれます。
呼び出し元が未認証の場合、IsAuthenticationPost ヘルパ関数が呼び出されます。この関数は、要求のタイプが POST であるかどうか、および要求フォームに hdLoginForm 入力フィールドがあるかどうかを確認します。両方の条件を満たしている場合、メソッドは true を返します。
要求が認証要求である場合、TryAuthenticate ヘルパ関数が呼び出されます。ユーザー名と OTP の値が要求コンテキストから取得され、認証 Web サービスの VerifyOtpCode メソッドに渡されます。検証が成功すると、新しい暗号化認証 Cookie が応答に付加されます。次に、応答は既定のページ (Default.htm) にリダイレクトされます。このデモを拡張する 1 つの方法として、ユーザーが要求した元のページを保存しておき、認証が成功したらそのページにユーザーをリダイレクトするという処理が考えられます。
VerifyOtpCode Web サービスの呼び出しが失敗した場合、要求は再度ログイン フォームにリダイレクトされます。この場合、ログイン フォームにはエラー メッセージが表示され、ヘルパ関数 ShowLoginForm が呼び出されます。このヘルパ関数はモジュールのリソース セクションからログイン ページを読み込み、ページにエラー メッセージ文字列を設定して (該当する場合)、ログイン ページを現在の要求に対する応答として設定します。次に、要求が完了したことを通知します。この通知は、要求の性質にかかわらず行われます。
認証 Web サービス
認証 Web サービスは、指定された OTP の値が、ユーザーが秘密キーを知っていることを示しているかどうかを確認することにより、OTP 認証を実行します。
OTP 認証 Web サービスの実装は、テスト用 OTP ジェネレータ クライアントに関するセクションで説明した OTP の計算を実装する低水準の暗号化ライブラリを再利用しているため、きわめて単純です。この再利用は、ネイティブ HmacOtpDll.dll の GenerateOTP エクスポートの P/Invoke 呼び出しの形で行われています。
この Web サービスは、認証が成功した場合に true を返す Web メソッド、VerifyOtpCode を公開しています。このメソッドの最初の手順は、認証要求で指定されたユーザー名に該当する SQL Server 行を読み込むことです。SQL Server に一致する行が見つからない場合、メソッドは false を返します。
ユーザー名が SQL Server データベースに見つかった場合、3 つのデータ項目 (要求に指定された OTP 値、SQL Server から取得したユーザーの秘密キー、SQL Server から取得したカウンタ値) がネイティブ GenerateOTP に渡されます。
GenerateOTP が連続したカウンタ値を使用して、一致する OTP の値が返されるまで、または最大 1,000 の連続カウンタ値がチェックされるまで、再試行されます。この場合、ユーザーがクライアント カウンタを誤ってオフラインでインクリメントする可能性がありますが、最後に認証が成功してからこの誤操作が 1000 回行われる可能性はないに等しいと考えられます。
この範囲を小さくすると、このシーケンス内で攻撃者が OTP の値を推測できる余地がさらに低くなりますが、ユーザーが誤ってサーバーによって試行された範囲を超えてクライアント カウンタをインクリメントする可能性があります。後者の場合、ユーザーが再度認証可能になるためには、管理者の介在が必要になります。
一致する OTP の値がカウンタの範囲内に見つかった場合、新しいカウンタ値がデータベースに書き込まれます。この処理を行うには認証 Web サービスにデータベースへの書き込みアクセス許可が必要になりますが、前述したように、カウンタ値の再利用を防ぐ必要があるため、これは OTP のセキュリティに不可欠なことです。ワンタイム パスワードを一意にするためには、パスワードの使用を 1 度限りにする必要があります。
単純なスキーマを持つ SQL Server データベースを使用して、ユーザー名とそのユーザー名に対応する OTP 秘密キーまたはシード値を保存します。スキーマを拡張して、OTP を使用したログオンの成功回数と失敗回数などのログ情報を追加することもできます。データベースは Username、SecretCode、Counter の各列で構成されます。これらの要素の詳細については、「認証 Web サービス」を参照してください。サンプル コードに付属しているデータベースのコピーには、ユーザー名 "testuser" の 1 行のみが存在します。
完成したアーキテクチャ
図 3 は、完成したソリューションの概要を示しています。図に示されているとおり、ユーザーはクライアント アプリケーションを起動し、OTP を生成し、認証 Web アプリケーションに移動して OTP を Web ブラウザ フォームに貼り付けます。このフォームは、要求が未認証であることが検出された場合に OTP モジュールによって生成されます。ユーザーが [Submit] をクリックすると、Web ブラウザ フォームがサーバーに要求を送信し、要求はサーバー上で OTP モジュールによって再度インターセプトされます。次に、OTP モジュールは、OTP Web サービスを呼び出してユーザー認証データを検証します。検証が成功した場合、Web サーバーは要求ページのハンドラを呼び出します。呼び出されるハンドラの種類は任意 (HTML、ASP.NET、PHP など) です。
.gif)
図 3 詳細な OTP ソリューションのアーキテクチャ (画像を拡大するには、ここをクリックします)
コード サンプルを実行する
コード サンプルを実行するには、IIS 7.0 を使用している Windows Vista® または Windows Server® 2008 (Windows Server 2008 のアプリケーション サーバーの役割が有効になっていること)、Visual Studio 2005、SQL Server 2005 または SQL Server Express、および OTP サンプル コードが必要です。デモを実行する場合は、筆者が使用した Windows Server 2008 と SQL Server Express を使用することをお勧めします。以下の説明は、OTP サンプル コードのソリューション ファイルが C:\Test\OTP\Otp.sln に存在することを前提にしています。
環境を準備するには、IIS マネージャを使用するか、web.config ファイルを編集して、IIS モジュールをインストールします。IIS_IUSRS アカウントまたはカスタム アプリケーション プールの ID として構成されたアカウントの C:\Test\OTP\webservice\app_data に対する読み取りおよび書き込みアクセス許可を有効にします。次に、OtpTest および OtpService の Web サイトを追加します。
web.config ファイルを使用して IIS モジュールを登録するには (この手順はサンプルでは完了済みです。TestWebsite\Web.Config を参照してください)、次の構成マークアップが必要です。
<system.webServer>
modules>
<add name="OtpModule" type="OtpModule" />
</modules>
</system.webServer>
モジュール DLL を bin フォルダまたはグローバル アセンブリ キャッシュ (GAC) に追加する必要もあります。OTP モジュール DLL を GAC に登録するには、次のようなコマンドを使用します。
gacutil.exe /i iis7module.dll
IIS マネージャを使用するには、IIS マネージャを開き、コンソール ツリーのコンピュータ名をクリックします。中央のウィンドウで [モジュール] アイコンをダブルクリックし、操作ウィンドウの [マネージ モジュールの追加] をクリックします。次に、ドロップダウン リストボックスから [OtpModule] を選択します。この DLL を GAC に登録し、IIS マネージャを使用してモジュールを追加した場合、モジュール一覧を更新するために IIS を再起動する必要があります。
SQL Server Express で number-of-attempts (試行回数) の値を適切にインクリメントするには、NETWORK SERVICE アカウントに、C:\Test\Otp\WebService\App_Data ディレクトリに対する読み取りおよび書き込みアクセス許可が必要です。図 4 に示すように、このオブジェクトに必要なアクセス許可は、読み取りおよび実行、フォルダ内容の一覧表示、読み取り、書き込みです。
.gif)
図 4 App_Data ディレクトリに必要なアクセス許可
テスト Web サイト用の IIS にサイトを設定する必要もあります。それには、IIS マネージャ コンソールを開き、IIS マネージャ コンソール ツリーでコンピュータ名のノードを展開して、[サイト] を右クリックし、[Web サイトの追加] をクリックします。新しいサイトに次の設定を使用し、[OK] をクリックします (図 5 に各設定を示します)。
.gif)
図 5 OtpTest Web サイトの設定 (画像を拡大するには、ここをクリックします)
- サイト名 : OtpTest
- 物理パス : C:\test\Otp\TestWebsite
- ポート : 8000
Web サービスのサイトも作成する必要があります。このサイトには、次の設定 (サイト名 OtpService、物理パス C:\Test\Otp\WebService、およびポート 8080) を使用します。
次に、Visual Studio で Otp.sln ソリューションを開き、ソリューション エクスプローラで IIS7Module を展開し、[Web 参照] を展開して、OtpService を右クリックします。[プロパティ] をクリックして [Web 参照 URL] が http://localhost:8080/service.asmx に設定されていることを確認します。[ビルド] メニューで [ソリューションのビルド] をクリックし、ビルド エラーが発生していないことを確認します。
次に、OTP モジュールが適切に登録され、正しく読み込まれることを確認する必要があります。それには、http://localhost:8000 に移動し、図 6 のようなログオン ページが表示されることを確認します。この実装をテストするには、テスト ユーザー名「testuser」を入力します。
.gif)
図 6 テスト Web サイトの最初のページ
[OTP Code] テキスト ボックスの値を取得するには、コマンド プロンプト ウィンドウを管理者として開き、OTP クライアント プログラムのビルド ディレクトリ (C:\Test\Otp\otpclient\bin\debug) に移動します。OtpClient.exe を実行して、次の OTP の値を取得します。図 7 のような値が取得されます。
.gif)
図 7 OtpClient.exe を実行して
OTP の値を取得する (画像を拡大するには、ここをクリックします)
OTP の値を [OTP Code] テキスト ボックスに入力し、[Submit] をクリックします。図 8 は、サンプル OTP コードをページに表示しています。認証が成功すると、Default.htm ページに移動します。
.gif)
図 8 サンプル OTP 値を指定したテスト ページ
既定のページの Text.aspx リンクをクリックしてデモ ページに移動します。現在認証されているユーザーが存在すれば、その名前が表示されます。認証の資格情報が不正な場合、図 9 のようなページが表示されます。
.gif)
図 9 認証が
失敗した場合
展開に関する考慮事項
このサンプル ソリューションを実稼働環境に展開する場合は、さまざまな考慮事項があります。実際の展開では、ユーザーのキー/シードをハードウェア トークンなどの耐タンパー性を備えたデバイスに保存します。認証の試行が連続して失敗した回数が多すぎる場合にアカウントをロックするようにソリューションを変更することをお勧めします。それには、SQL Server の複数の列と 1 つの機能を Web サービスに追加します。
相互運用性が懸念される場合、低水準の HMAC コードで相互運用性のテストを実行することをお勧めします。MD5 ハッシュ アルゴリズムはもはやセキュリティ上安全ではないということも認識してください。このサンプル ソリューションでは、RFC ドキュメントで使用可能な基本的な既知のベクトルのテストを実行するために MD5 ハッシュ アルゴリズムを使用していますが、展開可能なソリューションでは、SHA-2 アルゴリズムのうちの 1 つを使用してハッシュを作成する必要があります。
よりユーザーにわかりやすい認証ページを開発する場合、不正なユーザー名と不正なパスワードとを区別しないでください。そうしないと、攻撃者に有効なユーザー名を知られてしまいます。ユーザーを追加および削除するため、または認証データベースを Active Directory® などの他のリポジトリと同期するための何らかの種類のプロビジョニング ソリューションも必要です。
ASP.NET のみをターゲットにしている場合であれば、モジュールを標準の ASP.NET HTTP モジュールとして実装することが可能です。ただし、このようなソリューションでセキュリティが保護されるのは .aspx ファイルに限られます。IHttpModule インターフェイスは ASP.NET ランタイムまたは IIS 7.0 のどちらで構成する場合も同じであるため、元のソリューションが ASP.NET 固有のモジュールであった場合、すべてのファイルの種類をサポートするには、構成の単純な変更で済みます。
筆者は Visual Studio を使用してデータベースを編集しました。これは、以前には気付かなかった IDE の優れた機能です。データベースを編集するには、ソリューション エクスプローラのツリー ビューに移動して WebService を展開し、App_Data を展開して、コンテキスト メニューから [開く] オプションを選択します。表示された [サーバー エクスプローラ] パネルで [データ接続] を展開し、[otp.mdf] を展開し、[テーブル] を展開して、[ユーザー] を右クリックしてから [テーブル データの表示] をクリックします。図 10 は、Visual Studio IDE のテーブル データを示しています。テスト時には、データベースを IDE で開いたままにしないでください。Web サービスで開くことができず、認証が失敗します。
.gif)
図 10 ワンタイム パスワード ソリューションのコンポーネント
ぜひ試してみてください
ワンタイム パスワードは標準パスワードの優れた代替機能です。パスワードを書き留めたり、フィッシング攻撃にだまされたりするなどユーザーがパスワードを不用意に扱うことがあるため、認証プロセスを強化する必要があります。IIS 7.0 プラグインのモジュール モデルを使用して標準ベースの OTP ソリューションを作成し、ハードウェア トークンおよびチャレンジを使用してより堅牢で実稼動に適した OTP ソリューションを作成することができます。
このサンプルに従って、ご自身でソリューションを作成してみてください。多くの事業者や、オンライン バンキングなどの顧客対面インターフェイスは OTP に対応しているため、このテクノロジに精通する必要があります。
より詳しい説明については、Mike Volodarsky の 2008 年 1 月の MSDN Magazine の記事「IIS 7.0: 統合 ASP.NET パイプラインでアプリケーションを拡張する」(
msdn.microsoft.com/msdnmag/issues/08/01/PHPandIIS7) を参照してください。この記事には有益な背景情報が掲載されています。
Dan Griffin は、ワシントン州シアトル在住のソフトウェア セキュリティ コンサルタントです。Dan はかつてマイクロソフトの Windows セキュリティ開発チームに 7 年間在籍していました。Dan の連絡先は
www.jwsecure.com です。