<前の日記(2008年03月07日) 次の日記(2008年03月09日)> 最新 編集

高木浩光@自宅の日記

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

2008年03月08日

CAPTCHAのレベルはblog主が選択できるようblogサービスが提供してはどうか

先月末、江島健太郎氏の、

というブログエントリが話題になっていた。そのはてなブックマークを見ると、以下のように非難轟々だった。

  • temtan [セキュリティ][プログラム] この人プログラム初心者って自覚あるみたいだけど、だったらこれが有効かどうかも判らないはずじゃない。なんで自信満々に言うんだろう。googleのプログラマより頭良いと思ってるのかな。★
  • hatest [ダメな例] Javascriptおぼえたての人は、なんでもJavascriptで出来ると思っちゃう典型的な例。Spamに狙われるような人気サービスでもない限りhttp://www.geekpage.jp/blog/のようなCaptchaもどきでもOKだと思う。★
  • pmakino [CAPTCHA][これはひどい][セキュリティ] おもてなしという点でCAPTCHAが理想的な方法ではないのは確かだが代替案が酷すぎる。CAPTCHAですら破られているというのにそれよりひどく脆弱な方法ばかり書き並べてどうするのか ★★★★★
  • h_narazaki コノバクダンハスゴイナー。それで済んだらCAPTCHAとか最初から生まれてませんから。機械に簡単に分かるものは、機械に簡単に分かる。★★
  • fukken [これはひどい] 「コンピュータ処理が高コストで、人間が処理するのは低コストな問題」がCAPTCHAなんじゃないの?JavaScriptによる実装とかアボガド、BOTがJavaScriptを実行したら容易に読めちゃうじゃん、CAPTCHA破りの1000倍簡単だ ★★★★★★★★★★★★★★★

プププ。「この人プログラム初心者って自覚あるみたいだけど」と言われてしまうあたりも興味深い(笑)が、それはともかくとして、この記事がこのように非難されてしまったのは、書き方が悪いからだろう。

この記事はよく読むと2つの異なる話を扱っている。前半は、GoogleのCAPTCHAが破られたニュースを取り上げながら、GoogleのCAPTCHAが人に優しくないレベルのものになっていることを嘆き、とうとう検索時にまでCAPTHCAが現れるようになったことに苛立ってみせている。その一方、「では、他にどういう方法があるの?」から始まる後半は、マイナーサイトでのspam対策について考察している。これらは全然別の話だ。それを何の断りもなく繋げて書いたことが非難を招いた。

後半に書かれているのは、わりと誰でも考えたことのあるであろう、spam除けテクニックの数々だ。簡易なものから複雑なものへと順に説明されている。私なりに補足すれば、さらに簡易な方法として、単にPOSTのパラメタ名を変更するというものもある。

ここで重要なのは、spamは性質の異なる2つのタイプが存在することだ。1つは、サイト横断的に無差別爆撃するタイプのspam。もう1つは、特定のサイトやページに狙いを定めて集中的にピンポイント爆撃するタイプのspamだ。

サイト横断的な無差別spamでは、spam行為を自動化するために、何らかの共通するインターフェイスを利用するであろう。blogにおいて初期の頃、Movable Typeが狙われたように、Movable Typeのコメント送信フォームのHTML構造に合わせてspamプログラムが作られた。そのため、ワールドワイドにはマイナーな存在であったtDiaryはしばらくの間、コメントspamに悩まされずに済んでいた。しかし、後には、tDiaryもspamのターゲットとなる。このレベルの段階では、コメント用のPOSTパラメタの名前を変えるだけでspamy除けになっただろう。サイト横断的なspamは、何らかの共通のインターフェイスを使うからだ。

しかし、もちろん、「blogっぽいサイトのコメント欄っぽいHTMLフォームをWeb crawlingしながら見つけて、片っ端からspamコメントを突っ込んでボタンを押しまくる(のと同等のHTTPリクエストを送信する)」というspamボットも出てくるだろうから、それで解決しないことは目に見えている。それでも、そういう攻撃を受けるまでは、べつにそれでかまわない。サイト横断的なspamに対しては。

