パスワードの危機(その４) − SSL催眠術

（前回からの続き）いったいいつのまに、どうして、このような状況になってしまったのだろう？

技術者の無知

特に2000年前後のITバブル期の頃、Webというものが急速に普及した結果、「にわかIT技術者」が急増した。パスワードの取り扱いに関する従来のあるべき論を学ぶことも無く、 IDとパスワードで認証するタイプの会員制Webシステムの構築をいきなり任されるケースが多発した。

発注者の無理解

Webシステムの発注者、つまりWebサイトの運営者側は、パスワードの取り扱いなどといった技術的な意味合いが強い（と思われている）話にはついていけない（ついていく気もない）ケースがままある。パスワードがどのような形でデータベースに保存されているかなんてことには無頓着だ。そんな状況で、システム構築業者が技術者としてのモラルを働かせ、「パスワードは暗号化（ハッシュ化）して保存するようにしましょう」と提案したところでクエスチョンマークな顔で怪訝にされるだけだ。パスワードを忘れたユーザーに対する対処が生パスワードを見て教えるだけなのとは違い、新たにパスワードを登録しなおしてそれを教えるという業務の増加があるということ (その2参照)まで話すと、無理解な発注者は却下するだろう。 「担当者がデータベース上のパスワードを見てそれをそのまま教えればよかろう、余計な仕組みも無駄な業務もいらない、そのぶん安く早くしろ」と。

必要とされるシステム自体の変質

WebやE-MAILが登場する以前は、システムはもっと小さかった。ここで小さいというのは利用するユーザー数やネットワークの規模のことだ。たとえば、中規模の不動産屋が自社で扱う不動産物件の情報を一元管理するデータベースシステムにアクセスするのは、自社の社員だけだった。それは多くてせいぜい数十人か数百人。しかも社内のコンピュータからしか接続できない閉じたネットワークで、だ。 そこではユーザーIDとパスワードをさほど重要視する必要はなかった。

しいて言えば銀行のATM網は昔からユーザー数は非常に大きい。しかし、やはり閉じたネットワークで、端末も特殊で、アクセスするにはキャッシュカードという物理的な媒体も必要。もともとが現金を扱うという超クリティカルな業務なので警戒も厳重。これではパスワードの保存方法云々を議論するまでもなく不正は難しい。

万単位の不特定多数が、不特定な端末を使って、不特定なネットワークを経由して、ひとつのコンピュータシステムにアクセスする。そんなシステムはインターネット以前にはほとんど存在しなかったのだ。 10年ほど前のような小さく閉じたシステムに慣れた技術者（または発注者）であれば、これまで述べたようなパスワード管理に関するあるべき論を知らない（重要視しない）、のも無理は無い。もちろん本当はそれじゃいけないのだが。

低価格、短納期

とどめを刺すかように、やはりITバブル期以降、システム構築の低価格化と短納期化が急速に進んでしまった。システムを作る側としては、少しでもコストを抑え時間を稼ぐためにパスワードの暗号化（ハッシュ化）保存処理などは 必要とわかっていても提案すらしないケースがあると思われる。貴重なお客様と金と時間を前にすれば、技術者としてのモラルなど・・・。

SSL催眠術

「当社では個人情報保護のためにSSLを使用しています」というSSL催眠術。これが一番やっかいだ。
http://ではなくhttps://ではじまるURLは通信内容がSSLという技術で暗号化される。 SSLの名誉のために言っておくと、簡単に破られるような暗号ではないし、実際SSLを破ってなんらかの事件につながった例はほとんどない。しかしSSLは通信の経路上で盗聴されることを防ぐためのものだ（暗号化により内容がわからなくなってるから盗聴しても意味が無いという理屈）。したがって、

SSLは内部犯行に対抗できない
通信の経路上ではないところで起きること、つまり、データベースに直接アクセスしてデータを抜き取るようなケース＝内部犯行＝においてはSSLは無力である。
ローソン、顧客情報流出事件の調査結果を発表 (CNET Japan 2003/08)
−「委託先の開発用コンピュータから抜き取られた可能性が極めて高い」 −

ファミリーマート、ネット会員18万人分の個人情報が流出 (itmedia 2003/11)
− 従業員または委託先の従業員による内部犯行説が有力 −
前回（その３）で書いた楽天での例も同じことである。
SSLは単純ミスに対抗できない
Webシステムの不具合や設定上の単純ミスで、本来表示されてはならないことが表示できてしまうケース。これも通信の経路上で起きることが原因ではない。したがってSSLを使っていたとしても全く意味を成さない。
3万7000人の個人データ流出エステサロンのTBC (Mainichi Interactive 2002/5)
− アクセスにはパスワードなども設定していなかった −

アマゾン書評、自作自演が発覚(cnn.co.jp 2004/2)
− アマゾン・ドット・コムのカナダ版で書評欄に書き込んだ人々の個人情報が表示されるシステム障害 −

このように、これまで起きた（＆今後起きるであろう）個人情報漏洩事件の原因のほとんどはSSLの力が及ばないところにある。にもかかわらず「SSLを使います」の一言を持ち出すだけで Webシステム発注者（＝Webサイト運営者）もその上司も末端のユーザーにも、あらゆるセキュリティ問題は無くなると勘違いさせることができる。 IT業界特有の3文字アルファベット式催眠術の一種なのだ。

このSSL催眠術はほんとうに意外と強力だ。「パスワードの暗号化（ハッシュ化）？なにそれ？SSLなら使ってるよ、それでも何か問題あるの？」 Web業界の技術とビジネスの両方に相当詳しい人間であっても、そんな認識を平気で言う例を筆者は過去幾度と無く見ている。

さて、さんざん脅かして不安をあおるだけではなんなので、現実問題としてWebシステムにおいてパスワードをどう取り扱うべきなのか、ということについて述べてゆこう。（次回に続く）

※SSLには通信の暗号化のほかに情報の出所確認という機能もあるのだがテーマと無関係なので省略。