本編の前に、ご案内：
もっと短くてわかりやすい話をたのむ、という人は、 俺は悪くないYahooが悪いんだ返金しろ、とか言う人はこれを読んで胸に手を当ててよく考えてね をどうぞ。

今日は、パスワードを第三者に知られて結果的に金銭被害につながったお気の毒な方々のお話。

ヤフオク「ID乗っ取り」報道に反論、情報流出の事実はない (Internet Watch 2008/9)

「Yahoo!オークション」のIDとパスワードが盗まれ、偽ブランド品などの不正出品に悪用されているとした一部報道で、「Yahoo! JAPAN」からの情報流出を懸念する内容が報じられた件について、ヤフーは6日、「情報流出があるという事実はございません」と否定するコメントを発表した。

つれづれJUNK

乗っ取りに関してのyahooの回答は、読売新聞に対して”フィッシングの可能性も否定できない”と言っている。
朝日新聞には、”中国からＩＤやパスワードを当てずっぽうに打ち込まれ、解読されたとみられる手口が目立つ”と回答している。　(9/9　追記)　

朝日新聞のコメントに対して・・・・被害者は全員一発でミスなく乗っ取りされています。　参照1　参照2

そんなことがソフトで可能ですか？yahooさん、一発でミスなく他人のパスワードを解析できると証明してください。そんなことがもしできるならパスワードそのものの存在意義を否定してるってことですね！

山梨県／1496円 - ID乗っ取り被害回復ネットワーク

私は8月29日にyahooＩＤの乗っ取り被害に遭い、偽ブランド時計を多数出品されました。 ***には***会員料金、手数料の請求をされています。 オークションは入札、落札しかした事がなく、出品した事は一度もありません。

ＩＤとパスには関連性がなく簡単に推測されるようなパスではありません。長く複雑なパスです。ウイルス対策も行っています。 自宅のパソコンでしかログインしていませんし、ログアウトも常に行っていました。 ＩＤ、パス共に他人には知らせていません。管理には気をつけていたつもりでした。 第三者にパスワードが知られる原因に心当たりがありませんので、なぜこのような事になったのか不可解です。
ログイン履歴を見ますと、やはり不正アクセス、見知らぬIPのアクセスがあるのですが、一度でログインに成功しています。 パスを何度も試し何度目かでログイン出来るような場合は、ログイン履歴に失敗と表示されるはずなので これは、最初からパスを知っていたか、パスを知らなくてもログイン出来る仕組みがあるのか？と推測できるのではないでしょうか？
また、***側から漏れた可能性もあるのでないか、と思うのですが。

筆者注：文章の冒頭で「YahooIDの乗っ取りの被害」と書いているのに、なんでYahooのことを*** とつぶしているんだろう？笑

悪魔の証明

冒頭にあげたこちらの方ですが、なんというんでしょうか、もう少し冷静になったほうがよろしいかと。 「パスワードが漏れたに決まってるんだ！違うというなら証明しろ！」とでも言いたいのでしょうか。そうは直接は思ってないのでしょうが、でも結果的にはそれに近い。 それって悪魔証明ってやつでは？ 　例：「月の裏側には、ウサギが存在する。なぜなら月の裏側にウサギはいないという証拠がないからだ。」

やたらと悪魔証明を振りかざすユーザーを相手にしなかったり冷たくあしらうのも正しい企業姿勢のうちのひとつだよ。

「そもそもわたしが使っていたパスワードはそんな安易な文字列ではない！」

うん。そうでしょう。でもね、一般論として、多くの人は、いまどきYahoo提供のWebサイト／サービスだけを使っているということでもないだろう。そしてYahoo以外のサイトでは、たとえば

• ナチュラムという釣り道具屋のサイトでユーザーのIDとパスワードの平文が65万人分漏れてた件とか、
• サウンドハウスという楽器屋のサイトでやはり9万件ほどパスワードが平文で漏れてた件とか。

  「被害を隠すな」サウンドハウス社長が不正アクセス体験語る (2008/6)

  サウンドハウスによれば、攻撃者は、カード決済で使う本人認証システム「3Dセキュア」を導入しているゲームサイトにおいて、クレジットカード番号と、サウンドハウスのサイトのパスワードをマッチングさせて本人認証を通過。その後、金券や商品を購入してRMT（Real Money Trade）などのサイトで転売するなど、足が付かないかたちで換金していた。中島氏は「ここから先は推測」と前置きした上で、「金銭的被害者の大半は、サウンドハウスのパスワードとその他のパスワードを同一にしていた人」としている。

• 絵本ナビという絵本を売っている小さなサイトでは2万7千件。

  EhonNavi BLOG: 「不正アクセス発生に関する調査報告と情報漏えいのお詫び」に関するFAQ (2008/8)

  【Q15】
  漏えいしたデータでお客様にはどのような被害が想定されるのか？
  
  【A15】
  漏えいしたものはユーザーID（e-mailアドレス）とパスワードのみですので、「同じ組み合わせで他のサイトに登録されていれば、成りすまして利用される可能性」等が考えられます。
  
  筆者注：↑こう言っているということはパスワードは平文でありハッシュ化保存（後述）なんてやってなかったということだ。

• 1年も前に運用を停止したはずのペットショップのサイトがサーバーの電源は入れっぱなしだったがために18000件のIDとパスワードが流出。

  お客様の個人情報流出に関するお詫びとご報告(2008/9) （PDF形式。コピーここ）

  弊社が2004年１月から2007年5月まで運用しておりました、インターネットショッピングサイト『ドッグワンライフ』(URL:http://www.hot-star-dog.com/) において、6月21日に中国から不正アクセスがあり
  （中略）
  ※2007年6月以降もサーバーが稼動状態であった為、商品の販売終了後2007年6月以降にも、上記サイトに会員登録を頂きましたお客様も対象となります。
  
  個人情報項目は以下の内容となります。
  1.ログイン用ユーザーID
  2.ログイン用パスワード
  3.氏名 4.Eメールアドレス
  
  筆者注：パスワードが平文であったかどうかは文章からはわからないが、このお粗末さ加減からして平文であったと考えるのが妥当だろう。

• 化粧品会社のサイトがSQLインジェクション攻撃くらって2万件流出。

  オズ・インターナショナル、不正アクセスでカード情報大量流出の恐れ (Internet watch 2008/5)

  オズ・インターナショナルでは19日、クレジットカード情報が流出した可能性のある約2万人にメールで通知。今回の情報漏洩によってクレジットカードの不正使用が発生した場合は、すべて補償することなどを伝えた。

  不正アクセスに関するお詫びとお知らせ （オズインターナショナル 2008/5)

  5. サイト、携帯、その他で「同一パスワードを使用している人」は2重、3重のパスワード管理が無意味になりますので、出来るだけ早く全て違うパスワードに変更することをお勧め致します。
  
  筆者注：↑こう言っているということはやはりパスワードは平文のままだったということ。