江島氏が書いている後半の途中までの内容はそういう話(パラメタ名を変える代わりに、別のもう1つのパラメタを必要とするようにするという方法の話)で、その後、さらにspamボット側の負荷を増大させる策などを挙げている。(JavaScriptを使う話はむしろオマケ。)

このようなやり方は、「spamするならうちより他へ行ったほうがいいよ」戦略であり、サイト横断的な無差別spamには通用する話であっても、何らかの原因で、ピンポイント爆撃の標的として狙いを定められてしまった場合には、通用しない。

Googleは言うまでもなく、世界の頂点に君臨する超メジャーサイトであり、あらゆる目的でspam行為の標的として狙いを定められている。だから、「うちより他へ」戦略は通用しないわけで、世界で最も高度なCAPTCHAを採用する以外にないわけだ。江島氏が言うような「調子に乗ってどんどん強度を上げ」ているわけではあるまい。

では、江島氏は何を言いたかったのか。おそらくこういうことだろう。「身の丈を知らないマイナーサイトがこぞってCAPTHCAを導入しているのはマヌケだ」と。私もそう思う。江島氏の運営するサイトもきっとマイナーサイトに違いない。

サイト横断的無差別spamの対策を語る文脈で、「マイナーなサイトなら簡単な画像認証を使えばいい」と言う人がいる。だが、たとえ簡単であろうと、正規利用者の手を煩わすわけだから、正規利用者が何も入力せずに済む方法をまず先に試してみようよと、それが江島氏の言いたいことだろう。(私もアイデアを出すなら、「ダミーを含む形でコメントフォームがたくさんあって、本物である1つを除いて(何らかの方法で)不可視にされている」という方法なんかはどうだろうか。)

一方、コメントspamの話ではなく、新規ユーザ登録機能に対する自動登録攻撃の話となると話が違う。Googleほどではないにしても、はてなくらいの人気度があると、自動ユーザ登録を目的にしたピンポイント攻撃の標的にされる。標的にされてしまったら、正規利用者にも何かを入力させるCAPTCHAを採用せざるを得ないだろう。新規登録は、最初に一回するだけなのだから、このくらいは我慢して使うべきだろう。

ところで、昨年10月に「はてなのCAPTCHAは簡単に破れる」という話があった。

もちろん、技術的にそうだという話をするのはいいのだが、これを見て、「これじゃ全然だめ」だの、「はてな、なんとかしろ」だのとぬかすバカが出てきて困る。まだ荒らされてもいないのに、わざわざイタチごっこの手を自ら先に進めることもあるまい。やられたら次の手に進められるよう準備しておけばいいだけの話だ。荒らし対策の話は、脆弱性対策の話とは異なる。荒らしはしょせん程度問題であるし、取り返しのつかない被害が即座に出るわけでもない。

その点、2006年8月10日の日記「飾りじゃないのよCAPTCHAは 〜前代未聞のCAPTCHAもどき」の件は話の前提が違う。これは荒らし対策ではなかった。今だから言えるが、これはある意味、脆弱性対策として導入されたものであろう。

このサイトは、長年、数字4桁の暗証番号でのログインを許してきた(ここ数年、そんなサイトは他に存在しない)。数字4桁の暗証番号は、ATMなどの公共の場にある物理機器では妥当であり得ても、インターネット経由の認証には許されないレベルの弱さである。このことは以前から各所で言われてきたし私も講演等で言ってきた。口座番号の方を変えながら繰り返し試されたら、ロックをかけることもできず、数千回程度の試行で突破できる口座が見つかってしまう。

