■ 匿名アクセス

さて、ネット君。HTTPで最初にした話を覚えているかね？
WWWは3つの技術が基盤となっている、という話だ。

3つの技術？ HTTPとHTMLとURIでしたよね？

うむ。そこでURIの話をしたはずだ。URI、というかURLの記述はこうだったな。

でしたよ？ ユーザ名とパスワードとサーバポート番号は省略可能でしたよね？

うむうむ。今回話すのは、その省略されたユーザ名とパスワードの話だ。
ネット君、WWWとはなんだった？

うぇ？ 「3つの基盤技術を使った広域情報共有システム」でしたっけ？

そうだ。WWWは「広い範囲での情報共有」を前提としているので、FTPやTELNETと違い特にユーザを指定しなくても使用できることがもともとの発想だ。「誰でも簡単に情報を見ることができる」ようにしてるわけだな。

なるほど。誰でも見れるから、ユーザ名やパスワードは省略可能なわけですね。

そういうことだな。このように、誰でもアクセスできるのを匿名アクセスと呼ぶ。

とくめい…。名前を隠してアクセスするんですね。

名前を隠して、というか。実際は「誰でアクセスしても同じユーザでアクセスしている」という形になるわけだが。

「誰でアクセスしても同じユーザでアクセスしている」？

そうだ。誰でアクセスしても同じ特定のユーザでアクセスしている扱いになるわけだな。これを「匿名ユーザ」と呼ぶ。
例えば、WindowsのIISでは、「IUSR_」で始まるユーザが匿名ユーザとして用意されている。

へ〜。

Apacheの場合はいろいろあるのだが。
ともかく、基本はこの「匿名アクセス」による「誰でも自由に閲覧が可能」なシステムがWWWというわけだ。

誰でアクセスしても同じユーザだから、名前が隠れるわけですね。
で、そのおかげで自由に見れる、と。

だが、Webページによっては特定のユーザしか見て欲しくないページだってあるわけだ。
会員制のページだったり、コミュニティのページだったりすることもあるわけだしな。

そうですね、そういうこともありますよね。

そのために使われるのが、認証というわけだ。

認証？ あうせんてぃけーしょん？

■ アクセス認証

どっちかといえば、「オーセンティケーション」だと思うが。
まぁともかくだ、認証とは「なんらかの手段を用いてアクセスするユーザを特定する」ことだ。

アクセスするユーザを特定する？ 誰が特定するんですか？

サーバソフトがだ。「今ネット君がアクセスしにきている」とわかるようにする、ということだ。

は〜、その人がホントに会員かどうか「特定」しているわけですね。

うむ。まぁ、実際今まで説明してきたプロトコル、TELNETやFTPなどでも行われている処理だな。

ん〜、TELNETは仮想端末へのログイン、かな？
FTPだとUSERやPASSコマンドで「認証」とかそういう話をしてたような。

「してたような」ではなく、「してた」のだが。
つまり、この認証というものはHTTPに限らず、TELNETやFTP、後で説明するPOPなどでも使われているものだ、ということだ。

なるほどなるほど。
あれですね、ユーザIDとパスワードで「特定」するんですよね？

まぁ、そういう場合がほとんどだな。いわゆるアカウントという奴だ。

あかうんと？

「アクセスする権限を保持すること」かな？ 多くの場合ユーザIDとそれを確認するためのパスワードだな。正規の認められたアカウントによるアクセスか、ということを「認証」する、というわけだ。

ふむふむ。

ユーザIDとパスワードという形が多いが、電子証明書による方式もある。SSLクライアント認証で使われる方式だな。

電子証明書？ SSLクライアント認証？

ま、それについてはまたいずれ話そう。
ともかくだ。この認証はいくつか方法があるのだが、HTTPは次の2種類の認証方式を持っている。

べーしっく、と、だいじぇすと？

そうだ。CGIを使ったり、SSLを使ったりで他にも方法があることはあるが、HTTPが基本として持っているのはこの2種類だな。
IISの設定画面を見てみよう。

ん〜〜〜。博士？ 3つありますよ？ それに、ダイジェスト認証はグレーアウトして選べなくなってますけど？