• オンラインゲームサイトからの流出。「流出したIDによるデータ改ざんが確認されている」＝流出したパスワードは平文だったことはほぼ明白。

  オンラインゲームポータルに不正アクセス、個人情報14,362件流出 (Internet Watch 2008/1)

  流出した個人情報は14,362件（1月27日時点）で、アカウントID、パスワード、メールアドレス、年齢が含まれる。流出したIDを使用してゲームにハッキングし、アバターのデータを改竄するといった悪用も確認されており（以下略）

• 「いろんなWebサイト使ってるけど、パスワードはそれぞれ違うようにしてるよ。」
• 「Yahoo以外にもgmailとか楽天とか他にもいろいろなWebサイトでユーザー登録しているけど、パスワードは実は全部同じなんだよね。」

あなたは上のどっちに該当しますか？

なお、くれぐれも誤解しないでほしい。今回はYahooの認証用データベースサーバまたはそれに類するものがクラックされた確証はまったくどこにもない。 言いたいのは、違うWebサイト／サービスであってもパスワード（やID）は同じにしている人が多いという実態を逆手に取ったコンピュータ犯罪なんてどこででもありうるよ、ということだ。

ここまで言えば、ここ最近のYahooオークションで何が起きた（と推定しうる）のか、わかるよね。

それから、こうしてみるとみんなクレジットカード被害ばっかり気にしてる。 パスワードが流出したことによる二次被害に言及しているところやマスコミは意外と少ない不思議。 そしてなによりも、上に引用した情報流出元すべてでパスワードが平文で保存されていたこと自体を指弾する業界関係者や業界マスコミがほどんどいないということに、もう驚愕っていうか、絶望。

別なところでは、こんなことを言っている人もいる。↓

不可逆的な暗号化によるパスワードの管理ってなんのこと？

IDとパスワードが同じユーザーが被害に遭うケースも見られたってあるけど、どうしてIDとパスワードが同じだってわかったんだろう。被害にあった人に「IDとパスワードが同じでしたか?」とかいちいち聞いてるのかね? パスワードは不可逆的に暗号化してあるんだもんね。
Manu-'s diary(2008-09-10)

ここで、「わかりやすいパスワードを使用されている方々へのパスワード変更の案内」と、角カッコが付いているので気になる。すべてのユーザに変更の案内や注意を出すんならわかるんだけど。どうやって"わかりやすいパスワードを使用"しているユーザがわかるんだろうか。"パスワードは不可逆的に暗号化"してあるんでは? とか思ってしまうのだが、自分の理解または認識誤りであろうか。
Manu-'s diary(2008-09-10)

はい。認識誤ってますよ。

ここでいう「不可逆的な暗号化」っていうのは、専門数学用語でいうと「一方向性関数」の部類に入る（らしい）。業界ではハッシュ関数とかハッシュ値とか言う。 とにかく、ハッシュ関数の一種であるmd5（イマドキMD5もないだろSHAにしろとか、SALTもちゃんと使えといった話はさておき）を使うと、 「abcd123」という文字列は「79cfeb94595de33b3326c06ab1c7dbda」になる。

「abcd123」から「79cfeb94595de33b3326c06ab1c7dbda」を算出するのは簡単だが、 「79cfeb94595de33b3326c06ab1c7dbda」しかわからない状態で「abcd123」を割り出すのはものすごく難しい。だから一方向性と呼ばれる。

ユーザーデータベースの「パスワード」の欄には「79cfeb94595de33b3326c06ab1c7dbda」という値が入っているだけで、「abcd123」という文字は影も形も無い。これによって管理者でも本当のパスワードはわからないというセキュリティ上望ましい状態が実現する。 （そういう管理をしていないサイトも多いという話はこのまえした。）

パスワードで認証する処理においては、ユーザーが入力した値＝abcd123＝をそのハッシュ関数に通して 「79cfeb94595de33b3326c06ab1c7dbda」という値を得て、それがデータベース上に保存されているものと一致するかどうかで判断しているわけだ。

以上をふまえれば、

1. どうやって"わかりやすいパスワードを使用"しているユーザがわかるんだろうか。
2. IDとパスワードが同じユーザーが被害に遭うケースも見られたってあるけど、どうしてIDとパスワードが同じだってわかったんだろう。

という問題は簡単だ。問１は、わかりやすいパスワード＝12345とかabcdefgとか＝を、そのサイトで使っている一定のハッシュ関数にとおして、その結果値でユーザーデータベース上を検索すれば、パスワードが12345、abcdefgであるユーザーをあぶりだせる。あとは「わかりやすいパスワード」のバリエーションの問題でしかない。

実際にそういうソフトも（アングラなものではなく）存在するし、ユーザーに注意をうながす目的で実用されている。例えば大学なんかだと学生のアカウントのパスワードを定期的に走査して、安易なパスワードを見つけると自動的に警告するような仕組みは全くめずらしくない。やはり学生さんは安易なところあるしね。教育上必要なことだと思う。

余談だが、当時、筆者の友人が熱帯魚を飼うのが趣味で、自分のアカウントのパスワードを「cichlid」にしておいたら、バッチリひっかかって呼び出しをくらっていた。（笑） 辞書に載っているような単語ももちろん「わかりやすいパスワード」としての走査対象なのである。

問２は問1と同じ。「わかりやすいパスワード」のバリエーションに「ID文字列そのもの」を含めるだけのことだ。

そう、難しくない。だからこそ筆者はためしたことがある。

安易なパスワードを設定している人は100人に1人はいる。

数万人程度のユーザーを抱えるとあるサイト。好きなIDとパスワードを設定できる、よくあるサイトだ。もちろんパスワードはハッシュ値だけを保存している、当時としてはセキュリティの考え方がしっかりしたサイトだった（と思う）。そのサイトではIDとパスワードを同じにすることもできないようになっていた。

そこを使って、実験してみた。例えば「yamada」というユーザーがいたら、 「yamada89」「0xyamada」といったふうに、 自分のIDの前後に、0-9a-zA-Z!$()/.,（その他記号含め）のうちの任意の1文字または2文字を追加しただけのパスワードを設定しているユーザーはどれくらいいるのだろう？という実験である。いちいち画面からformに入力するのではなく直接データベースをさわれる環境だったので、作業は簡単だった。

結果：全ユーザーのうちの0.51%がヒット。

つまり1000人いたら5人は、そういう安易なパスワードを使っているアホが確実にいるということだ。 これに、さっきの「cichlid」みたいな辞書にのっている単語を使っているケースも加えれば1%近くになるだろう。 自動化された総当り攻撃をする側にとっては十分なヒット率である。 こういう人がいつなんどき第三者による乗っ取り被害を受けたとしても同情する気はまったくしない。

