<前の日記(2003年07月20日) 次の日記(2003年07月25日)> 最新 編集

高木浩光@自宅の日記

目次 はじめに 連絡先:blog@takagi-hiromitsu.jp
訪問者数 本日: 2186   昨日: 3759

2003年07月22日

続・最後の切り札を最初に使わせてどうする

一昨日の日記の続きだが、22日付けの「マネーメモ」によると、りそな銀行のtype blue(旧大和銀行)のシステムも、ログイン時に乱数表を使うのだそうだ。

他にも、東京三菱銀行もログイン時に乱数表を使うようだ。このことは、体験版の画面で、「OK」ボタンを押してみればわかる。

他にもあるか調べようと、一昨日紹介した、「ネットバンクで1600万円が突然消える」に行ってみると、なんだ、表に載っているではないか。表には「ログイン時のセキュリティ」の列があって、そこに「乱数表」と書かれたところが該当する。この中では、旧大和銀行と東京三菱銀行だけのようだ。

ここのシステムを作った人達は何を考えているのだろうか。常陽銀行の場合では、キーロガー事件を受けて急遽対策したんだろうから、まあ、ありがちなミスだなと思ったが、大和や東京三菱は、最初からこの設計でシステムを構築したんだろう。

ところで、これらの乱数表がキーロガーだけを想定した対策であるなら、「繰り返し使うとビンゴカードのように次々と盗まれていく」という心配は、実は杞憂なのだ。なぜなら、キーロガーだけでは、盗んだ入力番号が、どの枠のものであるかを知ることができないからだ。

しかし、キーロガーを仕掛けられるような環境では、他にどんな罠をしかけられているかわからない。例えば、キーロガーと同時に画面をキャプチャーするものを仕掛けられていれば、枠の位置と同時にコードを盗まれるだろう。他にも、ブラウザの表示内容と入力内容をキャプチャするプラグインを開発してブラウザに組み込んでおけば、両方とも盗めてしまうし、ブラウザのプロキシサーバの設定を変更して、SSL復号・再暗号化機能付きプロキシを仕掛け、偽サーバ用の偽ルート証明書をインストールしておけば、https:// の画面であろうが、通信内容をすべて記録できてしまう。消費者は、ネットカフェなどにある信用できないコンピュータを使うときは、これらの可能性を意識しておかねばならない。

やはり、最後の切り札を最初に使わせるような設計は避けるべきだろう。センスのない人間が設計し、運用しているとしか思えない。

乱数表が持ち腐れの銀行

これは個人の日記だ。個人の責任で余暇に書いている文章だ。個人が気軽に書いている日記なのだから、読者はあまり本気で信じてはいけない。組織の重厚な判断の下で慎重に書かれているのとは違うのだ。読者自らが再検証し、それが何を意味するか読者自身が考察するというのが、他人の日記を読むときの心得だろう。

一昨日の日記では、ぼかして書いたが、どうやら全然特殊な事例ではないようなので、はっきりと書くことにする。

まず、復習。日本銀行金融研究所の「インターネットを利用した金融サービスの安全性について」の p.219 には次のように書かれている。

しかし、もしも金融機関側のシステムが、攻撃者にとって都合のよい値が出るまで、「チャレンジの出し直し」をさせることができる作りであった場合、問題が発生する。こうした認証方式では、通常、暗証番号を試行錯誤的に入力する攻撃を回避するために、「チャレンジに対するレスポンスの入力エラーは3回以内」などといった制限を設け、制限値を超えると入力を規制するといった仕組みを採用することが多い。しかし、「チャレンジを表示させる回数」については、制限を設けていないシステムが存在するようである。そうしたシステムの場合、攻撃者は、不都合なチャレンジであればそれに応答しないで入力をキャンセルし、次のチャレンジを表示するよう依頼することにより、自分が正答できるチャレンジが表示されるまで、何度もチャレンジを表示させるという攻撃が可能となる。

松本勉, 岩下直行, インターネットを利用した金融サービスの安全性について, 金融研究第21巻別冊第1号, 2002年.

UFJ銀行の「これまでの改善内容」にはこんなことが書かれている。

今後、ログインパスワードを忘れたり、連続して間違えて入力し、インターネットバンキングが利用できなくなっている(ロックされている)場合は、 オンラインサインアップ(利用開始登録)画面より、再度オンラインサインアップ(利用開始登録)をすることによりインターネットバンキングがすぐにご利用いただけます

