Oddwit

あらすじ：パスワードではなく画像の組み合わせを使って認証させる仕組み（RecognitionAUTH）を採用したOpenIDプロバイダを見つけたが、これはあまり良くないんじゃないかと思った。

myvidoopという、パスワード不要のOpenIDプロバイダを見つけた。

よくあるOpenIDプロバイダは普通にユーザ名とパスワードでログインを求めてくるが、myvidoopでは画像を使ってパスワードなしでログインできるところが面白い。

まずユーザ登録時に好きな「カテゴリ」を3つ選んでおく。カテゴリは「犬」、「高層ビル」、「飲み物」、「飛行機」などで、全26種類。ログイン時する際は、ユーザ名を入れると写真がサムネールで15枚ほど表示される。その中から自分のカテゴリの写真3枚を見つけ、一緒に表示されているアルファベットを入力する。正しければログイン完了だ。

ちなみに画像はカテゴリごとに一枚というわけではなく、同じ「犬」でも色んな犬の写真が出てきたりする。

RecognitionAUTHという名前でConfidentというところが売りに出しているこのシステム。試したみた感想だが、あんまり良くないんじゃないだろうか。端的に言うと簡単ではあるが、カテゴリを忘れにくいわけでもなく、自分のネット界の要となることを任せるには安心感が足りないという印象だ。

本棚.orgと比べてみる

画像でログインといえば僕は本棚.orgの例が浮かぶ。こちらは画像を自前で用意し、それぞれにいくつかの選択肢をつけてクイズを作るというもの。例えば自宅近くの公園の写真を使って「5丁目の公園」「4丁目の公園」「駅前」などを選択肢とすればよい。そんな画像を数枚使えば、数クリックでログインできることになる。

こういった認証システムを検討する時は、いくつかの重要なポイントがあるだろう。まずはもちろん、破られにくいかどうか。破られるというのにはDoS的なものもソーシャルエンジニアリングも含む。例えばパスワードは組み合わせ的には比較的破りやすいし、80%の人がチョコレートと引換にパスワードを教えてしまうというような話があった。

次に、安心感があるかどうか。様々な認証システムを見ていると、安心感があることと実際に安心であることは必ずしも同じではない。例えば指紋認証などはナイーブには安心感があるけども、実際の強度はそれほどでもない。

ログインできない事はないか。一番よくあるのはパスワードを忘れることだが、他にもたとえばFlashやJavascriptなど特定の環境に依存してしまうことも考えられる。

使いやすいかどうか。これは一つの認証方式でも大いに変わりうる部分だ。普通のパスワードでもそれなりに使いづらいが、オンラインバンキングでは何故かソフトキーボードをちまちまとクリックしなければいけない所などもあり、そうなると最悪である。

大体において安全性と使いやすさ・失敗しにくさはトレードオフの関係にある。たとえばパスワードは長ければ長いほど安全だが、ログインにかかる時間は長くなるし、忘れやすくもなる。したがって認証方式には一長一短が出るのだが、それが利用シーンに適した一長一短なのかどうかが問題になる。

さて本棚.orgの場合、破られてもせいぜい知らない本が登録されたり本が削除されたりするだけだ。大した被害ではない。まぁ本が消されてたら困るといえば困るが、そのせいでピザが届いたり壷が届いたりすることはない。一方、myvidoopはOpenIDプロバイダである。ログインIDが一つになって便利だが、一度破られれば自分の使っているあらゆるWebサイトへログインを許すことになってしまう。これは重大な違いだ。

それを踏まえてRecognitionAUTHの安全性を考えると、極めて不安である。まず、写真のカテゴリは3個から最高でも5個までしか選べない。ということは結局のところ、アルファベット5文字で認証するわけだ。単純に組み合わせの数で言うと本棚.orgの一般的なユーザよりは多くなるが、それでもDoSが可能ならばあっという間の範囲だ。それに、打ち込む文字列がワンタイムで毎回変わるというのは一見良さそうに見えても殆ど役には立たないはずだ。キーロガーだけでは破れなくなるが、OCRか単純な画面キャプチャを組み合わせればいいだけの話である。

