it: 2005年3月アーカイブ

この文章は内輪向けにさっと書いたものを、読んでみていくらか一般的なことかなと思いこちらに掲載してみたものです。事実誤認が含まれる可能性も多分にあることをご了承ください。

sidebar.jp で実験してて、ほとんど害を感じていなかったわけですが、最近解ってきたことも踏まえて、整理してみます。

メイルアドレスのみで認証するシステムには少なくとも以下の問題がありました。

1.メイルを受信できない場所で認証ができない
2.メイルアドレスが無効になった(到達性がなくなった)場合にそのアカウントは完全に使用不能になる
3.メイル盗聴による成りすましの可能性

これ(特に1,2)を回避するには、メイル到達性以外の本人確認手段を併用するしかありません。

a:他の個人情報を入力しておいてもらい、メイルアドレス到達性がなくなった場合の本人確認情報とする

b:メイルアドレスをユーザ識別に用いるが、認証手段として、メイルを受信することに加えて、ユーザが設定したパスワード認証もサポートする

c:メイル認証に加えて、パスワードリマインダ相当の仕組みを導入する

d:USB token/生態認証など

e:他に何かよい本人確認手段はないか…？

a はこちらが保持する情報量が本人確認の確かさに影響します。しかし、正しいとされる情報量の基準が存在しないため、どれだけやっても確実とは言い切れません。持ちたくない個人情報を持たなければならないという問題もあります。また、1のケースにはまったく役に立ちません。

b だと POP3 パスワードを設定する人が続出しそうというのが問題です。パスワードを忘れた際にはメイル認証が使えます。両方の手段が使えなくなった場合はアウトです。

b は a の特殊系ともいえるので、中間案が考えられます。
c のパスワードリマインダ(秘密の質問)はこれにあたります。
世の中のパスワードリマインダは個人情報も集めた上で実施してたりするのでなんだかなぁと思うわけですが、これも、個人情報だけでは本人確認として不適切であるという証拠といえるかもしれません。

しかし、パスワードリマインダはどうしても(推測可能性の面で)パスワードより脆弱になるので、この認証が通っても、登録メイルアドレスにパスワードを送る程度のことしかしません。この認証だけで本人確認とするのは危険ということになります。

d のキーボード以外の入力デバイスを用いた認証というのも最近は現実的になりつつあります。USB-token のほか、指紋認証を供えたノートパソコンもあるくらいで。でもこれはネット越しの認証に使うのは危険すぎ、且つ普及度の点でまだまだ一般的な方法にはできません。
これらのデバイスに対して charrange & response 形式をネット越しにサポートできるようになったら、そして利用者が十分に増えたら有力かも。

まぁ、現状最も使われているのは結局 b なわけで、当面は b 方式の問題点が出ないように注意書きするくらいしかないのかもしれません。

(以下余談)
ところで、3 の問題点(メイル盗聴)を回避するにはメイルを暗号化するしかないのですが、受信者側が暗号化メイルのための鍵ペアを持っていないことが多いので厄介です。リレーポイント間で暗号化通信を行えるようにして、最後は POP3 パスワードを暗号解除キーとして APOP で取り出すようなプロトコルが実装できれば不完全とはいえだいぶ違うのですが…。

エンドポイント間の暗号化は、各SMTPサーバが公開鍵を宣言する(*)か、SSL 等でトンネリングするか、でしょうか。このあたり、最近どういう方向になろうとしているのか追いかけていないのですが…。
本当は送り先メイルアドレスごとに公開鍵があればいいだけですけど。

ユーザが鍵ペアを持てないでいるのは、鍵作成ソフトなどは無料で存在するのに、リポジトリが有料だったり(S/MIME)、手順が MUA で統合されていなかったり(PGP)するからなので、例えば国が証明書リポジトリを運用するとかすると、任意サービスが個々のユーザ向けに暗号化メイルを送れるようになるのかもしれません。

定義無しに謎概念に名前の付いたものがコード上に現れたときに感じること。

最近 DI (Dependency Injection)とか言って、カプセル化を破壊する過去に戻るような概念がもてはやされたりしてます。
自分は昔から設定ファイルベースの pluggable な仕組み自体は多用していたからこそ言いますが、DI が buzzword 化して流行りだすととんでもないことになります。

hibernate 等では RDB のリレーションを解決する方法を hibernate 側の設定として書けることを以て、「依存性を外部で定義する」＝DI の一種と呼ばれているように思います(詳しくは知らないので間違っていたらご指摘ください)。
こういうのは、はっきり言って外部化したことが便利なのではなく、コード中でリレーションを解決するコードを書くと長くなりがちで、最終的なオブジェクトグラフが読み取りにくくなるため、宣言的記法によって解消する、といった可読性面の意義でしかないと考えます。他に、依存性定義を一箇所にかけるなどがりますが、一元化したければ関数(static メソッド)にでもすればいいのです。

もし、ここで「ソースを書き換えなくても依存性の変更が可能」等と言い出してしまうと、buzzword の罠にはまっています。
そんなことができても便利にはならないです。そのかわりに失っているものがあるのだということが世間的に気づかれるのはあと１年くらいかかるかもしれません。

なお、hibernate は私もかなりいいツールだと思っています。使い手の問題なんです。

J2EE が間接参照を多用して、「柔軟性を上げた」と標榜して、概念の複雑化と実装負担(書かなければならないものの種類の増加)で嫌われた流れを踏襲するという予感がひしひしとします。

しかし、「謎概念」ってのがまた問題で、自分だけ知らなくて実は設計上当たり前ということも確かにあって、この業界では、知らないことが罪みたいな空気もなくはないので面倒です。デザインパターンなんてその典型です。しかも、言葉を知っているかどうかだけが重要視されていて、その意味は知らなくても良いかのような空気が:p。

新しい概念を定義し、名前をつけることは重要なのですが、過度に抽象化された定義が流行ると必ず正確な意図は掻き消えて、とんでもない使い方のほうが蔓延するものです。
技術者たるもの、宗教家のように論理的に説明できない用語を乱発するより具体的な定義を提唱することを心がけるべきでは？と思います。ちなみに(少なくとも GoF の)「デザインパターン」はかなり厳密に定義されています。念のため。

ところで、タイトルですが、管理者が buzzword に踊らされると使いたくないものを使わされて大変な思いをするということも一般的にはありがちではあるんですけどね…。私の場合、技術者が buzzword を生み出すことのほうがいやんな感じがするということです。