なお、どこのサイトの話かなんて口が避けても言うつもりはないし、 そのサイトの責任者の許可のもとに（というか要請を受けて）やった実験だし、 少なくとももう何年も前の話である、ということだけはお断りしておく。

結論

1. 中途半端な情報リテラシーで妙な信憑性をかもしだすだけのうわさ話を流すのはやめましょう。 引っ込みつかなくならない程度にしておかないと、ただのクレーマーと大差なくなる。
2. そんなことやってる暇があったらとにかくまともなパスワードを設定しましょう。 まともなパスワードであっても、複数個所で同じパスワードを1年以上にわたって使ってる場合はとっとと変更しましょう（←ココ！ぎくっとなった人多いはずだ！笑）
3. そもそも、同じパスワードを複数のサービスで使いまわす（心あたりある人多いでしょ）という行為自体が、 「パスワードを第三者に教えてはいけません」という常識的ルールに反していることに気がついていますか？ そんなこといったって、、、といっても、こういう事態に至っては「そんなこと」ではないでしょう。ええ。
4. ゴシップ週刊誌はもちろんのこと、朝日だろうと読売だろうと新聞に書いてあることなんて大してあてにはならない。紙面では文字数の制約があることもそうだし、 こと話が技術がらみになると話が違ったりトンチンカンだったりするのは今の新聞屋にはじまったことではないから。→パラボラアンテナがあれば自由にインターネットに接続できる？ (2007/9)
5. Webサイト上でサービスを提供する側も、 「ユーザーのパスワードはウチの管理者でもわからないようになっているんです！」と 胸を張っていえるようにしておくべきです。（この点はYahooはもともとそうなっているようだ）
   • パスワードの危機(その１) − きっかけ (2004/2)
   • パスワードの危機(その２) − あるべき姿 (2004/2)
   • パスワードの危機(その３) − 楽天の場合 (2004/2)
   • パスワードの危機(その４) − SSL催眠術 (2004/2)
   • パスワードの危機(その５) − アマゾンの場合 (2004/3)
6. 自分が被害をこうむったサービスの提供元それ自体での事故／故意／犯罪行為によってパスワードを流出させてるに決まってるんだ！という決めつけは身勝手であり、真面目にやっているWebサイトとその中の人に対してとても失礼であり、迷惑である。

see also:

• メールアドレスが漏洩してると決めつける迷惑な人々 (2006/7)
• パスワードはサイバースペースの「実印」 セキュリティー-西本逸郎のセキュリティー表ウラ (日経IT-PLUS 2008/2)
• 第2回　現状編：あなたは大丈夫？パスワードの危険な実態：ITpro (2008/3)
• 結局、予想通りの展開（ヤフオクID乗っ取りの件） (2008/9)

以下、 ギークなお姉さんは好きですか ＜title＞をクールにしてみた！ より。

extract($_GET);

mysql_connect('localhost','ユーザ名','パスワード');
mysql_select_db('データベース名');
mysql_query("set names utf8");

$sql="select * from geekDB where name_id = "$name_id"";
$result = mysql_query($sql);

while ($item = mysql_fetch_array($result)) {
 echo "<title>";
 echo $item["name"];
 echo "</title>";
}

すでに誰かが突っ込んでいるが、extract($_GET); はまずい。 でもなぜまずいのかどこにもマニュアルにも書いてないのがなんともねえ。

// このコードがfoo.php だとする。
$himitu = "ok!"
extract($_GET);
echo $himitu;

http://example.jp/foo.php?id=hoge へのアクセスの結果↓

ok!

baka

mysql_query("set names utf8"); もまずい。→ SET NAMESは禁止。 mysql_set_charset っていうのがあるんだからそっち使おう。つまり
mysql_set_charset("utf8");
ただしこの関数はPHP5.2.3以上じゃないと使えないというのがネックだ。

次。

$sql="select * from geekDB where name_id = "$name_id"";

そもそもこれだとダブルコーテーションの配置がおかしいからsyntax errorなはずなんだけど、コピペミスだろうか。 それはともかく、「SQL文の組み立てで$_GET["name_id"]って書くのは面倒だからextractして$name_idでアクセスできるようにしてしまえ」と思ったのかもしれない。でもそこは我慢しよう。
$sql = "select * from geekDB where name_id = '" . $_GET["name_id"] ."'" ;
あるいは
$sql = "select * from geekDB where name_id = '${_GET["name_id"]}'" ;
ところで、${hogehoge}って書くことでどこまでが変数名なのかを明示できることを知らない人は意外と多いみたい。