また、五個のカテゴリのソーシャルな脆弱性を考えると、パスワードよりもなお悪い事が分かる。というのは、「パスワードはakI928DCです」というのよりも「キーカテゴリは猫と船とオフィスです」という方が簡単だし伝播しやすいからだ。口に出すのも恥ずかしいようなカテゴリばかりならソーシャルには強くなるかもしれない。

安心感としても3〜5文字というのは不安ではないだろうか。少なくとも僕は不十分な印象を受けた。それに、設定したカテゴリを忘れないかというと特にそんな自信が生まれるわけでもない。

結論

RecognitionAUTHをボコボコにしてしまったが、結局言いたいのは、OpenIDという利用シーンに適してないということだ。利用方法は実際に簡単なので、その点では優れていると思う。Twitterぐらいのサービスひとつを守らせるなら簡単さが生きると同時に不安感が目立たなくなるだろうから、この仕組みはきっとそのあたりで使うべきものじゃないだろうか。

同志社大学の講義ノート共有サイト、Doshisha Corgi（同志社コーギー）を今日、リリースした。

Doshisha Corgi
http://corgi.uni-kaji.com/

ちょうどWikiのように誰でも講義ノートを編集できる。一人が執筆して皆が買うという従来の紙媒体スタイルにはない、新しい価値を提供できるはずだ。あまり授業に出ていないから一部しか書けないという（僕のような）人でも参加できることや、間違った内容が載せられても見ている人が多ければ修正されやすいことなどがポイントだと思う。

最近はOpenCourseWareなどの教育コンテンツ2.0とも呼ぶべきものが流行しだしているし、Corgiも近い将来には大学生活に欠かせないツールとなってることを期待している。

プラットフォームはASP.NETだ。選んだ理由は単に「触れたことのないものを試してみたいから」だったが、それにしてもマイクロソフトには体力を奪われた。簡単なことが簡単にできなさすぎる…。

ASP.NETはフレームワークとしてはいまいちウリどころが掴めない、というのが正直な感想。小さいシステムに向かなさそうだとは思っていたが、だからといって大規模システムに適すのかどうかも判断しかねる。油断しているとビューとコントローラが密着してしまうのが特に気に入らない。ASP.NETの流れに乗っているだけではロジックを後ろに追いやれなかった。

それに、Web特有のひねりや落とし穴を隠蔽してGUIアプリのような感覚でWebアプリを作れるのかと思っていたが、フタを開けてみればそうでもない。ビューへのデータの送り出し方やエスケープのタイミングなどの明確な指針が存在しないし、結局フォームやセッションを扱うときは通常のWebアプリ開発のノウハウが欠かせない。

あ、ちなみに良いところもある。たとえばバリデーションの扱いは大変優れている。テキストボックスなどの横にバリデーション用の部品を配置するだけで、ルール違反の入力があったときはフォームの送信自体も制御してくれる（かのような演出をしてくれる）。POST時に値をチェックして違反なら戻して…というような泥臭い処理はほとんど必要なかった。

さておき、リリースはしたがこれからが大変なところだ。バグをつぶそう。機能を増やそう。宣伝もしよう。でも本当に有意義だという自信が僕を動かすよ。

正当性云々を抜きにして単純に自分用サーバをSSL対応させる方法のメモ。

事情あって今回はWindows上でApacheを動かしているので、手順の中にはもしかしたらWindowsに依存する部分があるかもしれない。

手順概要は

1. 必要なソフトを入れる
2. 証明書の作成
3. Apacheの設定

手順の意味の簡単な説明

SSLを使うにはサーバが正当であるという証明書と、データ暗号化のための鍵が必要だ。それらのファイルを作成するためにOpenSSLを使う。実際の世の中では証明書リクエストをVeriSignなどの会社に申請し、お金を払って証明書をもらうのだが、今は勝手に自分でVeriSignみたいな役割もしてしまう。

