Research Survey and Memo

AppleからDashboard widget用開発環境「Dashcode」のbeta版がリリース

AppleからDashboard widgetの開発環境である「Dashcode」のベータ版が公開されました．

Tool - Dashcode (Apple)

Dashcode自体はLeopard向けの開発環境ですが、今回公開されたベータ版はTigerで動作するようになっているそうで(当たり前ですよね．普通の人はLeopardを持っていないのだから...)、2007年7月15日まで使えるそうです．

Dashboardは、Macintosh上でしか動作しませんが、Webアプリを通常のアプリケーションのように使えるというのはいいですよね．Mac OS X向けにWebアプリを作ろうと思っている人は、これを使って学習するというのも一つの手としてありだと思ったり．

DashcodeのHow to useに関する公式文書はないように思えるのですが、唯一見つけた文書はこちら
Introducing Dashcode (Apple)

追記:
MYCOM JournalでDashcodeに関する記事が公開されていました．
Leopardを先どり - Apple Dashcodeで楽々Widget (MYCOM Journal)
著者は，Dashboard Widgetに関して本も出されている木下氏です．

そしてもう一つ、精力的にDashCodeの解説をされているWebを発見
Non-Fiction
素晴らしい資料です．

ソフトウェア構成の統合によるセキュリティゲートウェイのスループット向上

Ying-Dar Lin, Chih-Wei Jan, Po-Ching Lin and Yuan-CHeng Lai
Designing an Integrated Architecture for Network Content Security Gateways
IEEE Computer, Vol.39, No.11, pp.66--72, 2006
http://csdl2.computer.org/persagen/DLAbsToc.jsp?resourcePath=/dl/mags/co/&toc=comp/mags/co/2006/11/rytoc.xml

■概要
複数のセキュリティシステム(ソフトウェア)を単一のゲートウェイ(計算機)にインストールするとプロセス間ならびにカーネル/ユーザ空間とのやりとりでオーバーヘッドが発生する．よってソフトウェア構成を改良し、緊密に統合することでオーバーヘッドを減らし、スループットの向上を試みた．

ということで，セキュリティソフトウェアを改良/構成変更し、それらを緊密に統合してみた結果，スループットがあがったよという話．Open Sourceツール群を用いたUTM(Unified Threat Management: 統合脅威管理)の一実装例とその性能評価と思えば良いかな?

■問題
- 計算機の処理能力の向上に伴い，複数の機能を一つのゲートウェイ上にて処理させる事が可能になりつつある．が，その一方で，メーカーはそれをしたがらない．
- 特定機能に特化したデバイスや機器にするのは信頼性やスケーラビリティの点で優れるが，似たような機器を多数管理する事は膨大なコストになる．

-この領域の研究者の興味は，性能向上である．
-その一方で機能の統合を試みる研究者が少ない
-Astaro Security GatewayやFortinetのFortiGate series, L7 Networkのfirewallなどは複数の機能を統合した製品を提供しているが，内部はブラックボックスであり，中の仕組みを知る方法はない．
- よって本研究では，著名な5つのオープンソースのコンテンツセキュリティシステムの統合によるスループットの向上を試みた．