CAPTCHAを導入すれば自動化された攻撃を防止できる。しかし、その目的の場合、そのCAPTCHAは絶対に破られることのないレベルの高度なものでなくてはならない。無差別spamtとは違い、このサイトが標的にされた状況を想定しているのであるし、取り返しのつかない被害の防止を目的としているからだ。それなのに、見ただけですぐ、どうすれば突破できるかわかるような仕掛けを採用していたのが問題であった。

そのサイトはその後、誕生日の入力を必要とするように対策された。これにより、突破される確率が数千分の一程度に抑えられたと言える。

そもそも、この目的では、CAPTCHAを採用するというアイデア自体が誤りであった。なぜなら、CAPTCHAに完全なものはあり得ないのであって、荒らし対策用のものだからだ。

ちなみに、Googleなどのように、パスワードを間違えたときにCAPTCHAが出るようになっているサイトもあるが、これもまた別の目的であるという点に注意が必要である。Googleなどでは、パスワードはユーザが自由に決められるのであるから、正しく設定すれば、上に書いたような方法で破られることはない。破られるのは、安易なパスワードを設定したユーザの責任である。それでもなおCAPTCHAによる対策を設けるというのは、そのようなユーザに対するサービスだと考えるべきものだろう(あるいは、弱いパスワードのアカウントが荒らし目的で不正使用されることを防止する目的のもの)。それに対して、4桁数字の暗証番号をユーザに強要しているサイトでは、サイト運営者に責任があるのであって、話が違う。

というわけで、CAPTCHAは荒らし対策用である。荒らし対策は、荒らされたら対応すればいい。荒らされてもいないのに、ユーザビリティを犠牲にしたCAPTCHAを導入するのはマヌケである。無差別spam対策なら、「他でやって」戦略をとる余地がまだある。標的にされているメジャーなところが、ユーザビリティを犠牲にするのは、他にどうしようもなく、しかたがない。

はてなの、新規ユーザ登録機能の防御は、現状ではおおむね必要十分なのだろう。ここで、はてなの新規ユーザ登録のCAPTCHAを突破して荒らす遊びを実行にうつすガキが出てきたら、そういうクソガキは村民でよってたかってdisるのがいい。業務妨害容疑で告発するのもよかろう。

一方、コメントspam対策はどうか。これは、blog主ごとに事情が異なるだろう。ホットエントリに上がったblogは、spamの標的に選ばれることがある。頻繁に注目を浴びるblogでは、ユーザビリティを犠牲にしてでもCAPTCHAを導入したいという事態になるかもしれない。一方、単なる無差別spamを防ぎたいだけのblogでは、江島氏が言うように、ユーザビリティを下げない簡易対策で当面十分だろう。

自分のドメインでblogを管理している者は自分のやりたいようにできるが、blogサービスを利用している場合はそうはいかない。そういった所で、spam対策のレベルを好きなように調整できないことが、江島氏のような不満を生んでいるのではないだろうか。

であれば、blogサービスの理想的な形は、「弱いが不便でない ←→ 強いが不便」の様々なレベルの仕掛けを用意して、各blog主が選択できるようにすることではないだろうか。

本日のTrackBacks(全3件) [TrackBack URL: http://takagi-hiromitsu.jp/diary/tb.rb/20080308]

はてながCAPTCHAの費用対効果で見落としていること

はてながCAPTCHAの費用対効果で見落としていること ってエントリが最近人気らしいけど、reCAPTCHAプロジェクトが出てきた時点で、もうスパム回避手段としてのCAPTCHAは終わっている。ちなみに、reCAPTCHAプロジェクトはサイボウズラボの秋元さんのブログで知った。 三井..

凪瀬 Blog:Gmail遮断の動き (2008年04月09日 12:50)

Gmail遮断の動き

検索

<前の日記(2008年03月07日) 次の日記(2008年03月09日)> 最新 編集

最近のタイトル

2024年11月11日

2024年07月28日

2024年07月27日

2024年07月07日

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|07|11|
<前の日記(2008年03月07日) 次の日記(2008年03月09日)> 最新 編集