UFJ銀行 ログインパスワードロック(6〜12桁)解除手続の変更について

なるほど便利な改善だ。

UFJダイレクトの「オンラインサインアップ」の画面の一番下にある「同意する」ボタンを押してみる。次の画面で、

ご契約カードの乱数表で、 8行目の6列目 の数字から右へ4桁(確認番号)を入力してください

といった表示が出る。ページを戻って、もう一度「同意する」ボタンを押してみると、今度は、

ご契約カードの乱数表で、 10行目の4列目 の数字から右へ4桁(確認番号)を入力してください

と、先ほどとは異なる場所が指定される。これは、何回でも繰り返せるようだ。

つまり、一回でも盗聴(キーロギングや画面キャプチャやプロキシ盗聴を含む)されて、X行Y列から右へ4桁の数字を盗られてしまったら、犯人は、上の画面でX行Y列が出るまでボタンを押し続けるだろう。乱数表には10行10列の100個の数字が書かれているようだが、「右へ4桁」という指示を出すからには、列番号は1〜7の範囲だろうから、70通りしかない。

りそなダイレクトの「type blue」と書かれた部分をクリックしてみる。

りそなダイレクトお客様ご利用カードを参照して、ひらがなの表示に該当する数字を入力してください。

の数字
の数字

などと指示される。ウィンドウを閉じて、もう一回クリックしてみると、今度は、

りそなダイレクトお客様ご利用カードを参照して、ひらがなの表示に該当する数字を入力してください。

の数字
の数字

と出る。欲しいものが出るまでいくらでも繰り返せる。この説明によると、「あ」〜「と」までの20個の枠で構成されているようなので、380通りしかないようだ。

こういう画面設計をしては駄目だ。ユーザ名の入力と同じ画面で乱数表の値を入力させる設計は駄目だ。ユーザ名を入れた次の画面で、乱数表を使わせるようにすればよい。そうすれば、ユーザが特定されているので、そのユーザ向けに前回に提示したのと同じ場所を指示するように作ることができ、そうすればこの問題は回避できるだろう。

「そんなことを日記に書くな」などと言われるかもしれないが、先に復習したように、この話は、2002年2月28日に日本銀行で開催された第4回情報セキュリティ・シンポジウムでとっくに指摘済みの話だ。もう1年半も経っている。たくさんの金融システム構築関係者が聴講していただろうし、全国銀行協会の人も聴いていただろう。何をやっているんだ。

やんわりとそれとなく指摘していたのでは永遠に修正されることはないのだろう。マスコミが扱うまで修正することはないのだろう。スラッシュドットでコケにされるまで直すことはないのだろう。

奥ゆかしきエラーコード

システムを開発する際、ユーザ名とパスワードを受け付けた画面で、「ユーザ名が間違っています」とか、「パスワードが間違っています」という表示をしてはならない、つまり、「ユーザ名またはパスワードが間違っています」と表示すべきだという話は、基礎中の基礎だ。

常陽銀行のログイン画面というか、NTTデータのANSERシステムで、「利用者ID」と「パスワード」を入力するとき、どちらか一方を間違えると、どんなメッセージが表示されるか。

ユーザ名が間違っているときは、

入力項目が誤っています。
再度入力して下さい。

理由コードはB33です。

と表示される。そして、ユーザ名が正しく、パスワードが間違っているときは、

入力項目が誤っています。
再度入力して下さい。

理由コードはBXXです。

と表示される。一応、「XX」の部分は伏字にしておいた。「B33」とは異なる文字列が表示される。

これは、「ネットアクセス(インターネットバンキング)に関するお問い合わせ先」に、

なお、パスワード等が入力エラーになってしまう場合など、「エラー理由コード(例:B03)」が画面上に表示されることがありますので、お申し出いただきますとより迅速にご対応できると思われます。ご協力のほどお願い申し上げます。

と書かれているように、エラーの原因を特定するためのものだろう。

ならば、ずばり「ユーザ名が違います」、「パスワードが違います」と表示すればいいものを、「理由コードはB33」などと奥ゆかしく表示するのはなぜなのか? ずばり表示するのがセキュリティ上問題があると知っているからじゃないのか? だが、それで理由がバレないと思っているのなら、かなり知能が低いと言わざるを得ない。

署名欄付き乱数表カード