導入したOpen sourceツールは以下の通りである
1. Snort (http://www.snort.org/)
2. ClamAV (http://www.clamav.net/)
3. SpamAssassin (http://spamassassin.apache.org/)
4. amavisd (http://www.ijs.si/software/amavisd)
5. DansGuardian (http://dansguardian.org)

計算機にこれらのシステムを単にインストールしただけの状態(loosely integrated)と，本論文で提案する統合型システム(tightly integrated)とで性能評価を行うとともに，その結果からどこにオーバーヘッドがあるかを特定する

■ Loosely integrated Architecture

オーバヘッドが多い
- Snortはlibpcap経由でデータを受け取るのに対し，E-mailとWebはTCP Stackからネットワークデータを取得している．またこのどちらもがカーネルとユーザ空間でやりとりする必要があるため，そこでオーバーヘッドが生じる

- メールのコンテンツ確認は，以下のオーバーヘッドがある
1. 4回のカーネル/ユーザ空間のやりとり
2. 2回のプロセス間通信
3. 1回のプロセス起動
4. 1回のRAM Diskへのアクセス

- またこの他にamavisdとDansGuardianはプロセスforkする．

■ Tightly integrated Architecture

これらの処理を統合し，プロセス間通信やカーネル/ユーザ空間のやりとりを最小限にした．またprocess forkを防ぐため，threadとIO multiplexingを使用した．さらにSnortは共有ライブラリとし，他のパッケージからその機能を利用できるようにした．

- 共有ライブラリとしてのSnort
共有ライブラリとし，他のアプリケーションからその機能を使用できるようにした．これを利用し，Snortの機能をPacket-Captureプログラムに組み込んで，特定のアプリ/サービスに特化していない攻撃(DoS攻撃など)の検知および防御に対処可能にするような拡張も可能である．

-amavisdのスタンドアロン化
SMTPの処理を行なわせるため，amavisdをスタンドアロン化し，またスケーラビリティ向上のためmultithread化した．select()コールのかわりにthread化した理由は，並列度が下がらないようにするためである．

またClamAVはdaemonモードで動作させることでウィルスパターンの読み込み時間を削減し，SpamAssassinはメモリに常駐させた．またamavisdはSnortの機能を利用しており，不正侵入の検知を可能にしている．

-Webfd
処理速度をあげるために，DansGuardianのかわりにWebfdを利用した．またDansGuardianをライブラリ化し，その機能をWebfdから利用可能にした．またcheckmeという関数がWebfdにはあり，ある統計処理によって得られる値が既定の閾値を超えると通信をブロックする仕組みになっている．
Webfdにはキャッシュ機能がない．シンクライアント等はDiskがないのでその点で問題は発生しないが，キャッシュはある方がよい．今後の課題である．

■ Packet flows
結果としてHTTP,SMTPともにカーネル/ユーザ間のやりとりは1回．
プロセス間通信はSMTPのみで1回になり，オーバヘッドは削減できた．

■ Integration Cost
- 将来的にOpen Sourceのシステムが更新されても，本システムが適応できるようにすべきである．が，OSS側のAPIに大幅な変更がなければ，それは問題なく適用できるはずである．

■ Benchmark Results
■ External benchmarks
HTTPのベンチマークは，WebBench(http://www.veritest.com/bencmarks/webbench/default.asp)を使用し，そのスループットを測定した．
SMTPのベンチマークは，Postal(http://www.coker.com.au/postal)というツールをもとに改良を加えた．これをmail clientとして動作するようにし，かつ添付ファイルに対応できるようにして測定に使用した．メールのサイズは一行の文字列と添付ファイルで合計1MBとした．またその中にはspamやvirusも混ぜ込んだ．

◎ HTTP test results
Webフィルタリングの性能は，コンテンツのサイズに比例した．
Webfdにはキャッシュ機能がないので，公平性確保のためSquidのキャッシュ機能もOffにした．
結果としては，webfdのスループットはsquidの倍になった．
Snortによるコンテンツチェック分の性能劣化も，webfdの方がDansGuardianの場合より少なかった．

◎ SMTP test results
amavisdの導入でスループットは極端に劣化した．
antispamやantivirusの処理はスループットを劣化させるが，amavisdによる劣化を考えれば，対した影響ではない．
tightly integratedの方がスループットは良かった．

■ Internal benchmarks
- HTTPの各内部処理の評価:
gettimeofday()関数やgprofで処理時間を測定
Chariotでトラフィックを生成し，fragrouteでフラグメント化させSnortにパケットの再構成を強制した

- SMTPの各内部処理の評価:
amavisdに実装されているログ機能を利用した．

◎ HTTP test results

1. HTTP requestにおける評価
BannedRegExpURL関数が処理時間の60%以上を占めている
BannedURLとBannedSiteで残りのうちの24%の処理時間を使用
データベースはBannedRegExpURLの方が，他の2つの関数のデータベースよりもはるかに小さいのだが，こういう結果になった．
スループットをより求めるのであれば，BannedRegExpURLは機能をOffにすべき．

2. HTTP responseにおける評価
Content確認処理が90%以上の処理時間を占める
これは不正侵入の分野で知られている結果と同じ結果となった．

3. SnortのHTTP processにおける評価
String matchingの処理が一番時間がかかる．
TCP reassemblyは予想よりも処理時間は小さく，検知においてはボトルネックにならない

◎ SMTP test results
新しいアーキテクチャーでは，ウィルススキャンをメモリ上で動作させているので，ウィルスパターンの読み込み時間が削減され，またamavisdがメールサーバのかわりにproxyとして動作しているので，メールサーバが行っている処理の分が削減されているはずなのだが，amavisdがメールの受信と転送をすることで，その処理時間がメールサーバで実行するのと比較して，それぞれ21%と62%も増加してしまった．これらは新しいボトルネックである．
またメールは，事後処理の前に一旦保存されなければならず，またその後にdecoding, decompression そしてウィルススキャンとスパムスキャンの処理が行われるが，それらの処理はすべてRAM Diskにアクセスして行われる事になるため，結果としてSMTPのスループットはHTTPよりも大幅に低くなるという結果になった．

■ 結論
-プロセス間やカーネル/ユーザ間のオーバーヘッドを減らすため，複数のソフトウェアコンポーネントを統合した
-Webフィルタでは83%，ウィルスとスパムフィルタはおよそ倍のスループット改善が実現できた
-新しいセキュリティゲートウェイにおけるボトルネックは，Webフィルタではstring matchであり，メール処理ではRAM Diskへのアクセスであることがわかった．それらはそれぞれ，処理時間の48%と62%を占めている．
- このアーキテクチャは他のプロトコルのProxyにも拡張可能

この論文の参考文献には，コンテンツセキュリティや不正侵入検知の性能向上に関する論文が挙げられているので，興味がある方は見るべきであろう．

エニグマ暗号のデモ(?)

エニグマ暗号のデモを見つけたので残しておく． Flashで実装されています．

http://enigmaco.de/enigma/enigma.html

当方，暗号に関しては素人ですが，こうやって目に見える形で見せられると，暗号もなかなか興味深いですね．すごくよくできています．
情報の授業で暗号を視覚的に見せて理解を深めてやるのにはもってこいではないでしょうか?

ちなみに，ドメイン名が"enigmaco.deですが，これはenigma codeをもじっているそうな．

ちなみに，エニグマって何? という人は，お約束のWikiPediaをどうぞ
WikiPedia - エニグマ(暗号機)

セキュリティかるた - 日立システムアンドサービス

日立システムアンドサービスが，情報セキュリティに関するキーワードを題材にした「セキュリティかるた」を販売するそうです．価格は1,800円．SEShop.comで12/14より販売するそうです

セキュリティーの要点を楽しく学習 - 日立システム「セキュリティかるた」を発売 - @IT
日立システムが「セキュリティかるた」発売、理解向上を狙う - 「怪しいと 感じたメールは 開かない」など45句収録 - ITPro
「（あ）怪しいと 感じたメールは 開かない」、セキュリティかるた発売 - INTERNET watch

情報セキュリティ大学院大学の板倉征男教授が監修されたそうで，情報セキュリティブログの連載が元ネタになっているそうです．

時期的にもぴったりですね．
また教育方法としても，最近では「ゲームか漫画化が一番よい」なんて言葉も聞かれるぐらいですので，まさにもってこいかもしれません．最近の子供は"かるた"なんてしないだろうから，子供の教育とかるたという伝統的な遊びを教えるという点でもよし，また子供相手ではなくて，大人の教育に使うのもいいかも．

このかるたのセリフを九九算のように暗記させるっていうのも，セキュリティの基礎教育としてありかもなと思ったり(冗談)

PwdHash: Webブラウザの拡張による，より安全な認証システム

Stronger Password Authentication Using Browser Extensions,
Blake Ross, Collin Jackson, Nick Miyake, Dan Boneh and John C Mitchell
Proceedings of the 14th Usenix Security Symposium, 2005
Paper download: http://www.usenix.org/events/sec05/tech/ross.html
Project Web page: http://crypto.stanford.edu/PwdHash/

Webサイト毎に異なるパスワードを透過的に生成する"PwdHash"というシステムの提案で，webサイトのパスワードをPhishingや悪意のあるスクリプトによる奪取に対する安全性向上を目的としたシステムである．
このシステムは，以下の情報からサイト毎に異なるHash化されたパスワードを生成する
1. ユーザの入力したパスワード
2. クライアント計算機に格納されているデータ(Salt) - (これはoption)
3. Webサイト毎に関連付けられたデータ

よって，ユーザは複数のWebサイトに対して同一のパスワードを使用していたとしても，PwdHashが自動的にWebサイト毎に異なるパスワードを生成し，認証に使用することになるので，仮にとあるサイトのパスワードが悪意のあるユーザに漏洩したとしても，他のWebサイトにまで被害が及ぶことを防ぐことができる(つまり他のWebサイトのパスワードはわからない)という仕組みである．

このシステムは，Webブラウザ拡張として実装されており，またクライアントとサーバ間のインタフェースを変更しないため，Webサーバ側の処理を変更する必要がないのも特徴である．

以下は走り書き

■ Intro
- SSLを使っていても"Phishing Scam"で，ユーザは騙され，パスワードを奪取される
- 多くのユーザは，複数のWebサイトで同じパスワードを使っている
=> Crackerは，脆弱なサイトからパスワードを取得し，同じパスワードで他のサイト(銀行等)にも侵入する
- ハードウェアトークンやクライアント証明書がそれに対する対策として挙げられるが，コストと管理負担，そして不便さが増すという点で問題がある

- ブラウザ拡張によるWebパスワード認証の安全性強化"PwdHash"
- サーバ側の処理変更不要，ユーザの操作もほとんど変更なし．初心者でも簡単に導入できる
- Mozilla FirefoxとInternet Explorerにて実装

- 仕組みは簡単，パスワードをクリアテキストで送るかわりにパスワードのhashとドメイン名を送る
- Hashはユーザの入力したパスワードとドメイン名に由来するデータから生成され，サーバ側のパスワードの要件に適合するように変更される
- Phishing対策にもなる，ドメイン名が異なれば，異なるHashとなり，そのHashから正規サイトのデータを得ることは困難なため

- 研究の目標
- Webブラウザの拡張機能によるパスワード認証の強化
1. ユーザ側の操作をほとんど変化させない
2. サーバ側の処理を変更させない

■ Challenge
- 問題点
1. JavaScript attacks
JavaScriptによるform入力の盗難
2. Salting
パスワードをhash化するのに，何の情報を種(Salt)として使用するか?
www.amazon.comとwww.amazon.co.ukが同じ種を使うことをどうやって保証するか?
3. Encoding
どうやってパスワード要件を満たすか?
あるWebサイトは，パスワードに特殊文字が1文字以上含まれていないと許容されない
4. Auto-Complete
システムは，パスワードの自動補完や他のWebブラウザの機能と互換性があるべき
5. Password reset
システム導入後に，既存のパスワードをHashパスワードに変更する必要がある
これが簡単にできるべきだ
6. Roaming
ユーザの一部は，使用するコンピュータに本システムのインストールを許可されない場合もあるだろう．そういった場合の対応は?
7. Dictionary Attack
PhishingサイトはHash化されたパスワードを取得したあと，辞書攻撃をしてくる可能性がある．この危険性を減らすにはどうしたらよいか?

- これらの問題は3つのカテゴリに分類できる

1. password hash functionの実装問題
Salting, Encoding, Dictionary Attack

2. ブラウザ環境でのシステムに関する問題
JavaScript attack, Auto-Complete

3. ユーザ操作/環境に関する問題
Roaming, Password reset

- HTML formのblurイベントをきっかけとして，passwordフィールドの内容をhash化する
- 本システムは，blueイベントを受け取り，passwordフィールドの内容をplain textから，hash化した文字列に置き換える．つまり，ユーザがformにパスワードを入力し終わると，入力したパスワードが自動的にHash化されたものに置きかわるという仕組みである

- しかし，この実装方法だとJavascriptによりパスワードを取得することがまだ可能である．
=> keyboard monitoringによる方法
=> domain rewritingによる方法
=> mock password fieldによる方法
=> online mock password fieldによる方法
=> password reflection attackによる方法

■ さて，どうする
- 種々の攻撃手法を考えると，秘密情報の一部としてドメイン名をそのまま使用するのは危険
- 他のアプリケーションとして，ログイン画面が出現したら，そのアプリケーションを起動し，その中でパスワードをHash化するという方法もあるが，ユーザの操作を変更させたくないので，ブラウザ拡張として実装を試みる．では，安全性を確保するためには，WebアプリケーションがFormの値にアクセスする前に，我々のシステムが入力値にアクセスできなければならない．

- 新しい仕組み:
1. password-prefix: ユーザが今まさにパスワードを入力していることをPwdHashに知らせる仕組み
2. password-key: PwdHashが今入力されているパスワードを保護する仕組み

■ Passworf Prefix
- ある特定の文字列を使って，ユーザが入力をHash化するかどうかを能動的に選択可能にする仕組み
- 今回は"@@"を使用したが，なんでもよい．(でも，英単語はまずいだろう)

- PwdHashは2つの動作モードがある

1. normal mode
入力された文字をそのままWebページに渡す

2. password mode
- 入力はPwdHash内に記録され，かわりに変換テーブルによって変換された別の文字列がWebページに渡される
- つまりpassword modeに入ると，キー入力はPwdHash内で記録され，Webページには渡らなくなる．これによってJavaScriptによるキーロガーから保護することが可能になる．

- PwdHashは全てのキー入力を監視しており，"@@"を検知すると，normal modeからpassword modeになる．逆の状態遷移は，入力フォームからfocusがはずれた時である．

- Hashが行われるタイミングは2つ．どちらを使用するか選択可能
1. focusがpasswordフィールドから外れたとき
2. submitボタンが押されたとき

- パスワードフィールドにfocusがないときに，password-prefixが入力された警告する．
これにより偽のパスワードフィールドによる攻撃をユーザに通知することが可能になる．

- このpassword-prefixは，以下に挙げる別の利点も生む
1. PINや社会保障番号をPasswordフィールドにて入力することがある．こういう場合はpassword-prefixを入力せずに，それらを入力すればよい．今まで通り使用することができる
2. パスワード更新時も同様である．古いパスワードはpassword-prefixを入力せずに入力し(clear textでwebページに渡る)，新しいパスワードはpassword-prefixを入力してから入力すればよい．

つまり，ユーザが自分自身で，どのパスワードをHash化するかを選択できるということである

■ Password-key
- 基本的にpassword-prefixと同じ
- password-prefixが，特定の文字列をパスワード入力の前に入力するのに対し，password-keyは，特定のキーをパスワード入力の前に打鍵する
- どのキーでもよいが，今回はメジャーなWebブラウザが使用していなかった「F2」キーを使用
- password-prefix同様，passwordフィールドにfocusがないときにpassword-keyを押すと「これはpasswordフィールドでない」という旨の警告を出す

- どちらが良いかというと，password-prefixの方が良いと考える．理由はパスワードの先頭に「"@@"をつけてね」と言えば，ユーザにpassword-prefixを意識させずにすむからである．
- 本システム導入後，password keyを使用してパスワードの更新をさせたら「古い方はpassword-keyを押さずに入力，新しいパスワードはpassword-keyを押してから入力」という指示が必要となり，ユーザは混乱をきたす可能性がある．
- もちろん，どちらも実装されており，選択可能

- なおPwdHashは，key loggerやspywareに対する安全性は保証できない．言いかえれば，PwdHashはkey loggerと同様の仕組みでkey入力を監視していると言えるからである．ただし，この仕組みがKernelやVMに実装されれば，これらの脅威に対する対策にもなると考えられ，それは今後の課題である．

■ Password traffic light
- Pwdhashのオプション機能
- Password入力が保護されているかいないかを，信号機の赤青灯で表示
- password modeになっているときは青，それ以外は赤
- focusがpasswordフィールド以外のときも赤
- 初心者はそんなものは見ないので有効性に疑問が残るが，セキュリティ意識の高いユーザには有用な機能，
- Focus stealing attackにも有効だと考えられる
- ただし，このtraffic lightを偽装する攻撃も起こりうるのは事実

■ Keystream monitor
- 危険なユーザの行為を検知するために，key streamを監視する
- 2つの処理

1. recording component
ユーザがpassword-modeの際に入力したパスワードを捕捉し，そのHash化した文字列をDiskに記録する．

2. monitoring component
key streamを監視し，ユーザのパスワードに一致する文字列が安易にWebページに渡されないよう監視し，それがpassword-modeでないときに発生したら，ユーザに警告する

-しかし問題もある．
1. ここまでしても，online mock attackには効果がない
2. Hash化されたパスワードをディスクに記録すると，侵入者や内部犯によるOff-line crackingの脅威が発生する
3. 初心者は，key streamに偶然現れるような文字列を設定しがちである．そうすると，システムにより頻繁に警告が発せられ，それが逆効果となって警告を無視するようになってしまう可能性もある

■ Auto-Complete
- Hash化されたパスワードも，されていないパスワード同様自動補完される．特に問題なく動作する．

■ Salting and encoding issues
- Hashに使用する種(Salt)は，Webサイト毎に異なり，かつ偽装に対する耐性がなければならない．
- どのデータ(ドメイン名)をSaltとして使用するか

1. 現在のページが存在するドメイン
- 自然な選択，phisherがタグを埋め込みデータを搾取する恐れはあるが，Cross-Site Scriptingの脆弱性も認知されつつあり，無害化されつつある

2. Formデータを受け取るドメイン
- これも適切に見えるが，domain rewriting攻撃によりFormによるデータ送信先を改竄さ
れるとパスワードを漏洩させることになる．これを防ぐためには，送られてくるHTMLをparseし，formのaction fieldを検証しなければならないが，これは容易ではない．

3. SSL証明書にあるドメイン

よって，本システムは現ページのドメイン名をSaltとして使用する．

■ General salting complications
- 問題も残っている
1. 違うドメイン名のWebだが，パスワードは共通 (amazon.comとamazon.co.uk)
2. ログインページとパスワードリセットページが違うドメインにある場合
- 特別な例として考える(4.5章 Special Caseで考察)
- パスワードのやりとりに GET method を使うべきではない

■ Salting with SSL certificates
- SSL証明書の組織名もsaltとして使えそうだが，以下の懸念によって使用を断念
- 違うドメインでも同じSaltとなり，前述のamazonの問題を解決できる可能性もある
1. CAから証明書を取得していない証明書が多数ある => ユニーク性を保証できない
2. 本システムがインストールされていないシステムを使用しなければならない場合，SSL証明書からユーザが自身でSaltデータを取得しなければならない
3. SSL証明書を持っていないWebサイトも多数ある．

■ Encoding
- パスワードの要件への対応．数字を混ぜろ，特殊文字を最低1文字は入れよという要件に対応しなければならない．
- 特例をつくって対処
- 本システムでは採用していないが，ユーザの入力したパスワードを検査し，それに応じてHashをencodeするという方法もある．これだとユーザの手間は削減されるが，パスワード情報の一部が漏洩する恐れもある

■ Special cases
- 特別な対応が必要な場合は，特例として扱う．これは設定ファイルでドメイン毎に設定することができる
- <ドメイン名指定，Saltの指定，Hashアルゴリズムの指定>という記述
- この設定ファイルは，サービス提供側が用意し，ユーザに配布してもよいし，ユーザが自身で設定してもよい
- このファイルは改竄に注意しなければならない

■ Dictionary attack
- 辞書攻撃の可能性はある．Hash関数はよく知られているものであり，時間をかければ20%前後のパスワードはcrackされる可能性がある．
- 2つの対策方法で対応

1. Slow hash function
動作の極端に遅いHash関数を使用する

2. Short secret salt.
pepperとも呼ばれる手法で，サーバ側の対応が必要となる．複数回のログイン処理をし，...?

- 複数回の試行失敗によるロックも実施

- 実装されている他の対策法としては，global passwordがある．全ドメインに対してSaltの一部として使用されるpasswordで，phishierは，ドメイン毎のパスワードの他に，このglobal passwordも推測しなければならなくなる．
- key exchange protocolの使用もありうる．が，これはサーバー/クライアント共に実装を変更する必要がある

■ User interface and usability issues

■ Password reset after extension install
- 本システムをインストールしたら，すべてのWebサイトのパスワードを変更する必要がある．
- password-keyでのパスワード更新は面倒かもしれないが，password-prefixなら簡単であろう．ユーザはどこをhash化するかさえも知る必要がない．

■ Roaming
- 会社の規則，インターネットカフェ，友達の計算機等，本システムをインストールできない場合はどうするか?
- Hash passwordを生成するWebサービスを用意することで対応．ドメイン名とパスワードを入力すると，hash化されたパスワードを返す．JavaScriptで実装されているので，hash化されたパスワードをネットワーク上に流すことはない．
- bookmarkletという方法もある
- これらは本システムの代替となるものではなく，あくまで非常用という扱いである．

■ Password updates
- Webサイトの重要性に応じていくつかのパスワードを作り，本システムを使用する．
例えば，金融関係のサイトのパスワードは，共通して"mym0ne-"だとする．この状況で仮にとある金融サイトのパスワードが漏洩したとしても，他の金融サイトのパスワードを変更する必要はない．PwdHashがドメイン毎に違うパスワードを生成し，パスワードにしているからである．

■ Implementation
1. Internet Explorer
略
2. Mozilla Firefox
略

■ Limitations
- いくつかの限界(制約)がある
1. Other application
WindowsではIEのlayout engineが他のアプリケーションでも使用されているが，それらのアプリケーションの全てがBrowser Helper Objectを左ポートしているわけではない．PwdHashをより汎用的にするためには，実装をengineに統合するようにしていかなければならない．

2. Spyware
スパイウェアやキーロガーのように計算機にインストールされて機能するような脅威には意味がない．またhostsファイルを書きかえることで行うようなphishing攻撃にも意味がない．もちろん，侵入者が計算機にソフトウェアをインストールしたり，hostsファイルを書き換えられるようならば，PwdHashを無効化することも容易であろう．

3. DNS Attacks
PwdHashはDNSが正情稼働していることに大いに依存している．よってDNSをだますことができれば，攻撃者はそのドメインのパスワードを取得することができてしまう．またPwdHashは，HTTP response splittingやweb cache poisoning攻撃にも脆弱である．

4. Flash
Flashでは，Flashにパスワード情報が渡る前にブラウザーの拡張機能がパスワード文字列を横取りする機能がないため，侵入者にパスワード情報を奪取される可能性がある．これは将来的に，OS，ブラウザ，ブラウザ拡張そして外部プラグイン間のインタフェースが改善されることを待つしかない．

5. Focus Steamling
興味深いJavascriptによる攻撃の一つに，ユーザがパスワードを入力している最中にフォーカスを変更し，パスワードフィールドから他のフィールドへフォーカスを移してしまう方法がある．Traffic lightというアイデアがこの攻撃を通知するが，それを知ったときにはすでに手遅れになる可能性もある．これに対する対策方法として，password suffixがある．これはユーザがパスワードを入力し終わったことを示し，password modeからnormal modeに処理を戻すことを示す．が，若干面倒である．もう一つは，Javascriptをoffにするか，focusが移されることを防ぐなんらかの方法を導入することである．

■ User study
- 5人のプロフェッショナルにユーザ評価を実施した．
- password prefixを使用して評価をしたが，ほとんど問題なく使えていた．またphishingサイトへのログインも試してもらったが，ドメイン名が数値によるIPアドレスだったので，正規のサイトで使用しているパスワードをphishingサイトへ漏洩させなかった．
- 気がついたこととしては，lockアイコンに誰も気づかなかった．
- PwdHashが入力したパスワード文字列の長さを変更してしまったことに驚くユーザがいた
- ユーザの一人が，PwdHashがインストールされていないブラウザでログインしなければならない状況になった．その際にremote hash pageを使って，hash passwordを生成してもらったが，その際にうまくremote hash pageを使用できなかった．それはドメイン名を間違って入力しており(gmail.comとgoogle.comとか)，その状況で，ユーザは何がいけないのかがわからなかった．

■ Related works
- proxyによる実装
SSLによる問題がある

- Java appletによる実装

- Browser拡張による実装
-- "The password maker extension"
ユーザインタフェースに問題．パスワードを入力するための手段が大幅に変更されてしまうので，ユーザの習熟を要する
-- Password Composer
hash passwordをsuperimposeする．bookmarkletやGreasemonkey scriptも用意されている．が，亜杭のあるスクリプトによってパスワードを奪取されるおそれがある上，spoofingされる恐れもある．

Pwdhashは他のanti-phishing手法を排除していない．SpoofGuardやPassmarkとPwdHashは互いに相互補完できると考えている．

- Hash passwordへの辞書攻撃を困難にするために，Ultra-slow hash関数を使用している．

- 多くのブラウザが搭載しているパスワード管理システムや"Password safe"とPwdHashの比較は，
-- マスターパスワードさえ記憶すれば，多くのパスワードを管理可能
-- パスワードを記憶している計算機を使用しなければならない
-- ユーザが安全性の高いパスワードを使用すれば，辞書攻撃に対する安全性強化になる

■ Conclusion
パスワード認証を改善するため，Webブラウザの拡張として実装したPwdHashを提案した．これはユーザのパスワード入力に関する方法を変更せず，かつ，サーバ側の処理を変更する必要もない方法でもある．本手法では，ブラウザ内部でパスワードをhash化するため，悪意のあるスクリプトによるパスワードの奪取を困難にしていることであり，またユーザインタフェースの変更を最少限にしているため，ユーザ評価でも大きな混乱もなく使用できていた．

ゼロデイ攻撃公表サイト - eEye Zero-Day Tracker

eEye Digital Securityがゼロデイ攻撃によって修正方法(patch等)が公開されていないままになっているセキュリティ脆弱性情報を公開するサイトを始めたそうです．

米セキュリティ企業、ゼロデイ脆弱性情報をまとめたウェブサイトを開設 (CNET)

というわけで，記事中にもありますが，そのWebサイトはこちら

Zero-Day Tracker

でも，ふと思う．これはどんな人をターゲットとした情報になるのだろう?
少なくとも一般ユーザではないことは確かだと思うのだが．でも、一般ユーザにアピールしているようにも見える．でもって、誰にこの情報を届けたら、それがセキュリティ対策として有効なのだろうか?

なぜ一般ユーザには意味がないのか．それはすぐにわかるだろう．一般ユーザに対して、「こういう脆弱性がまだ放置されているから気をつけろ!」 と言っても「何をどう気をつければよいの?」とユーザはとまどうだけだからある．そう，patchが公開されていない以上、一般ユーザにとってはHowがないのだ．そしてpatch以外の対策方法は、大抵の場合、簡単には行えないものである．

情報として公開されることに意義があること自体は疑いの余地はない．
これらの情報によって，なんらかの対策なり，行動が起こせる人もいるからだ．
でも、本当はこういう情報を誰に届けるべきなのだろう? やはりそういう脆弱性が見つかったシステムの開発者だけなんだろうか... うーむ．

良いパスワードをつけさせるためにユーザに与えるべきアドバイスはなにがよいのだろうか?

Password Memorability and Security: Empirical Results
Jeff Yan, Alan Blackwell ,Ross Anderson and Alasdair Grant
IEEE Security & Privacy, September/October 2004.

パスワード認証における弱点の一つは，脆弱なパスワードをつけてしまうことである．これに対し，パスワード決定のためのアドバイスをすることが多々あるが，それが果して有効なのか? (そのアドバイスによって，ユーザは安全なパスワードをつけるようになるのか?) についてユーザ実験により検証を行った．

つまり，パスワードを決定する際にあたえる「アドバイス」には何が有効か? を実験を通じて検証した論文．

結果として，「X文字以上で，推測が困難なパスワードをつけるように」というアドバイスは意味がない，つまり何もアドバイスをしないのと有意な差異が得られないことを証明している．

以下は走り書き

■ 導入
* 人は，大抵 7文字 プラスマイナス 2文字程度の文字列しか覚えていられない
* ユーザは敵ではない，だが，システムの安全性を維持するためには有益な情報を与えることが必要

* 良く使われてる，パスワード決定のためのアドバイス
- パスワードには数字や特殊文字を混ぜろ
- 辞書に載っている単語は使うな
- 大文字小文字を混ぜろ
- 書き留めたパスワードを，他人の目につくところにおくな
- ランダムパスワード生成器の出力を使え，そしてそれを発音可能な単語に置き換えて覚えろ，またアクセントのあるところは大文字にしろ
- よいパスワードはランダムな文字列だ
- あるフレーズ(文章)を考え，その各単語の頭文字を抜き出してパスワードとせよ，ただしありがちなフレーズは使ってはならない

* よくあるアドバイス
「8文字以上で2文字以上の数字か特殊文字を混ぜよ．そして月に一回変更せよ」
- ユーザのする行為
Juliet03, Juliet04...と月の数字を変えてパスワードを更新する
- こういった類のアドバイスは，ユーザによる回避行動を助長するだけ
- どういうアドバイスが，実際に有効なのか? を考えなければならない

■ 評価実験
- ユーザを3つのグループに分け，それぞれ異なるアドバイスをあたえる
1. control group:
「7文字以上で，少なくとも1つは特殊文字か数字を混ぜること」
2. random password group:
「8文字のランダム文字列をパスワードとせよ，なおパスワードが記憶できるまで，そのメモを持ちつづけるべし」
3. pass phrase group :
「ニーモニックに基づくパスワード．つまり文章(フレーズ)を考え，その文書の各単語の頭文字または最後の文字を抜き出してパスワードとせよ．7文字以上で，1つは特殊文字を入れよ」

- これに対し，4つの攻撃手法で攻撃を行った
1. 辞書攻撃
2. 文字および数字の置換による攻撃
3. 個人情報による(推測)攻撃
4. Brute-force攻撃 (6文字によるすべての回答で実施)

- 実施期間は4ヶ月
- 比較対象として，実験に参加していないグループのデータも収集

■ 実験結果
- パスワード長の平均は，7と8の間．実験に参加していない母集団の平均よりも若干長かった．
- 「文字および数字の置換による攻撃」が一番攻撃に成功した
- 「個人情報による推測攻撃」が，一番攻撃成功率が低かった．理由は推測に使用した母集団の情報が少なかったからと推測される．
- もちろん，6文字によるパスワードはBrute-force攻撃によって攻撃に成功した．アドバイスに忠実であれば，6文字のパスワードをつけるはずがないので，これはアドバイスを無視したケースであるといえる．
- もちろん，6文字によるパスワードはBrute-force攻撃によって攻撃に成功した
- 6文字以上のパスワードで，もっとも攻撃に成功したのはcontrol groupであった．しかし，その成功率は，アドバイスなしの比較対象グループよりも低かった．
- random passwordとpass phrase passwordでcrackされたパスワードは，すべて置換攻撃によるものであった．
- pass phrase password以外の被験者で，特殊文字をパスワードに使用したユーザはいなかった．つまり，アドバイス中に特殊文字を入れることを明記した方が良いということがわかる
- パスワードのリセットをシステム管理者に依頼するユーザはほとんどいなかった

- 電子メールで被験者に以下の2つについてアンケートした
1. 記憶可能なパスワードを見付けるのはどのくらい大変か? 5段階で答えよ
2. どのくらいパスワードのメモを持ち歩いたか? 週単位で答えよ

- random password groupは，決定も記憶維持も難しいと回答
- random password groupの多くは，いまだにメモを持ち歩いている

■ 何が真実か?
- 真実: ランダムパスワードは覚えられない
- 真実: Passphraseに基づくパスワードは，普通に設定されたパスワードよりも推測に強い
- 疑惑: ランダムパスワードはpassphraseベースのパスワードより安全
- 疑惑: passphraseベースのパスワードは，普通に設定したパスワードより記憶が難しい
- 疑惑: ランダムパスワードやpassphraseベースのパスワードを使用するように教育すれば，システムの安全性は改善する．
これが疑惑である理由は，全てのユーザがその規則を守らない限り，脆弱なパスワードが攻撃され，システムに侵入されることで，安全なパスワードをつけていたユーザもなんらかの被害に会う可能性があるからである．よって，一部のユーザの怠慢によりシステムの安全性が低下しないよう，規則遵守の強制と監視はユーザの教育と同様に重要である．

■ 推奨されるアドバイス
- mnemonicに基づくパスワードを使用するようにせよ
- パスワードはできるだけ長い文字列にせよ．またシステムにより制約にも注意を払え
- 規則遵守はもっとも重要な点である．
- 統一された払い出し機構によるランダムパスワードを使用するならば，パスワードがランダムであることよりも，統一して払い出せることによる利点，つまり規則遵守を実現可能であるということに注目せよ．

- 今後の興味深いチャレンジは，mnemonicベースのパスワードで規則遵守を実現(強制)できる枠組の探求である．Proactive Password Checkerは，効果的なツールかもしれない

セキュリティ対策を行わせる上で「なるほどな!」 と思ったこと

東京国際セキュリティカンファレンスに参加してきた．
http://www.tokyointersec.com/

その中の講演で「なるほどな〜」と思ったことがあったので書く．

それは，「Firewall(ファイアウォール)がなぜ市場で成功をおさめたか?」である．
その理由は以下の通りであると述べていた．

=> 監査人が設置しろと言ったから
==> Firewallを設置しないと監査が通らない
===> 監査が通らないことによるコストは，Firewallを設置するコストよりも大きい
====> だから設置する

つまりFirewallの設置が進んだのは， 決してFirewallがセキュリティ対策として有効だという認識が広まったからではない．それどころか，多くの組織でFirewallが設置されたとしても，それがきちんと設定され，かつ運用管理されているわけではなく，それゆえ現状ではFirewallがセキュリティ対策として有効に機能しているとはほど遠い状況であると推測されている．

なるほど!，やはり基本はコストか...．でも，この話，納得できる話でもある．
またFirewallを設置していないと，訴訟で追求される恐れもあるらしい．

つまりインターネットを利用して商売をするのであれば，業界の常識(最低限のセキュリティ対策)として「Firewallの設置」はすべきであり，それをせずにセキュリティ問題を発生させ，それに関して訴訟を起こしても「しかるべき対策を怠った」と指摘される可能性大だということである．やはり，自らに生じた意識ではなく，外圧なんですね．

また同じような効果は，保険でも生じ得るらしい．保険は「リスク」という変動費用を固定費用に変えるため，経営者には好まれるらしい．そして保険会社もあらたな分野として開拓を始めている．しかし，保険を提供するからには，保険加入者がある一定の条件を満たしていることが重要であり(誰でも保険加入を認めていたら，保険会社が危機に陥るため)，その条件として得低レベルのセキュリティ対策が実施されていることが要求される．つまり，保険に加入するために，一定レベルのセキュリティ対策をする必要があるということになるからである．

ってことは，やはり法律か訴訟コストが増すというぐらいの状況が発生しない限り，やはり企業もセキュリティに対する意識は上がらないってことかなと思ったり．そういう意味では，もうすぐ施行される内部統制という外圧は，状況をさらに変化する可能性はあるかなとも思ったり．

しかし，我思う．どこのセキュリティ関連のカンファレンスやシンポジウムに言っても「企業や個人のセキュリティに対する意識は低い，これをどうにかしなければならない」と皆が口を揃えて言っているが，では「そのためになにをすべきか，どうしていくべきか，どうしたらよいのか」の提言がほとんどない．いや，まったくない．まるで自然にそうなっていくのを待っているのか，それとも，そうならない方が議論をしている人達の利益になるから放置しているのかも(?)と疑ってしまいたくなるぐらい，そういう議論がない．本当に「暖簾に腕押し」の議論を繰り返しているようで，滑稽である．

当方はこう思う．ユーザの意識や企業の意識はそうそう変わらないであろう．

やはりコストか法的な軽罰がない以上，そこにお金をかけるという意識は出てこないのが自然であろう．ならば，そういう枠組を作って行くしかない気がする．セキュリティ上の問題が発生した場合，被害者になる側にそういうコストや法的な軽罰を課すとはどういうことだ! と憤慨する方もいるだろう．たしかにおっしゃる通りであり，当方もそうなって欲しくない．が，残念ながら，インタネットに接続した時点で，あなたの使用する計算機は一つの国となり，そしてあなたは国家元首としてその国を守らなければならないのである．でないと，他の国からミサイルを打ち込まれ，そしてあなたの国(計算機)は，他の国の属国(踏み台計算機)となって，さらに他の国を攻撃/侵略するものとなってしまうからである．

うーん，話が変な方向に転んだ．とにかく，セキュリティに対する意識を変えていかなければいけないということは理解できるし，同意である．が，その一方で，その実現は自然に放置したままで醸成されていくとは到底思えない．ならば，どうすべきか，どうしたらよいかという議論をもっとしていかなければならず，当方としては，やはり強制力なくして，この実現は無理だろうと現時点では考えるのだ．どうだろうか?
でも，こういっている時点で，当方も思考停止なのかもしれない．なにかよい方法はないものだろうか...
人は目に見えないものを信じようとしない，そして体験したことのないことはわかりようがないと考える．そして情報セキュリティのリスクは，他のリスクと比較すると比較的小さなものだと考えている人が多い．この状況を変えるためのよい方法は一体なんだろうか?

なおこの会議，無料で参加可能だが，内容は大変興味深いものであった．来年も是非参加しようと思う．