必要なソフト

バージョンは2007/11/11現在の最新版。インストールは適当に。

OpenSSL 0.9.8g
証明書の作成用。公式サイトにはソースしかないが、有志がWindowsバイナリを公開している。
Shining Light Productions - Win32 OpenSSL

ActivePerl 5.8.8
OpenSSLを使う上で必要。既にPerlが動くなら入れなくていい。
このページにはなにやら値段が書いてあるがDLは無料。
ActiveState - Store - ActivePerl

証明書作成（１）サーバ用秘密鍵作成

C:\OpenSSLにインストールしたとして

C:\OpenSSL\bin> openssl genrsa -out server.key 1024
Loading 'screen' into random state - done
Generating RSA private key, 1024 bit long modulus
..................++++++
............++++++
e is 65537 (0x10001)

これでbinフォルダにserver.keyが出力される。

証明書作成（２）証明書リクエスト作成

C:\OpenSSL\bin>openssl req -new -key server.key -out server.csr

リクエスト作成のために情報を入れてもらいます、と言われ、いくつかの入力をさせられる。基本的には適当に入れていけばいいが、
CommonNameにはサーバがアクセスされるホスト名を正確に入力。
Challenge passwordでは何も入力せずにEnter。
Optional company nameにも何も入力せずにEnter。

今回はこんな感じ。

Country Name (2 letter code) [AU]:JP
State or Province Name (full name) [Some-State]:Kyoto
Locality Name (eg, city) []:Kyoto
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Oddwit
Organizational Unit Name (eg, section) []:Oddwit
Common Name (eg, YOUR name) []:www.oddwit.com
Email Address []:info@oddwit.com

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

これでbinフォルダにserver.csrが作成される。

証明書作成（３）証明書作成

C:\OpenSSL\bin> openssl x509 -in server.csr -out server.crt -req -signkey server.key -days 3650
Loading 'screen' into random state - done
Signature ok
subject=/C=JP/ST=Kyoto/L=Kyoto/O=Unikaji/OU=Unikaji/CN=202.11.205.142/emailAddress=info@uni-kaji.com
Getting Private key

-days 3650は証明書の有効期限。別に短くしておく必要はないので10年とかでいい。
これでbinフォルダにserver.crtが作成される。

Apacheの設定

server.crtとserver.keyをApacheのconf\certsに移動。
conf\ssl.confに以下を書き込む（ない場合は近くにあるサンプルファイルをコピーして作成）。

SSLCertificateFile conf/certs/server.crt
SSLCertificateKeyFile conf/certs/server.key

その下にDocumentRootなどの設定をするところがあるが、そこはhttpd.confの設定に応じて設定する。

Apacheを再起動して作業は完了だ。

その他もろもろ

SSLはデフォルトでポート443を使うので、ファイアウォールに穴を穿っておくこと。

これでhttps://…にアクセスできるはずだ。ブラウザに証明書がズルいとかヤバいとかがちゃがちゃと文句を言われるが華麗にスルーしてあげよう。

参考にしたサイトは主にこのあたり。
Apache + SSL
OpenSSL for Windows
OpenSSLのインストール
SSL用証明書の作成（Windows編）

Vitaminの記事が面白かったので紹介。

Web Design-isms: 7 Surefire Styles that Work

昨今のWebにあふれるSweetなデザインを七つの流派に分けて紹介している。

1. コラージュ派（Collagism）

2. 装飾派 (Ornamentalism)

3. 光沢派 (Glossism)
最近はこれが大流行している模様。

4. 文字派 (Wordism)
タイポグラフィー。

5. 未来派 (Futurism)

6. ミニマリズム (Minimalism)
ん～、いいね。

7. レトロ派 (Retroism)

七つというのが何かとても「それは誰が決めたんだ」と思わせてくれるが、参考にはなる。
元記事にはもっとスクリーンショットとリンクがあります。