開発日誌：フォーム認証の保存方法を考える

甕星 — Mon, 10 Jan 2005 12:36:00 GMT

フォーム認証を使うためには、認証処理を自前で用意しなくてはなりません。内部でAPIを呼び出しWindowsのユーザー管理機能を使って認証を行う方法もあります。ですが、レンタルサーバーで任意にユーザーを登録できるわけではないので、この方法は候補から外しましょう。データベース上に独自にユーザ情報を保存して、自前の処理で認証を行うことにします。

ユーザー情報として最低限ユーザーIDとパスワードを保存することになります。この時パスワードを保存する方法には２種類が考えられます。一つは平分のまま格納する方法、もう一つは片方向ハッシュを用いて暗号化を施す方法です。

パスワードを平文でそのまま格納した場合、データベースを他者に見られた場合にパスワードが漏洩朗詠してしまいます。パスワードを忘却した場合いは、データベースに格納されている元のパスワードを通知すれば良いでしょう。ただしこの時、パスワードの通知が行われたことを確実にユーザーに伝える工夫を考えたほうが良いでしょう。さもなければ、誰かが不正にパスワードを取得したとしても、利用者は気がつかないままになってしまいます。チャレンジレスポンス方式の認証を行う場合には、平分でパスワードを保持しておく必要があります。フォーム認証でもJavaScriptを活用してチャレンジレスポンス認証を行うことは可能ですが、今回そこまでする心算はありません。となるとデメリットしかないので、パスワードを平分で格納するのは止めた方が良いでしょう。

片方向ハッシュで暗号化を施した場合、例えデータの内容を他者に見られてもパスワードが漏洩する事はありません。今回はレンタルサーバーなので、他者の目に触れてしまうリスクは、自分でサーバーを管理しているときよりも高いと言えるでしょう。パスワードを暗号化しておくのは重要です。もちろん管理者にも元のパスワードを知る術はありません。したがってパスワードを忘却した場合にはこちらで適当に再設定したパスワードを相手に安全な方法で送付することになります。この場合パスワードは必ず変わってしまい、元のパスワードではログインできなくなります。誰かが不正にパスワードを入手した場合、本来のユーザーは利用できなくなることですぐに事実に気がつくことができます。

今回のところは片方向ハッシュで暗号化して保存する方向で作ろうと思います。幸いな事に片方向ハッシュアルゴリズムの一つMD5は、標準の機能として.Net Frameworkで提供されています。今回はそれを使って暗号化するよにしましょう。

認証方法を選択する

甕星 — Mon, 10 Jan 2005 01:33:00 GMT

せっかくサーバーを借りたので、やっぱり練習がてらCMSを作ってみることにしました。CMSを作るためには、やっぱりユーザー認証の機能は外せませんよね。IIS+ASP.NETで利用できるユーザー認証方法は以下の5つに分けることが出来ます。

基本認証
HTTP1.0で既定されているユーザー認証方法。もっとも簡単確実な方法のはず、でもあまり使っているのは見かけない。
利点：

ほぼ全てのWEBブラウザが広く対応している。
Windowsのユーザー管理機能と連携した、きめ細かなアクセス制御が可能。

欠点：

ユーザーIDとパスワードは平分で送受信される。
各ユーザーのWindowsアカウントを作成する必要がある。

ダイジェスト認証
チャレンジレスポンス方式で、パスワードを暗号化して認証を行います。実際に使っているのは見たこと無いです。
利点：

パスワードは暗号化して送受信される。

欠点：

HTTPでは既定されていないため、対応ブラウザが限定される。InternetExplorer5.0以上。
パスワードをクリアテキストで保存する必要があります。
ダイジェスト認証用に設定された Active Directory サーバーが必要。

統合Windows認証
WindowsNTの認証機能であるNTLMやKerberosV5による認証を行います。Windowsとの親和性が高い、逆に言えばいんどｗｓ以外では使えない。
利点：

Windowsのユーザー管理機能と連携した、きめ細かなアクセス制御が可能。
パスワードは暗号化して送受信される。

欠点：

HTTPでは既定されていないため、対応ブラウザが限定される。InternetExplorer5.0以上。
各ユーザーのWindowsアカウントを作成する必要がある。
プロキシーサーバーを利用することが出来ない。

クライアント証明書マップ
電子証明書を利用した認証方法。銀行業務や、企業間取引など強力なユーザー認証機能が必要なときに用いられている。利点：

証明期間の電子証明書を使った電子署名を利用するため偽装は困難です。

欠点：

利用するためには証明機関から各ユーザー用の電子証明を取得する必要があります。結構高い。
クライアント側で電子証明書を利用するための設定が必要です。
対応していないブラウザもあるらしいです。

フォーム認証
認証処理をASP.NETのアプリケーションとして独自に実装します。自由度が高く互換性の問題も少ないので、広く使われている様子。セキュリティ面は実装次第。
利点：

独自のCGIによって実現するので、実装はプログラマ次第です。

欠点：

独自のCGIによって実現するので、実装はプログラマ次第です。

さてどの認証方法を採用しましょうか？私はブラウザを限定したくないので、Windows認証やダイジェスト認証は候補から外します。レンタルサーバーで運用するつもりですので、Windowsアカウントを自由に作成するわけにはいきません。基本認証も駄目です。私には潤沢な予算がありません。したがってクライアント証明書を購入しなくてはならなくなるクライアント証明書マップも候補から外れます。唯一残ったフォーム認証を利用して作ることになりそうです。

世間ではフォーム認証を利用したWEBアプリケーションが大多数ですが、伊達や酔狂でフォーム認証を利用しているわけではないのですね。