ワンタイムパスワードは何のためにあるのか先月、ジャパンネット銀行から「SecurID」が送られてきた。RSAセキュリティのワンタイムパスワード生成器(以下「トークン」)だ。ジャパンネット銀行は全口座の利用者に対してこれを配布している。届いた郵便物には図1の案内状が入っていた。ジャパンネット銀行から送られてきたSecurIDに同梱の案内状ここに書かれていることは事実でないので、信じてはいけない。トークンはスパイウェアに監視されないので安全です。トークンはパソコン、携帯電話などと一切の通信を行いません。万が一パソコンや携帯電話がスパイウェア(不正プログラム)に感染しても、トークンに表示されたワンタイムパスワードが監視されることがなく安心です。ファイルを安心して実行できる」と思ってしまうかもしれないが、トロイの木馬(不正プログラム)を実行してしまっては、たとえこのワンタイムパスワード生成器を使っていようとも、不正送金されるという事態は起こり得るのであり、「パスワードが監視されることがなく安心です」という宣伝文句を信じてはいけない。スパイウェア(不正プログラム)はキーロガーだけではない。不正プログラムがユーザのコンピュータに入り込む余地があるということは、任意のプログラムが入り込み得るわけだから、ユーザがログインしたのを見はからってログインセッションを乗っ取ることができてしまう。した攻撃が英語圏では既に発生しているらしいという話は、2月22日の日記にも書いたとおりだ。2006年2月20日ジャパンネット銀行のWebサイトでの説明ページでは、少し違う言い回しがされている。トークンはスパイウェアに感染しませんトークンはお取引にご利用されるパソコン、携帯電話などと接続して使用するものではなく、また、一切の通信を行いませんので、万が一パソコンや携帯電話がスパイウェアなどの不正プログラムに感染し、パソコンや携帯電話内の情報がすべて監視されていた場合でも、トークンに表示されているワンタイムパスワードを監視されることはありません。ジャパンネット銀行トークン自体がスパイウェアに感染しないのは事実だろうし、トークンに表示されているものが監視されるわけではないのは事実だろうけども、パスワードを送信しようとして、ユーザがトークンから目でコピーしてブラウザに入力しているそのワンタイムパスワードは、不正プログラムならば監視できてしまう。ワンタイムパスワードは再利用できませんワンタイムパスワードは、60秒ごとに使い捨てパスワードが自動発行され、一度使用したワンタイムパスワードは無効となりますので、万が一フィッシングなどでワンタイムパスワードが盗まれた場合でも、それを再利用し、不正に取引されることはありません。たしかに、再利用はできないのだから、「再利用によって不正取引される」ことがないのは事実だが、一回目の利用としてその瞬間(30秒以内)に不正取引される可能性があるのだから、「万が一フィッシングなどで......ありません」などと、フィッシングされても大丈夫であるかのような誤解を与える表現は危険だ。昨年10月17日の日記「銀行やマスコミは対策の有効性の範囲で嘘を書いてはいけない」でも書いたように、誇大な安全宣伝は無責任であり、自分の首を絞めることになる。これらはたぶん、わざと誇大に書いているのではなく、危険性に気づかなかったか、単に業者の宣伝文句を真に受けただけか、あるいは業者自身が無知で誤った宣伝をしているのだろう。セキュリティベンダーは(さらには学術研究の場でさえしばしば)、ワンタイムパスワードがフィッシング対策や、スパイウェア対策になるという誤解をしているようで、困ったことだ。SA」という製品の説明にも次のようなことが書かれている。SA」の販売を本日から開始します。インターネット環境においてフィッシング詐欺やキーロガーにより不正に入手されたログイン情報を使った「なりすまし」を防ぐために、従来の単純なパスワードによる知識認証方式に替わり、より強固な認証機能が求められています。ワンタイムパスワード認証などがありますが、いずれにおいても専用の装置が必要となり普及は難しい状況にありました。2005年11月7日なぜこのような誤解が生じているのか考えてみた。SecurIDは、消費者に使われるようになったのはごく最近のことだが、企業や団体では、従業員が社内システムに社外からアクセスする際に使用するなどの目的で、20世紀末から普及していた。この実績から、「SecurIDは安全性が高い」「コストが高いので普及しないだけ」という理解が広く浸透していたのだと考えられる。コストが高い(配布の手間も含めて)ために、不特定多数の消費者向けの用途としては普及しなかったわけだが、そうも言っていられないほどの状況がここ数年で出てきたため、三井住友銀行をはじめ、ジャパンネット銀行もSecurIDを採用したのだろう。ここ数年で被害の原因として目立っているのは何かというと、フィッシングとスパイウェアである。「SecureIDでフィッシングとスパイウェアから守れる」という短絡思考が生じているのではないか。たしかに、ビンゴカードのような乱数表を使うくらいなら、ワンタイムパスワード生成器にした方が安全性が格段に違うというのは、その通りであり、三井住友銀行がSecurIDを採用したときは、セキュリティを理解しているはずの技術者達も絶賛したようだった。2006年1月13日フィッシングやスパイウェアによる被害を防げるわけではない。ワンタイムパスワードが安全であると言われた時代は、フィッシングなどという手法でユーザがこうも騙されて偽サイトに入れてしまうとは、想定していなかったのだろう。スパイウェアも然りで、それを想定するともはやどうにもならないので、想定しない前提で安全であると言われてきただけだ。フィッシングもスパイウェアも想定外との前提を置いた場合に、ワンタイムパスワードの効用は何なんだということになるが、たとえば、「盗聴されても再利用できないので安全」という主張を検討してみると、盗聴されればセッションハイジャックされてしまうので、安全ではない。「後ろからパスワードを覗かれても再利用されない」というのは概ね正しいだろう。他にはないのか......。考えてみるに、ワンタイムパスワードの効用とは、パスワードの安全レベルの管理が、ユーザではなく、アクセス管理者にコントロールされているところが肝ではなかろうか。普通のパスワードだと、パスワードの安全レベルが、ユーザの力量に依存してしまう。パスワードの変更を許せば、安易なパスワードを付けるユーザが出てくるし、変更を許さず複雑なものを与えると、パスワードをメモしてモニタに貼り付けるユーザが出てくる。ここで、ワンタイムパスワード生成器を配布すれば、安易な内容のパスワードになってしまうことは避けられるし、メモさせず、物として管理もさせやすい。一般のWebサイトなどでは、ユーザのパスワードの安全レベルは、ユーザの自己責任で決められている。パスワードが弱くて被害が出てもユーザの責任と主張することができるだろう。それに対し、企業が社内システムへのリモートアクセス用にアクセス制御機能をインターネットに開くときは、一人でも弱いパスワードを付けるユーザがいるだけで、社内システムが危険に晒されるわけだから、ユーザの責任でというわけにいかない。これが、SecurIDが企業等に先に普及していった本当の理由ではないか。いうことになるが、そうではない。今年の2月から預金者保護法が施行された。預金者保護法は、偽造カードと盗難カードによる被害を対象としており、インターネットバンキングでの被害は対象としていないが、考え方としては共通しており、将来、インターネットバンキングにも対象が広げられるかもしれない。この法律により、一定の基準のケースにおいて、銀行側が被害を補償しなくてはならないようになった。「パスワードが弱いのはユーザの責任」とは言っていられない状況が強まった。今こそ銀行がワンタイムパスワードを導入するというのは正しい。その理由が間違って宣伝されている。ExplorerのCSSXSS脆弱性に配慮するべきだという主張が出た際に私は、それはWebブラウザの脆弱性でありWebアプリ側の責任ではないとした。その理由は、hiddenが漏れるならどのみち別の方法で同等の被害が出るのだからというものだった。Fixationの脆弱性を考えるときに、Webブラウザの責任と言えるかどうかは微妙なところにある。Fixationが、Webアプリサーバ製品の脆弱性を指すものと、誤解している人が少なくないような気がする。Adoption」という用語を定義している。Adoptionのことを指す」という誤解があるように思われる。Fixationの脆弱性があることになる。Monster」バグを使う方法(これは上の論文には書かれていない)がある。このあたりの話については、2月のIPAでの講演スライドにも書いた。Monster」バグが現状でどのように考えられているか。スライドを作成した時点では、Mozillaプロジェクトは直す気がないようだと書いた。FixationはWebアプリ側で直せるからいいじゃないかという主張などがあった。.co.uk」を見に行ったところ、進展していたことに気づいた。nsEffectiveTLDService)」でファイルフォーマット案が示され、パッチが作成されているようだ。file」で検討されているもよう。組み込まれないようだ。Draftが書かれていたことにいまごろ気づいた。このドラフトはexpireしている。Monsterバグがないというわけではない。Fixation脆弱性の原因をWebブラウザ側に責任がある(Webアプリ側に責任なし)と位置付けるのには難があるというわけだが、はてさて、今後どうなっていくのだろうか。ちなみに、この論文は微妙に間違った内容も含まれているので注意。