あぁ、IISの場合、ダイジェスト認証にはドメインが必要なのだよ。
それとWindows統合認証はIISの独自方式だ。なので、基本的にはさきほどあげた基本とダイジェストの2つだな。

へ〜。

■ 基本認証

では、まず基本認証から説明しよう。基本認証はHTTP1.0からある認証方式だ。
基本認証を有効にしたWebサーバで、アクセスするアカウントに制限がかかっているページにアクセスすると、次のような状態になる。

これはIEでの画面だが、ユーザIDとパスワードの入力を促されるわけだな。

「アカウントの認証」が必要なんですね!!

うむ、覚えた言葉をすぐ使ってみたがるという、子供じみたところは非常に好感が持てる。

そうですか、えへへ。

褒めてねぇ

はうっ。

ともかくだ、これを実現するのに使われるのが、HTTPレスポンスメッセージのメッセージヘッダの中の、「WWW-Authenticate」だ。

だぶりゅだぶりゅだぶりゅおうせんてぃけいと？ 第73回のメッセージヘッダの一覧の中にありましたっけ……？

博士っ!! 「応答」の中にありますよっ!!

当たり前だ。

あれ？ 「要求」の「Authorization」も色が変わってますけど、これは何か？

うむ。クライアントがHTTPレスポンスメッセージにユーザ名とパスワードを入れて送る場合に使われるのが、「Authorization」なのだよ。実際の動きはこうなる。

アクセスしようとすると「認証失敗」と、認証方式がくるので、そこでユーザIDとパスワードを入れて送り返すんですね。

うむ、そうだ。
ではこの動きをEtherealでキャプチャしたものを見てみると。

クライアントが最初に送ったリクエストに対するレスポンスメッセージだ。
IISなので「401 Access Denid（アクセス拒否）」というメッセージになっているが、やってることは同じだ。

「401」のレスポンスコードと、「WWW-Authenticate」のメッセージヘッダが確かにありますよ？

うむ。そしたら、クライアントは「Authorization」にユーザIDとパスワードを入れたリクエストメッセージを返すんだったな。

ありゃ？ なんですこの「dGVzdDp0ZXN0」っての？ 変なユーザIDですね。

あぁ、実際は送られる「ユーザID：パスワード」はBASE64という方式でコード化されて送られる。この「dGVzdDp0ZXN0」ってのがそうだ。

ははぁ、べーす64。

ま、BASE64はまた後で説明するとして、このようにやり取りされるわけだな。

なるほどです。

ただネット君、1つのページで認証が成功したとして、同じディレクトリにある他の認証が必要なページにアクセスする場合、どうなるんだね？

え？ ええぇ？
他にも認証が必要なページですか？ じゃあやっぱりまた認証が必要なんじゃないですか？

うむ。同じディレクトリや下位ディレクトリにあるページが認証が必要ならば、やっぱり認証を再び行う必要があるのだ。なんとも面倒じゃないかね、ネット君

あ〜、確かに面倒かも。
毎回毎回ページを移動するたびにユーザIDとパスワードを入れるのは結構大変ですよね。

だろう？ なので、そのページのディレクトリが同じもしくはその下ならば、「認証が必要であろう」と考えて、最初から「Authorization」をつけてリクエストができるのだよ。

ははぁ、「401 Unauthorized」を受け取る前に、「さっきのページは認証が必要だったから、この同じディレクトリにあるページも認証が必要だろう」って考えるんですね？

そういうことだ。この場合、前のページで送ったユーザIDとパスワードを「Authorization」に入れて、送ることができるのだ。

なるほど。それなら毎回ユーザIDとパスワードを入れる必要がないですね。

うむ、ただし、ブラウザを閉じてしまってはダメだがな。

あ、そうなんですか。

■ ダイジェスト認証

さて、基本認証を使えば、ページを「権限のないアクセスから保護」できるわけだが。
基本認証には欠点がある。ヒントは[Figure77-03]をよく見てみたまえ。

ん〜？ IISの画面ですか？
……「パスワードはクリアテキストで送信されます」かな？

うむ、その通り。

やりぃ。

