2006年10月21日
■ ワンタイムパスワードは何のためにあるのか
先月、ジャパンネット銀行から「SecurID」が送られてきた。RSAセキュリティのワンタイムパスワード生成器（以下「トークン」）だ。ジャパンネット銀行は全口座の利用者に対してこれを配布している。
届いた郵便物には図1の案内状が入っていた。
ここに書かれていることは事実でないので、信じてはいけない。
2. トークンはスパイウェアに監視されないので安全です。
トークンはパソコン、携帯電話などと一切の通信を行いません。万が一パソコンや携帯電話がスパイウェア（不正プログラム）に感染しても、トークンに表示されたワンタイムパスワードが監視されることがなく安心です。
これを読んだユーザは、「今後はダウンロードした .exe ファイルを安心して実行できる」と思ってしまうかもしれないが、トロイの木馬（不正プログラム）を実行してしまっては、たとえこのワンタイムパスワード生成器を使っていようとも、不正送金されるという事態は起こり得るのであり、「パスワードが監視されることがなく安心です」という宣伝文句を信じてはいけない。
スパイウェア（不正プログラム）はキーロガーだけではない。不正プログラムがユーザのコンピュータに入り込む余地があるということは、任意のプログラムが入り込み得るわけだから、ユーザがログインしたのを見はからってログインセッションを乗っ取ることができてしまう。こうした攻撃が英語圏では既に発生しているらしいという話は、2月22日の日記にも書いたとおりだ。
- 口座預金を略奪するトロイの木馬がまん延--セキュリティ研究者が注意を呼びかけ, CNET News, 2006年2月20日
ジャパンネット銀行のWebサイトでの説明ページでは、少し違う言い回しがされている。
トークン方式のワンタイムパスワードの安全性
(2) トークンはスパイウェアに感染しません
トークンはお取引にご利用されるパソコン、携帯電話などと接続して使用するものではなく、また、一切の通信を行いませんので、万が一パソコンや携帯電話がスパイウェアなどの不正プログラムに感染し、パソコンや携帯電話内の情報がすべて監視されていた場合でも、トークンに表示されているワンタイムパスワードを監視されることはありません。
ワンタイムパスワードのご案内, ジャパンネット銀行
トークン自体がスパイウェアに感染しないのは事実だろうし、トークンに表示されているものが監視されるわけではないのは事実だろうけども、パスワードを送信しようとして、ユーザがトークンから目でコピーしてブラウザに入力しているそのワンタイムパスワードは、不正プログラムならば監視できてしまう。
「ワンタイムパスワードは再利用できないので安全です」というが、たしかに、ワンタイムパスワードは再利用ができないが、再利用ができなければ安全だなどと、誰が言い出したのだろうか？
トークン方式のワンタイムパスワードの安全性
(1) ワンタイムパスワードは再利用できません
ワンタイムパスワードは、60秒ごとに使い捨てパスワードが自動発行され、一度使用したワンタイムパスワードは無効となりますので、万が一フィッシングなどでワンタイムパスワードが盗まれた場合でも、それを再利用し、不正に取引されることはありません。
ワンタイムパスワードのご案内, ジャパンネット銀行
微妙な言い回しだ。たしかに、再利用はできないのだから、「再利用によって不正取引される」ことがないのは事実だが、一回目の利用としてその瞬間（30秒以内）に不正取引される可能性があるのだから、「万が一フィッシングなどで……ありません」などと、フィッシングされても大丈夫であるかのような誤解を与える表現は危険だ。
昨年10月17日の日記「銀行やマスコミは対策の有効性の範囲で嘘を書いてはいけない」でも書いたように、誇大な安全宣伝は無責任であり、自分の首を絞めることになる。
これらはたぶん、わざと誇大に書いているのではなく、危険性に気づかなかったか、単に業者の宣伝文句を真に受けただけか、あるいは業者自身が無知で誤った宣伝をしているのだろう。
どうも、セキュリティベンダーは（さらには学術研究の場でさえしばしば）、ワンタイムパスワードがフィッシング対策や、スパイウェア対策になるという誤解をしているようで、困ったことだ。
たとえば、「SecuSURF SA」という製品の説明にも次のようなことが書かれている。
（略）は、フィッシング詐欺や「キーロガー」（キーボードからの入力を監視して記録するスパイウェアの代表格）などで不正に取得された本人確認情報の第三者による「なりすまし」利用を防ぐ高度認証ソリューション「SecuSURF SA」の販売を本日から開始します。
インターネット環境においてフィッシング詐欺やキーロガーにより不正に入手されたログイン情報を使った「なりすまし」を防ぐために、従来の単純なパスワードによる知識認証方式に替わり、より強固な認証機能が求められています。認証のセキュリティ強度を上げる方策としては、ICカード等の媒体認証、生体認証、ワンタイムパスワード認証などがありますが、いずれにおいても専用の装置が必要となり普及は難しい状況にありました。（以下略）
携帯電話を利用したワンタイムパスワード方式の高度認証ソリューション「SecuSURF SA」を販売開始, 野村総合研究所, 2005年11月7日
なぜこのような誤解が生じているのか考えてみた。
SecurIDは、消費者に使われるようになったのはごく最近のことだが、企業や団体では、従業員が社内システムに社外からアクセスする際に使用するなどの目的で、20世紀末から普及していた。この実績から、「SecurIDは安全性が高い」「コストが高いので普及しないだけ」という理解が広く浸透していたのだと考えられる。
コストが高い（配布の手間も含めて）ために、不特定多数の消費者向けの用途としては普及しなかったわけだが、そうも言っていられないほどの状況がここ数年で出てきたため、三井住友銀行をはじめ、ジャパンネット銀行もSecurIDを採用したのだろう。
そして、ここ数年で被害の原因として目立っているのは何かというと、フィッシングとスパイウェアである。だから、「SecureIDでフィッシングとスパイウェアから守れる」という短絡思考が生じているのではないか。
たしかに、ビンゴカードのような乱数表を使うくらいなら、ワンタイムパスワード生成器にした方が安全性が格段に違うというのは、その通りであり、三井住友銀行がSecurIDを採用したときは、セキュリティを理解しているはずの技術者達も絶賛したようだった。
- 三井住友銀行がワンタイムパスワード採用, スラッシュドットジャパン, 2006年1月13日
フィッシングやスパイウェアによる被害を防げるわけではない。では、SecurIDが安全であるという皆の理解はいったい何だったのだ？ ということになる。
ワンタイムパスワードが安全であると言われた時代は、フィッシングなどという手法でユーザがこうも騙されて偽サイトに入れてしまうとは、想定していなかったのだろう。スパイウェアも然りで、それを想定するともはやどうにもならないので、想定しない前提で安全であると言われてきただけだ。
じゃあ、フィッシングもスパイウェアも想定外との前提を置いた場合に、ワンタイムパスワードの効用は何なんだということになるが、たとえば、「盗聴されても再利用できないので安全」という主張を検討してみると、盗聴されればセッションハイジャックされてしまうので、安全ではない。
「後ろからパスワードを覗かれても再利用されない」というのは概ね正しいだろう。他にはないのか……。
改めて考えてみるに、ワンタイムパスワードの効用とは、パスワードの安全レベルの管理が、ユーザではなく、アクセス管理者にコントロールされているところが肝ではなかろうか。
つまり、普通のパスワードだと、パスワードの安全レベルが、ユーザの力量に依存してしまう。パスワードの変更を許せば、安易なパスワードを付けるユーザが出てくるし、変更を許さず複雑なものを与えると、パスワードをメモしてモニタに貼り付けるユーザが出てくる。ここで、ワンタイムパスワード生成器を配布すれば、安易な内容のパスワードになってしまうことは避けられるし、メモさせず、物として管理もさせやすい。
一般のWebサイトなどでは、ユーザのパスワードの安全レベルは、ユーザの自己責任で決められている。パスワードが弱くて被害が出てもユーザの責任と主張することができるだろう。それに対し、企業が社内システムへのリモートアクセス用にアクセス制御機能をインターネットに開くときは、一人でも弱いパスワードを付けるユーザがいるだけで、社内システムが危険に晒されるわけだから、ユーザの責任でというわけにいかない。これが、SecurIDが企業等に先に普及していった本当の理由ではないか。
さて、そうすると、銀行がワンタイムパスワード生成器を導入したのは勇み足だったのか？ ということになるが、そうではない。今年の2月から預金者保護法が施行された。預金者保護法は、偽造カードと盗難カードによる被害を対象としており、インターネットバンキングでの被害は対象としていないが、考え方としては共通しており、将来、インターネットバンキングにも対象が広げられるかもしれない。この法律により、一定の基準のケースにおいて、銀行側が被害を補償しなくてはならないようになった。つまり、「パスワードが弱いのはユーザの責任」とは言っていられない状況が強まった。
だから、今こそ銀行がワンタイムパスワードを導入するというのは正しい。ただ、その理由が間違って宣伝されている。
■ Session Fixation脆弱性の責任主体はWebアプリかWebブラウザか
CSRF対策の話題で、Internet ExplorerのCSSXSS脆弱性に配慮するべきだという主張が出た際に私は、それはWebブラウザの脆弱性でありWebアプリ側の責任ではないとした。その理由は、hiddenが漏れるならどのみち別の方法で同等の被害が出るのだからというものだった。（4月9日の日記「hiddenパラメタは漏れやすいのか？」）
それに比べると、Session Fixationの脆弱性を考えるときに、Webブラウザの責任と言えるかどうかは微妙なところにある。
ところで、Session Fixationが、Webアプリサーバ製品の脆弱性を指すものと、誤解している人が少なくないような気がする。Session Fixationという名前を付けたACROS Securityの論文「Session Fixation Vulnerability in Web-based Applications」*1では、「Session Adoption」という用語を定義している。
Session adoption
Some servers (e.g., JRun) accept any session ID in a URL and issue it back as a cookie to the browser. For example, requesting:
http://online.worldbank.dom/?jsessionid=1234
sets the session cookie JSESSIONID to 1234 and creates a new session with that ID on the server. We'll call such behavior "session adoption", due to the fact that the server effectively "adopts" a session ID that was generated by someone else.
PHPにはこの脆弱性があり、設定で回避できるのだが、PHPプログラマ界隈では、このことばかりが注目され、「Sesssion FixationといえばこのSession Adoptionのことを指す」という誤解があるように思われる。実際には、論文にあるように、攻撃者がサーバから取得した有効なセッションIDを使う方法が、Session Fixationとして一般的であり、それをユーザのブラウザにセットする別の方法が存在すれば、（Session Adoptionができなくても）Session Fixationの脆弱性があることになる。
cookieでセッション追跡されているWebアプリにおいては、その方法は、XSS脆弱性を突く方法と（これは上の論文に書いてある）、ブラウザの「Cookie Monster」バグを使う方法（これは上の論文には書かれていない）がある。このあたりの話については、2月のIPAでの講演スライドにも書いた。
で、ブラウザの「Cookie Monster」バグが現状でどのように考えられているか。
スライドを作成した時点では、Mozillaプロジェクトは直す気がないようだと書いた。1998年から知られている件であり脆弱性ではないとする主張、Session FixationはWebアプリ側で直せるからいいじゃないかという主張などがあった。それが、久しぶりに再び当該のBugzilla Bug「252342: fix cookie domain checks to not allow .co.uk」を見に行ったところ、進展していたことに気づいた。
ドメイン名の構造を表すファイルを作成して、それに従って Set-Cookie: での domain指定の範囲を決定するという方向性が選ばれたようで、Bugzilla Bug「331510: Add knowledge of subdomains to necko (create nsEffectiveTLDService)」でファイルフォーマット案が示され、パッチが作成されているようだ。ファイルの内容は「342314: Need effective-TLD file」で検討されているもよう。しかし、まだ完成には至っていないようで、Mozilla 1.8 にも組み込まれないようだ。
ちなみに、OperaがDNSを使ってやっているらしいという件は、Internet Draftが書かれていたことにいまごろ気づいた。しかし、このドラフトはexpireしている。
- I-D ACTION:draft-pettersen-dns-cookie-validate-00.txt
- I-D ACTION:draft-pettersen-subtld-structure-00.txt
そして Internet Explorerがどうなっているかというと、ドメイン名の第2レベルが2文字の場合は第3レベルで分けるというアドホックな対策を（昔から）とっているが、これは .jp においても地域ドメインなどで問題になるわけで、IEにはCookie Monsterバグがないというわけではない。
このような状況では、Session Fixation脆弱性の原因をWebブラウザ側に責任がある（Webアプリ側に責任なし）と位置付けるのには難があるというわけだが、はてさて、今後どうなっていくのだろうか。
*1 ちなみに、この論文は微妙に間違った内容も含まれているので注意。