第6回 迷走の痕跡を抱えるMac OS XのOpenDirectory：Undocumented Mac OS X（2/3 ページ）

[白山貴之，ITmedia]

認証の問題とパスワード情報のありかた

　ディレクトリサービスの有無にかかわらず、認証を行う場合、「どうやって」認証するか、そして「どこで」認証するかという問題がある。

認証の方式

　「どうやって」の方だが、これは大きく分けて2つの方式がある。1つは、UNIXの/etc/passwdが使っていたように、ある一定の手法で計算した値をパスワードとして送りそれを比較する方法である。そしてもう1つは、パスワードに加え認証を行うごとに変わる値を加え計算を行い比較する、チャレンジ-レスポンス方式の認証である。POP3やIMAPのPLAIN認証、HTTPのBasic認証などは前者であり、APOPやIMAPのCRAM-MD5認証、HTTPのDigest認証は後者になる。

　前者は手軽だが、通信路を盗聴されることでパスワードが露見してしまう弱点がある（図4）。後者は毎回変わる値があるため通信路を盗聴してもパスワードはまず分からないという利点がある。昨今ではネットワーク上での盗聴への対処から後者のチャレンジ-レスポンス系の認証が好まれるが、しかし、毎回計算を行うためサーバ側に生のパスワードを保管しなければならないという弱点がある*（図5）。

図4　POP3のように単純な認証の場合、ネットワーク上にユーザー名とパスワードが流れ、それを基にサーバ側で計算を行い、すでに計算済みのパスワードデータベースとの比較が行われる。ネットを盗聴することでパスワードが判明する

図5　APOPのようなチャレンジ−レスポンス系の認証は、まず乱数を送り、サーバとクライアントがそれぞれその乱数とパスワードを基に値を計算、それを比較する。ネットワークに流れるのは毎回異なる計算結果のため盗聴には強いが、サーバ側に平文のパスワードを保管する必要が出てきてしまう

どこで認証するか

　ディレクトリサービスを認証に使う場合、さらに「どこで」という問題がつきまとう。ディレクトリサービス自身が認証の機構を持たない場合、アプリケーション側で認証を行う必要があるが、そのためにはパスワード情報をディレクトリサービスから取り出さないとならない。そして、チャレンジ−レスポンス系の認証を行おうとした場合は、生のパスワードそのものが取り出せなければならないのだ。これを許すのは大きな問題である。

　ディレクトリサービス自体が認証機構を持ち合わせている場合は、そうした問題はなくなる。しかし、HTTPならDigest認証とBasic認証、IMAPならPLAIN認証にCRAM-MD5、Windowsへのサービスを行うならNTおよび旧来のLM認証が必要になる。これらは微妙に計算方法が異なり、それぞれ独自の方法を用意しなければならない。さらに、各アプリケーションはそうした認証のための情報をディレクトリサービスへスルーしなければならなくなる。

解決方法

　同じLDAPを用いたディレクトリサービスでも、こうした問題への解決方法はそれぞれの環境で異なる。

　UNIX系OSとOpenLDAPという組み合わせの場合、その多くは単純にLDAPサーバの中にパスワードを入れてしまうというものだ。そしてユーザーが入力したユーザー名とパスワードを用いてLDAPサーバへ接続を試みて成功したら、認証に成功したと見なす。これをbind認証という。またSolarisではアノニマスでLDAPサーバへ接続、ユーザーを検索してそのパスワード情報を読み取り、ローカル側で照合を行う。これは暗号化された状態とはいえ、リモートからパスワードを読めるということなのでセキュリティ的に大きな不安が残る。

　通常のログインに加えて、Sambaの認証もLDAPサーバで管理させる場合、userPassword属性に加え、sambaNTPassword、sambaLMPassword属性というまったく別個の属性を用意し、smbdはsmb.confおよびsecret.tdbに格納されたLDAPサーバへのアクセス用ユーザー名とパスワードで接続、この2つの属性を確認するという方式を採用している。

　WindowsのActiveDirectoryでは、unicodePwd属性に生パスワードが格納されている。この値は外部から読み出せないようになっており、SSLで保護されたLDAPで接続された場合に限り変更ができる*だけだ。Windowsの行うNT認証やLM認証はチャレンジ−レスポンス系の認証方法であり、生パスワードが必須となるため、こういう仕組みになっている。

　OpenDirectoryのLDAPサーバはOpenLDAPのものを利用している。このため、ほかのUNIXと同じように認証しているのかと思われる。しかし実は、LDAPサーバの中にはパスワードが格納されていない。互換性のためかuserPassword属性などは存在するが、意味のある値は格納されていない。

　ではどうやって認証するのか、どこにパスワードを保管しているのか。その謎を解き明かすのがApplePasswordServerだ。

このページで出てきた専門用語

毎回計算を行うためサーバ側に生のパスワードを保管しなければならないという弱点がある

HTTPのDigest認証のように、あえて計算を2段階に分け、サーバ側には途中の1段目まで計算した状態で格納できるようにするものや、Sambaのようにハッシュした値をsmbpasswdに収めることでパスワードそのものは見えないように工夫しているものが多い。しかし、これらの工夫は、あくまで生パスワードそのものが判明しない、同じパスワードを使い回しているサービスへ侵入されるという2次災害の可能性が下がる程度の効果しかない。結局、チャレンジ−レスポンス系のパスワードは、その弱点をネットワークからサーバ上のファイルにずらしただけにすぎない。

SSLで保護されたLDAPで接続された場合に限り変更ができる

「LDAPを介してWindows 2000ユーザーのパスワードを変更する」というドキュメントに解説がある。