常陽銀行から送られてきた「ご契約者カード」の裏面には、署名欄がある。どうして署名なんかしなくちゃいけないのか。名前なんか書いたら、落としたときに危ないだけだろ。

これを作った人は、「カードってものは裏に署名欄を付けるものだ」とかいうレベルの認識なのだろうか。

ドイツのネットバンキング事情

ドイツ在住のOliverさんから、ドイツにおけるネットバンキングの様子をメールで頂いた。

それによると、ドイツのネットバンキングのほとんどでは、「TAN」(トランザクション番号)という、使い捨てのワンタイムパスワードが使われているそうだ。TANは、B6サイズほどの紙に100個の5〜7桁の番号が書かれたもので、それぞれ1回しか使えないそうだ。どの順番で使ってもよく、残りが少なくなると自動的に新しい紙が郵送されてきて、新しい方の番号を使うと、古い紙の残りは無効になるそうだ。

彼が使っている銀行では、ログイン用の固定暗証番号を3回間違えると、アカウントはロックされ、有効なTANを3個入力すると、ロックは解除され、もし、TANを3回間違えると、アカウントは完全にロックアウトされ、身分証明書をもって支店にいかないと解除できないそうだ。

きっと、TANの紙には、口座番号も契約者番号も氏名も書かれていないのだろう。拾っても誰のものかわからないように。

また、一部の銀行では、時刻で変化する10桁の番号を表示する電卓サイズのカードをユーザに配布しているところもあるそうだ。

この話を聞いて不思議に思ったのは、日本ではどうしてこう、まやかしの安全システムがまかり通って、ドイツではこうも確かな方法が選択されるのだろうか? ということだ。どういう文化的相違からくるものなのだろうか。

検索

<前の日記(2003年07月20日) 次の日記(2003年07月25日)> 最新 編集

最近のタイトル

2024年04月07日

2024年04月01日

2024年03月23日

2024年03月19日

2024年03月16日

2024年03月13日

2024年03月11日

2023年03月27日

2022年12月30日

2022年12月25日

2022年06月09日

2022年04月01日

2022年01月19日

2021年12月26日

2021年10月06日

2021年08月23日

2021年07月12日

2020年09月14日

2020年08月01日

2019年10月05日

2019年08月03日

2019年07月08日

2019年06月25日

2019年06月09日

2019年05月19日

2019年05月12日

2019年03月19日

2019年03月16日

2019年03月09日

2019年03月07日

2019年02月19日

2019年02月11日

2018年12月26日

2018年10月31日

2018年06月17日

2018年06月10日

2018年05月19日

2018年05月04日

2018年03月07日

2017年12月29日

2017年10月29日

2017年10月22日

2017年07月22日

2017年06月04日

2017年05月13日

2017年05月05日

2017年04月08日

2017年03月10日

2017年03月05日

2017年02月18日

2017年01月08日

2017年01月04日

2016年12月30日

2016年12月04日

2016年11月29日

2016年11月23日

2016年11月05日

2016年10月25日

2016年10月10日

2016年08月23日

2016年07月23日

2016年07月16日

2016年07月02日

2016年06月12日

2016年06月03日

2016年04月23日

2016年04月06日

2016年03月27日

2016年03月14日

2016年03月06日

2016年02月24日

2016年02月20日

2016年02月11日

2016年02月05日

2016年01月31日

2015年12月12日

2015年12月06日

2015年11月23日

2015年11月21日

2015年11月07日

2015年10月20日

2015年07月02日

2015年06月14日

2015年03月15日

2015年03月10日

2015年03月08日

2015年01月05日

2014年12月27日

2014年11月12日

2014年09月07日

2014年07月18日

2014年04月23日

2014年04月22日

2000|01|
2003|05|06|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|05|06|07|08|09|10|11|12|
2012|02|03|04|05|06|07|08|09|
2013|01|02|03|04|05|06|07|
2014|01|04|07|09|11|12|
2015|01|03|06|07|10|11|12|
2016|01|02|03|04|06|07|08|10|11|12|
2017|01|02|03|04|05|06|07|10|12|
2018|03|05|06|10|12|
2019|02|03|05|06|07|08|10|
2020|08|09|
2021|07|08|10|12|
2022|01|04|06|12|
2023|03|
2024|03|04|
<前の日記(2003年07月20日) 次の日記(2003年07月25日)> 最新 編集