December 08, 2006
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化するため，悪意のあるスクリプトによるパスワードの奪取を困難にしていることであり，またユーザインタフェースの変更を最少限にしているため，ユーザ評価でも大きな混乱もなく使用できていた．