まぁ、他にそれらしいところがないわけだから、気がつかない方がどうかしてる。
まさか当たって喜ぶようなことは考えられないわけだが。なぁ、ネット君。

え、えぇ、そりゃそうですよ、そこしかないですよね。

うむ。基本認証の欠点はまさしくその括弧書き、「パスワードはクリアテキストで送信」という点だ。つまり、パスワードがそのまま送られてしまう、というところだ。

パスワードがそのまま、クリアテキスト……、TELNETでも同じ事を聞かされた記憶が。

第53回だな。うむ、まったく同じ事を言った。「暗号化されていないため、盗聴の危険性がある」と。セキュリティ面で弱いのだよ。

あれ？ でもさっきべーす64とかいうのでコード化されるっておっしゃってませんでしたっけ？

あぁ、BASE64でコード化されるが、戻すのが簡単なのだよ。対応表さえあれば簡単に元に戻せる。

あ、そうなんですか。

そうなのだ。なので、パスワードを見られないようにしてやりとりをしたいわけだ。
そこで使うのがダイジェスト認証なわけだよ。ダイジェスト認証の場合、実は入力画面が異なる。

あ、なんか微妙に違う。これで区別するんですね。

さて、そのダイジェスト認証がどのようにパスワードを隠しながらやりとりするかというと。
チャレンジ&レスポンス方式を使う。

ちゃれんじあんどれすぽんす？
挑戦と応答？

うむ。これはPPPのCHAPでも使われている方式だ。
これには一方向関数のハッシュ関数が使われる。

おおぅ、なんだかよくわからない言葉が連発されてきましたよ、博士。ピンチです。

うむ、そうか。一方向関数を説明しよう。

へ〜、へんな関数ですねぇ。全然別のビット列を作り出すなんて。

そうなのだ。しかもそのビット列は長さが一定で、元のビット列を推測できなくて、同じビット列が出来にくいし、作りにくいという特徴をもっている。有名なものではMD5やSHA-1がある。

しゃーわん。

現在の暗号・認証技術の中でも必須技術の1つがこのハッシュ関数だ。

へ〜。で、これを使うとどうなるんです？

うむ。実際のダイジェスト認証で使われている計算は結構複雑なので、単純化したもので説明しよう。

ん？ ん〜？
ちょっと待ってください。混乱しています。

気にするな、いつものことだ。

え〜っと、サーバはなんかしらの文字列を入れて、レスポンスを返す。
クライアントはユーザIDとパスワードと文字列をハッシュして、ハッシュ値を作り出す。

そうだ。

そのハッシュ値をサーバに送る。サーバは自分に登録してあるユーザID、パスワード、送った文字列をハッシュして、ハッシュ値を作り出す。

ユーザID、パスワード、文字列という同じモノでハッシュ関数を計算しているから、ハッシュ値が同じものになるはずだ。そうでなければ、ユーザID、パスワード、文字列のうちどれかが違うということになる。

文字列が違うわけはないから、ユーザIDかパスワードが違う…。

逆にいえば、一致するなら、クライアントのユーザID、パスワードと、サーバに登録してあるユーザID、パスワードは同じモノだという証明になる。

つまり、認証される……なるほど。

どうだね、ネット君。この方式ならばパスワードはやりとりされないのだよ。

ん〜っと、やりとりされるのは「文字列」と「ハッシュ値」だけ、ですね。

パスワードと関連してるのはハッシュ値だが、ハッシュ関数の特徴より、ハッシュ値がわかったとしても元はわからない、つまり、パスワードはバレない、ということになるわけだ。

や、上手く考えられてますね。

だろう？
だが、実際はダイジェスト認証といえども、すごくセキュリティが高い、というわけではない。

え？ そうなんですか？

うむ。というよりも、SSLの方がセキュリティが高い、といったほうがいいかな。
なので、実際は認証としてはダイジェスト認証よりもSSLを使うのが現在の主流だな。

は〜〜。

さてさて、今回はこのぐらいにしておこう。

はい。

とりあえず、HTTPはこれくらいにしておこう。
次回からはまた別のプロトコルを説明する。

了解です。 ３分間ネットワーキングでした〜♪