もちろんこれでもまだまずい。 元記事のコメントでは、phpのmysql関数群のでは 「;(セミコロン）で区切るような複合クエリに対応してないから大丈夫だろう」的なことが書いてあるが、SQLインジェクション攻撃はなにもセミコロンで区切る方法だけじゃない。 さぼらずちゃんとmysql_real_escape_string() を使おう。
$sql = "select * from geekDB where name_id = '"
. mysql_real_escape_string($_GET["name_id"]) ."'";

そもそもの話になるが、PHPには実はmysqlにアクセスするためのクラス/関数群が三つもある。

1. MySQL関数。元祖。古い。冒頭のコードで多用されていたやつ。
2. MySQL 改良版拡張モジュール。少し新しいやつ。
3. PDO - PHP Data Objects 一番新しいやつ。mysqlに限らない汎用モジュール。

PHP: プリペアドステートメントおよびストアドプロシージャ - Manual

プリペアドステートメントに渡すパラメータは、引用符で括る必要は ありません。それはドライバが自動的に行います。 アプリケーションで明示的にプリペアドステートメントを使用するように すれば、SQL インジェクションは決して発生しません (しかし、もし信頼できない入力をもとにクエリの他の部分を構築している のならば、その部分に対するリスクを負うことになります)。

セキュアになるだけじゃなく、手作業でSQL文組み立てるよりもコードの見た目がわかりやすくなるという利点もある。

<?php
$dbhandle = new PDO('mysql:host=localhost;dbname=データベース名', $user, $pass);

$dbhandle->query("set names utf8;"); // ←さっき書いたとおりでほんとはやりたくないんだが
// ほかに方法がないかも。本来ならDBサーバのmy.confファイル上かなにかで
// 設定すべきなのだろうが詳しくは知らん。いや、php.iniファイルかな？

// select * じゃなくちゃんとカラム名まで指定する。ここは好みかもしれないけど。↓
$statement = $dbhandle->prepare("select geekname from geekdb where name_id = ?");
$statement->bindParam(1, $_GET["name_id"]); // 上の?マークにあてがう
$statement->execute(); // SQLの実行

$row = $statement->fetch(); // 1件しか引っかからないとわかっているなら
// ループさせるまでもなく1行目だけとれば（「フェッチ」すれば）いい。
// 引っかからなかった場合(ゼロ件ヒット）のエラー処理が抜けているのはまずいんだけど
// ここではとりあえずの模式。

$name = $row[0]; // これでひっかかったDBレコードの1行目の1カラム目が$nameに入る。
$dbhandle = null; // 念のため接続閉鎖
// あとは、phpな部分↑とHTMLな部分↓は極力分けよう。
?>
<html>
<head>
<title><?php echo $name;?></title>
<body>
........

なお、プリペアドステートメントじゃ表現できないようなSQLを作らなきゃならない局面も必ずある。 そういうときは、pdo::quoteを使う。

まとめ：

• ある程度まで来たら、巷の初心者向けの本は捨てて、 PHPのマニュアルを読むようにしよう。PHPのオンラインマニュアルはとても充実していて、巷の本のほうが実はそれをパクっていることすらよくある。
• セキュアなコードを書くのは、めんどくさい。 「セキュリティ大丈夫ですか？」ってツッコまれたところで「もっと具体的に言えよセキュリティって言いたいだけちゃうんかハゲ」と思うのは俺だけじゃないだろう。 そういう意味でも、セキュリティ過敏症というやつは大嫌いだ。自分の案件の納期が迫ってるからという話でもないのにフレームワーク使えの一言で済ませることしか考えてない人もね。
• でも、ある程度は慣れの問題だから、ちょっとだけ我慢しよう。 それから、ほっといてもセキュアになるようなアリモノを優先的に使うことも有効だ。 プリペアドステートメントもそんなアリモノの一種だと考えてもいいだろう。 フレームワークみたいな大きなアリモノをいきなり使い始めるよりも先に、こういうレベルでの小さなアリモノを使うことからその考え方を学ぶのも大切なんじゃないだろうか。
• あとは、モリモリ書こう。そのうち、関数やクラスで共通化する、includeでファイルを分ける、例外処理をちゃんと使う、テンプレートエンジンを使う、フレームワークを使う、MVCが、、、ってことになってゆく。

ここから追記：

see also:

• PHPからSET NAMESを使わない方が良い理由と対策まとめ | twk @ ふらっと

ヤフオク「ID乗っ取り」報道に反論、情報流出の事実はない (Internet Watch 2008/9)の件、あらためて、簡単に言おう。

1. インターネット上の様々な便利なサービスは、IDとパスワードの両方を知っているか否かでそれが本人かどうかを確認してることがほとんどだ。

2. だから、パスワードを第三者に教えてはいけない。

3. 誰かが簡単に予測できるようなパスワードを使ってもいけない。1234とかabcdefgとかtaroとかhanakoとか。

この前提条件、いいね？ じゃあ、

5. ここで質問です。

あなたは、楽器屋とかつり道具屋のサイトとかオンラインゲームのサイトとか化粧品屋サイトとか絵本屋のサイトとか、その他もろもろいろんなWebサイトにおいて、ユーザー登録などをするときに、パスワードとして「jdf8!94ngio@mqiovudgr」を使いましたか？
（なんで楽器屋とか釣り道具屋の話になるの？という人は→参考：「おまえがパスワードを流出させたんだ」と決めつける迷惑な人々）

「もちろんNoだ！わたしが jdf8!94ngio@mqiovudgr というパスワードを使ったのはYahooにおいてだけだ！」と自信を持って言える人だけが、Yahooに文句を言う権利があります。

えっ！？まさかYesだとおっしゃる？

じゃあ、教えたんじゃん！楽器屋とかつり道具屋のサイトとかオンラインゲームのサイトとか化粧品屋サイトとか絵本屋のサイトとか、その他もろもろいろんなWebサイトに、jdf8!94ngio@mqiovudgrというパスワードを教えたんじゃん！

そう。最初に挙げた「パスワードを第三者に教えてはいけない。」という前提をくずしたのは、あなた自身だ。

前提をくずした瞬間からあらゆるセキュリティは崩壊する。その全責任は、前提を崩したあなたにある。パスワードとはそういうものだ。 なのにまだ「俺は悪くない」とおっしゃる？

おまえYahooの回し者だろとか、俺は釣り道具も化粧品も買わんとかいうつまらんツッコミは却下。それから、予測しやすいパスワードを使った人に関する話なんてする必要ないくらいアホらしいので、省略。

あえてキビシめに表現したが、これくらい言わんとわからんでしょ。それでもわからん顔をするのがユーザーだし、そこをなんとかすんのも技術屋の役目といってしまえばそうだけどね。 認証という概念に関する現状と問題点とかそういうまじめな話はまた別の記事でやる（かも）。

see also:

• 「おまえがパスワードを流出させたんだ」と決めつける迷惑な人々 (2008/9)
• パスワードはサイバースペースの「実印」 セキュリティー-西本逸郎のセキュリティー表ウラ (日経IT-PLUS 2008/2)
• 結局、予想通りの展開（ヤフオクID乗っ取りの件） (2008/9)

「インターネットとヤフーはどう違うんですか？」っていう人は斉藤アナだけじゃないからだ。

たけくまメモ : 斉藤舞子さんは凄かった（その１） (2006/9)

それはともかく、今回アップされたのは第一回なんですが、早くも熱暴走しております。もちろん俺ではなくて、舞子アナが。

なんとなく「すごい人」だとは聞いていたんですが、ここまでスゴイとは想像していませんでした。どうすごいかを言葉で言い表すのは難しいですので、ぜひネットテレビを見てください。時々、硬直する俺の顔を見られるだけでも貴重かもしれませんよ。

「インターネットとヤフーはどう違うんですか？」

と問われて、どう答えればいいんでしょうか。恐ろしいことにこれが全４回続くわけです。次回の更新は今月２６日だそうです。ちなみに俺の前は偶然にも切込隊長の出演でしたが、隊長の呆れ顔を見るのも一興ですよ。

うーん。まさに強者Yahooならではの悩み。 次元を超越した戦い。

see also:

• ヤフオク「ID乗っ取り」報道に反論、情報流出の事実はない (Internet Watch 2008/9)
• 「おまえがパスワードを流出させたんだ」と決めつける迷惑な人々 (2008/9)
• 俺は悪くないYahooが悪いんだ返金しろ、とか言う人はこれを読んで胸に手を当ててよく考えてね (2008/9)
• 結局、予想通りの展開（ヤフオクID乗っ取りの件） (2008/9)

まったくもって程度の低い記事というか単なる記録なので読み流していただきたく。

いやね、YahooのIDを乗っ取られてどうのこうのという最近の件、

つれづれJUNK

（8/29）被害に遭われ手数料を請求されている方は”IDとパスワードが一致していれば本人とみなす”という規定の無効を請求（消費者団体訴訟による差止請求）をしていただくように消費者支援機構関西さまにお願いしてください。

とかいう、あらゆるインターネットサービスのほとんどすべてをくつがえすようなヨタを叫んでいらっしゃる方なのですが、んじゃもうネット使うなよ電話だけにしろとかいうツッコミはさておき、 そのお仲間（？）のひとつ、 ID乗っ取り被害回復ネットワーク というのが、つい昨日（9月15日）までは存在していたはずなのですが、 9/16日現在でこういう状態になっちゃってる→画像。 なんか、リンクが一個あるだけ。どうされました？編集事故ですか？。 だって、おっかしいよ、Googleでブログ検索（画像こちら）すると、つい3,4日前まで新規投稿があって、確かにいろんな情報があったはずなんだけど。

あれれ？と思って、たしかつれづれJUNK経由でそこのリンクを踏んだと思って今みたら、

（8/19） ID乗っ取り被害回復ネットワーク　様で、事業者に対する申出とその反応に関する情報の集約を進めています。書式は任意で　yidnet@mail.goo.ne.jp　まで、被害情報の報告をお願いいたします。

っていう、確かにあったはずの記述がきれいさっぱりなくなっている。 ちなみに上記の引用はGoogleのキャッシュから。（画像こちら）

この際だから、Googleのキャッシュと9/16夜現在とで並べてみよう。

• つれづれJUNK (9/16夜現在の画像こちら)
• Googleのキャッシュから。（画像はこちら）

よーく見ると、 ID乗っ取り被害回復ネットワーク というGooブログ上のコンテンツの存在が完全に無かったことになっている気がするのですが、 ずいぶんすばやい連係プレーだなあ。

とにかく”臭いものには蓋をする”態度が許せませんでした。

うん。お怒りはごもっともです。

• パスワードはサイバースペースの「実印」 セキュリティー-西本逸郎のセキュリティー表ウラ (日経IT-PLUS 2008/2)
• ヤフオク「ID乗っ取り」報道に反論、情報流出の事実はない (Internet Watch 2008/9)
• 「おまえがパスワードを流出させたんだ」と決めつける迷惑な人々 (2008/9)
• 俺は悪くないYahooが悪いんだ返金しろ、とか言う人はこれを読んで胸に手を当ててよく考えてね (2008/9)
• 結局、予想通りの展開（ヤフオクID乗っ取りの件） (2008/9)

レシピ

1. ドコモの携帯で連続ドットのメールアドレスを取得する

djpgjm258..aa@docomo.ne.jp というアドレスにしてみた。インターネット共通仕様としては本来は許されないはずの、連続するドットや@直前のドットが含まれるメールアドレスを取得できてしまう、というのがポイントだ。

2. GMailからメールを送ってみる

こうなる。

3. Googleと提携したauがGMailと同システムで提供しているauoneメールから送ってみる

こうなる。

いつまでこんな混乱を撒き散らし続ける気なんだろう？→ドコモとau
いつまで他人のせいにしつづけるつもりなんだろう？→ドコモとau
メールアドレスの設定変更画面でそういうアドレスを取れないようにちょこっと変更するだけでとりあえず出血を止めることくらいはできるでしょ？→ドコモとau
ほっといたところで傷口が広がる以外のことは起きないのにいつまでグズグズしてんだろう？→ドコモとau

ドコモもそうだがauはもっと深刻だ。auoneメール使ってるユーザーからの問い合わせが急増して現場の担当者は苦悩してるんだろうな。

なお、Googleの企業向けサービスを使って自社ドメインのメールサービスをGMailに頼っている企業や団体でも、同じことが起きている可能性が非常に高い。

世界中で使われているGmail。基盤システムは共通だ。この仕様変更をくつがえすのは、難しいよ。なお、本来あるべき仕様を10年来くつがえし続けているのはauとドコモのほうなので誤解しないように。

• RFCを読まなかった携帯キャリアの罪　 (2004/10)
• DoCoMoの説明にある「RFCに準拠しています」はウソ (2006/4)
• ドコモの説明から「RFCに準拠しています」が削除 (2006/4)
• みんなで渡れば怖くない － au by KDDI メールアドレスにRFC違反を故意に許すの巻 (2006/6)
• KDDI 会社情報: ニュースリリース > Googleの技術を活用した「au one メール」の提供について (KDDI 2007/7)

• ドコモもauもいいかげんにメールアドレス設定の仕様を直せ。 (2007/11)

• ドコモもauもいいかげんにメールアドレス設定の仕様を直せ。の続きと補足 (2007/11)

• 仕様変更？アドレス認識できないエラー発生 - Gmail 要望・提案 | Google グループ (2008/9)
• au one net（旧名称DION）ではいまだに連続ドットのメールアドレスが取れてしまうの巻 (2008/9)

アラの指摘ばっかりだなあ。でもまだまだ続くよ。

ヤフオクでID乗っ取りで覚えの無い出品手数料その他が請求されまくりの件。

適格消費者団体　特定非営利活動法人　消費者支援機構関西 (2008/7)

インターネットオークションYahoo! JAPAN ID乗っ取りについて

　ネットオークション大手のヤフーオークションに関して、会員のIDが乗っ取られ何者かによって出品がなされた結果、身に覚えのない利用手数料等の請求を受けている等の被害が多発しているようです。
（途中省略）
調査をより効果的に進めるため、このたび、アンケートを実施することに致しました。

ということで、アンケートの最後にある「6.その他（KC’sへの要望）など」のところに書く内容を考えてみた。もう少し直したあと週末にでも送る。

see also:

• パスワードの危機(その１) − きっかけ (2004/2)
• パスワードの危機(その２) − あるべき姿 (2004/2)
• パスワードの危機(その３) − 楽天の場合 (2004/2)
• パスワードの危機(その４) − SSL催眠術 (2004/2)
• パスワードの危機(その５) − アマゾンの場合 (2004/3)
• 「おまえがパスワードを流出させたんだ」と決めつける迷惑な人々 (2008/9)
• 結局、予想通りの展開（ヤフオクID乗っ取りの件） (2008/9)
• パスワードはサイバースペースの「実印」 セキュリティー-西本逸郎のセキュリティー表ウラ (日経IT-PLUS 2008/2)

あんまし趣味じゃないですが、でもこういう二枚舌はつっこまざるをえない。

一生懸命なにかを叫んでいらっしゃるこちらの方 (9.20現在の全体の画像ここ）なのですが、 その一部を拡大すると

っていう話になっているのですが、この部分はほんの2,3日前（Gogleキャッシュを画像化）と比べると

っていうことになっている。

無かったことにしたい過去は誰にでもあるものだが、じゃあいったいいまの彼は何を叫びたいのだろう？といったあたりが見えない。そんなところまで他力本願の人任せ？

そういうことをはっきりさせないままの状態でつきすすんだところで、 「当サイトは、yahooを中傷・批判する為のサイトではありません。 」とか 「とにかく”臭いものには蓋をする”態度が許せませんでした。」 なんて話はなんつーか、ブーメラン。

see also:

• ヤフオク「ID乗っ取り」報道に反論、情報流出の事実はない (InternetWatch 2008/9)
• 「おまえがパスワードを流出させたんだ」と決めつける迷惑な人々 (2008/9)
• 拝啓 消費者支援機構関西 様 (2008/9)
• 結局、予想通りの展開（ヤフオクID乗っ取りの件） (2008/9)

2008.09.04 【お知らせ】 「セカンダリDNS（ゾーン転送設定）」の提供開始、利用料は無料 (お名前.com 2008/9)

すごく地味だけど必要なサービス。技術的にそんな複雑でもないのでなんで今までなかったんだろうと思うくらい。 （いや、既にほかにあったのかもしらんけど） なお過去にはセカンダリDNSじゃないものをセカンダリDNSとうたおうとしていたこともあったのだが、 今回は本当にセカンダリDNSである。(笑)

これにはさすがに驚いた。 はたと思い出して、自宅でKDDIの回線使っている知人に、去年に続いてまた試してもらったんですよ。

説明するまでも無く誰もが知っている、
1. 大手の通信キャリアであり、
2. 携帯電話キャリアでもあり、
3. ISP（インターネットサービスプロバイダ）のひとつでもある、
KDDI株式会社が提供するau one net(旧名称DION）というISPサービスでは、 いまだにこんなことになっている。

この件に関しては、2007年11月つまり今から10ヶ月ほど前に書いた ドコモもauもいいかげんにメールアドレス設定の仕様を直せ。の続きと補足という記事の冒頭でも紹介したとおり。 あのときは、これはきっと一時的なものでそのうち直るだろうと考えていたのだが、まったく勝手な希望的観測だったようだ。

いくらなんでもウンコすぎるだろau by KDDI。

Gmailでやるとこうなる。メール送信できない。

Gmailと同システムでやってるauoneメールでやるとこうなる。メール送信できない。

Outlook2007やSP3をあてたOutlook2003ではこうなる。メール送信できない。

MSN Hotmailでやるとこうなる。メール送信できない。

Outlook Expressの後継の「Windows Live メール」でやるとこうなる。メール送信できない。

ユーザーには 「. (ピリオド/ドット)をアドレス内で連続使用すると、一部のプロバイダーとメールを送受信できない場合があります。」 って小さく書いてアリバイ作っておきさえすればどうにでも逃げられるから、 あとはほっとけばなんとかなるとでも思っているのだろうか。

逆でしょそれ。ほっとけばほっとくほど傷口は広がり首は絞まっていく方向にしか進まない。

どのISP使っているかにかかわらずoutlook2007やWindowsLiveメールをメールクライアントとして使っている人はすべてメールを送信できないんだから、「一部のプロバイダーとメールを送受信できない場合が」っていう説明自体がすでにウソになってしまっているし。 auoneメールはどうなるの？「一部のプロバイダー」なの？auoneのロゴマークをデカデカとうたっているのに？ 「この場合のプロバイダーって具体的になんのことですか？」と聞いたらどんな回答が返ってくるのだろう？

誰が好むと好まざるとにかかわらず、PCやネットワーク環境そしてソフトウェアはどんどん進化する。予測は難しい。 だがメールアドレスは、3年とか5年とかあるいは10年以上という長いスパンで同じものを使い続けるのが普通でありそれは予測可能／不可能という話ではなくて単に事実である。

だからこそ最初にメールアドレスを決定する段階で標準仕様に沿っておくことがとても重要だ。 KDDIはその程度のことも考えられないくらいどうしようもなく脳ミソが空っぽらしい。

もちろん、他のISPの中の人にはちゃんと脳ミソがある。

niftyの場合

@niftyユーザー名 ご入力上の注意（←これがアカウント部分、つまり@の左側の規則にあたる）

• 2～32文字で入力してください。
• 使用できる文字は、半角英数字、ハイフン( - )、アンダーバー( _ )、ピリオド( . )です。
• @niftyユーザー名は、英大文字と英小文字が区別されません。
• ピリオドは、末尾や連続での使用はできません。
• 先頭の１文字は必ず英文字にしてください。
• 英字3桁＋数字5桁の組み合わせと英字4桁＋数字4桁の組み合わせはできません。
  　 (禁止形式例：abc12345 wxyz9876）

biglobeの場合

BIGLOBEメール｜BIGLOBEメールの仕様
ご注意

• 先頭の文字には、半角英小文字または半角数字を使用してください。
• .（ドット）の連続や、最後の文字に.（ドット）を使用することはできません。
• 既に他の方が使っているメールアドレスは取得できません。

IIJ4Uの場合

メールに関するQ&A
設定可能なメールアカウント名（メールアドレスの"@"より左側の文字列）には、以下の制限があります。

• アカウント名の長さは、2文字以上8文字以内です。
• 使用できる文字は以下のとおりです。
  • "a"～"z"の半角英小文字
  • "0"～"9"の半角数字
  • "-"（半角ハイフン）
• 1文字目は英小文字のみ使用できます。

wakwak（NTT-ME系列）の場合

WAKWAK - メールサービス
ご指定いただけるアカウントは3文字以上16文字以内で、使用できる文字は「小文字英数字」「ハイフン (-)」「アンダーバー (_)」「ピリオド (.)」です。また、先頭文字は英字のみで、「ハイフン」「アンダーバー」「ピリオド」の前後は英数字となります。

So-netの場合

http://www.so-net.ne.jp/abox/base/srvce/guide01.html

アカウント名には以下の制限があります。
文字数 3文字以上、32文字以内
使用可能文字 アルファベット小文字、数字、-(ハイフン)、_(アンダーバー)
のみ使用（アルファベット大文字、漢字カナ文字など上記以外の特殊文字は
使えません）その他 先頭文字はアルファベットを設定してください。

Yahoo!メールの場合

https://edit.yahoo.co.jp/config/eval_register
Yahoo! JAPAN ID
・ 最初の文字はアルファベット
・ 記号は、アンダーバー（ _ ）のみ使用可能です

GMailの場合

連続するドットを使うとはじかれる。

アカウントの最後（@の直前）にドットを入れると、はじかれる。

ところで、

「@ の直前にピリオドがあるなどのRFC に準拠していないアドレスとのメール送受信について」という題名でMSNのヘルプに書かれていた、 2006年10月の日付で書いてあった内容（ドコモもauもいいかげんにメールアドレス設定の仕様を直せ。で引用している文章）が更新されて、もうすこしわかりやすい文章になっているようだ。よくできているので、ここに全文を引用させてもらおう。

@ の直前にピリオドがあるなどのRFC に準拠していないアドレスとのメール送受信について MSN ヘルプ - お知らせ

平素より Windows Live Hotmail をご利用いただき、誠にありがとうございます。

Windows Live Hotmail のアカウント（メールアドレス）では、@ の直前に「.」(ドット)があるメールアドレスや、特殊な記号を含むメールアドレスとの送受信において、エラーが表示されたり、配信に問題が発生する場合がございます。


　　　【問題が発生するメールアドレス例】

　　　・ @の直前に「.」(ドット)があるメールアドレス
　 　 (xxxx.@xxxxxx)

　　　・ 「.」(ドット)が連続しているメールアドレス
　 　 (xx..xx@xxxxxx)

　　　・ 「/」「?」スラッシュやクエスチョンマークなどの記号が含まれるメールアドレス
　 　 (xx/xx@xxxxxx　　xx?xx@xxxxxx)

　　　【原因】

　　　RFCでは、"@" の前の文字列をピリオドやドット ( . ) で区切ることは許可されておりますが、
　　　区切り文字であるピリオドや "@" などを連続して使用すること、および、
　　　特殊な記号を含むメールアドレスは許可されていないことにより、
　　　Windows Live Hotmail での送受信に影響を与える可能性がございます。


　　　　※コンピュータ用語辞典　-　■RFC（Request for Comments）とは
　　　---------------------------------------------------------------------
　　　RFC とは、インターネット技術標準化委員会が提唱している規格です。
　　　インターネットに関する世界標準は、The Internet Engineering Task Force (IETF) という
　　　組織で策定され、RFCという文書で公開されています。
　　　---------------------------------------------------------------------


昨今、携帯電話やインターネットの普及により、文字列、記号などをメールアドレスとして使用できるよう、
独自の作成規定をお持ちの企業様もございます。


ご不便をおかけいたしますが、MSN および Windows Live では、
世界共通となるインターネット通信規格（統一された仕組み）にてメールの送受信が
できることが望ましく、RFCに準拠していることが必要であると認識いたしております。


そのため、上記、【問題が発生するメールアドレス例】のような文字列との送受信に
制限がございますことを、何卒、ご理解、ご了承くださいますようお願い申し上げます。

今後とも Windows Live Hotmail をご愛顧いただきますようよろしくお願いいたします。

[2008.08.10 更新]

MSの中の人は、ちゃんと脳みそを使って自分の立場と考えを誤解を抑えるべくわかりやすく表明している。えらいね。で、KDDIの中の人には脳みそあるのないのどっち？

see also:

• みんなで渡れば怖くない － au by KDDI メールアドレスにRFC違反を故意に許すの巻 (2006/6)

• ドコモもauもいいかげんにメールアドレス設定の仕様を直せ。 (2007/11)

• ドコモもauもいいかげんにメールアドレス設定の仕様を直せ。の続きと補足 (2007/11)

• GMailからはドコモやAUの連続ドット(RFC違反)メールアドレスにメールできなくなった (2008/9)

keep-aliveでHTTPコネクションを放置するベンチマーク(abパッチ) : Media Technology Labs (MTL) : メディアテクノロジーラボ　ブログ

いいねこれ。keepalive状態の接続が増えるとどうなっちゃうか？っていうテストはやりたくても手軽にやるツールがコレといってなくて、何年か前にわざわざperlでそれっぽいものを書いた覚えがある。apacheのコミッタ陣にこのパッチ送ったらそのまま採用してくれるんじゃないの？

Linux チューニング - Ext3 のパフォーマンスを最大化させる :: Drk7jp

これも面白い。ext3にいろんなオプション設定があるのは知ってたけど、ジャーナリングモードがここまで影響大きいとは。あとで使うかもしれないのでメモ。 とは言っても手元のサーバのいくつかはi/o性能の状況をモニタリングしてないのでまずはそこから始めなければならん。

意味あるんだろうか？

某所で運用されている数十台のサーバー群のすべてで、ntpdが常駐してた。そういう設計になってるのをまったく他のところでも見かけたことがあるので、なんだろう、定石みたいになっているのだろうか。

一部の人には釈迦に説法だろうが一応説明すると、ntpはクライアント／サーバなソフトである。 クライアント（例：ntpdateコマンド）は、指定したサーバに「いま何時？」と聞く。 サーバー（例：ntpdデーモン）は、「いま○○時だよ」と答える。

ちなみに筆者はサーバの時刻あわせ設定はいつも

$ cat /etc/cron.daily/ntpdate 
#!/bin/bash
/usr/sbin/ntpdate -s ntp.jst.mfeed.ad.jp
/sbin/hwclock --systohc
exit 0

ほとんどのケースでは、他のマシンに時刻情報を提供したい、という要求ではなくて、マシンの時計を合わせておきたいというだけの要求だろう。だとすればntpクライアントを定期的に実行するだけでいいはずなのに、なんでかしらんけどntpデーモンが常駐してntpサーバとして稼動させるケースが多いみたい。確かにそれでサーバの時刻は一定時間ごとに自動補正されるけどさ。 （注：NTPサーバの時刻が狂っていたらお話にならないので、ntpdデーモンはクライアントの問い合わせに答えるだけでなく、一定時間ごとに基準とするほかのNTPサーバに問い合わせて自らの時刻を補正する機能を併せもつ。）

常駐している必要の無いプロセスが常駐している状態は気持ち悪いかつリソースの無駄と感じる俺の頭は古いのだろうか。 ntpdなんて小さなプロセスが食うリソースなんて知れてるからいいんだ！という、富豪プログラミングならぬ富豪的サーバー運用なのか？ いまさらNTPデーモンにセキュリティホールが！なんてこともなさそうだしなあ。

あ、そうか、デーモンで動かしておけば「そのサーバの時刻が合ってるか」っていうのを外部からのntp問い合わせで確認／監視できるというメリットがあるな。 でもサーバー／ＮＷ監視対象項目にそんなのあったかどうかまでは覚えてない。 そもそもntpd通さなくともマシンの時刻くらいならsnmpで取得できそうな気もする。

なお、「なんでもかんでも /usr/sbin/ntpdate -s ntp.jst.mfeed.ad.jp とかやっちゃだめだろちゃんと自分のプロバイダが提供しているやつとか、とにかく近くのNTPサーバを指定するようにしないと！」という話は近代日本では昔話だと思う。 マルチフィード社の回線は主要プロバイダ直結で十分太いし、そもそもいまどきみんな回線速いし、mfeedも普通のPCでも使ってね的な説明をしている。NICTのほうも毎秒100万リクエストでもOKだからドンと来いと言ってる。 福岡大のNTPサーバがアクセス集中で悲鳴をあげてた話なんてのも今となっては古きよき時代の伝説である。

もちろん、0.1秒未満の誤差で全てのマシンの時刻を合わせたい！とかいうシビアな要求であればここまでの話とはまたちがうと思います。。

追記：

ntpdにslewモードってのがあるのを実はいま初めて知った(汗) ７へぇ。時刻ズレで苦しんだ経験がほとんど無いせいか知らなかったです。 デーモン常駐でやるメリットはそこかなるほど。 解説は→時刻の後戻りを発生させずにシステム全体の時刻を確実に同期させたい：ITpro

第３回日本ケータイ小説大賞：あたし彼女

1ページあたり2秒くらいの高速で読むも全429ページ中78ページ目で挫折。感想？腹立った。そんだけ。みたいな。

ヤフオク「ID乗っ取り」で不正出品、被害は5000件に (Internet Watch 2008-09-26)

「入力されたIDの9割以上はYahoo!に存在せず、その中にはYahoo!では使えない『.（ドット）』や『-（ハイフン）』などの記号を含むIDも多かった。一方、Yahoo!で使われているIDが入力されたのは4％程度。不正なログインが確認されたケースでは、いずれも1～2回の入力でログインに成功していたことから、他社とYahoo!のID・パスワードが同一のユーザーが被害に遭った可能性が高い。」（ヤフー広報部）

大方のというか、少なくとも、IDとパスワードで認証するというタイプのWebサイトの構築／運営に関わったことのある人なら、容易に予想していたであろうそのまんまの展開。 （詳細は2週間ほど前に筆者が書いた「「おまえがパスワードを流出させたんだ」と決めつける迷惑な人々」を参照してください）

一方で同じ件に関する読売新聞の記事は

ヤフオクＩＤ乗っ取り、特定アドレス１５０万件接続 : 社会 : YOMIURI ONLINE（読売新聞） (2008-09-26)

ＩＤなどが流出した経緯について、ヤフーは「会員がフィッシング詐欺に遭った可能性がある」と主張。また、ヤフオクのＩＤやパスワードと同じものを別のサイトで使っている人もいるため、「別のサイトから流出したＩＤなどのリストが使われているのではないか」と推測する。

　しかし、被害に遭った会員の中には、ヤフオクでしか使っていないＩＤなどを用いて侵入されているケースもあり、ヤフーの主張とは食い違う点もある。

ヤフーの言っていることは「主張」と書きつつも、会員の言っていることは「ケース≒真実」のように書いていることがこの記事のミソ。実際はどっちも「主張」なのに、そう書くとイーブンになってしまうからそうは書かない。 いずれにせよ新聞記者的に（世間一般的にも）ありがちなかたよりである。「大きな方が悪だ」

ヤフオクでID乗っ取り5000件　ヤフー、不正出品の被害補償へというITMediaのニュースも内容的に同じなので一応リンクしておく。

いずれも共通しているのが、元をたどれば他社からパスワードが漏れたことに起因してる可能性が高いと報じているわりには、さらにその元をたどると他社で同じパスワードを使っていた＝パスワードを（この場合ではヤフオク以外の）第三者に教えてはいけないという常識的ルールを破っていたユーザーである、という実態についてなんら言及していない。なんだかなあ。

そしてなによりも、Internet Watchと読売新聞の両方の記者が書くべきだったこと↓

「いろんなサイトで同じパスワードを使いまわしている人はそもそもそれはおかしいことなのでなるべく早くパスワードを変えましょう」ぐらい最後に添えろよ。

「パスワードを平文で保存していたこと自体を指弾する業界関係者や業界マスコミがほどんどいないということに、もう驚愕っていうか、絶望」している件は、やっぱり期待してもしょうがないからいいや。。。

see also:

• パスワードの危機(その１) − きっかけ (2004/2)
• パスワードの危機(その２) − あるべき姿 (2004/2)
• パスワードの危機(その３) − 楽天の場合 (2004/2)
• パスワードの危機(その４) − SSL催眠術 (2004/2)
• パスワードの危機(その５) − アマゾンの場合 (2004/3)
• 「おまえがパスワードを流出させたんだ」と決めつける迷惑な人々 (2008/9)
• 拝啓 消費者支援機構関西 様 (2008/9)
• パスワードはサイバースペースの「実印」 セキュリティー-西本逸郎のセキュリティー表ウラ (日経IT-PLUS 2008/2)

追記

コメントありがとう。 レインボーテーブルの話なら他の記事でコメントしていただきたかったところですがまあ一応ここで紹介しておきます。

レインボーテーブル - Wikipediaより。

salt の使用
ハッシュに salt が使われている場合、レインボーテーブルの有効性は著しく低下する。例えば、次のようなハッシュ関数 MD5() を考える（ここで、 "." は文字列結合演算子とする）。

hash = MD5 (password . salt)

このようなハッシュからパスワードを得る場合、取りうる salt の値の数だけテーブルを作成する必要がある。このような場合、レインボーテーブルの効果は大幅に薄れてしまう。

小女子(コオナゴ)殺害予告犯の何がいけなかったのか - コデラノブログ 3

僕が思うにこの事件で彼がいけなかったのは、すごく単純なルールを破ったことだった。つまりそれは、
「ガチな大人をからかっちゃいけない」
ということである。

たしかにそうだ。でもイキじゃないよね。

こんな感じ。

上のうち、たとえば一つキャッシュを見ると、こんな感じ。

9/29夕方現在、大慌てでメルマガシステムの閉鎖＆修正中。

いま流行のSQLインジェクション攻撃によるデータベース丸ごと漏れ出し、、、、とかじゃなくてよかったね。詳細な分析はまたあとでやる（かも）。

追記：

「大急ぎでrobots.txt書いてみた。待つしかない。」そんな感じなのだろうか。

http://emagazine.rakuten.co.jp/robots.txt

User-agent: *
Disallow: /m
Disallow: /q
Disallow: /rs
Disallow: /n
Disallow: /ns
Disallow: /shops

追記：

「よく考えたらemagazine.rakuten.co.jp配下には大したコンテンツ無いんだった。バルス！」 （mdn.mainichi.jpでもそんなことあったな）

http://emagazine.rakuten.co.jp/robots.txt

User-agent: *
Disallow: /

なるほどそういうことか。 こっちも参照。 ユーザーはなにするかわからんから怖いね。 もちろん「なにするかわからんのがユーザー」という前提でシステムづくりすることも肝要。