セブンペイ事件に関連してのセキュリティ考察その３です。
あくまで私の小並感。数年後自分で赤っ恥と思うかもしれないが！
認証に関する考え方（つづき）
インターネット・Web自体が元々セキュアな設計ではなかった
インターネットの黎明期においては、あまりセキュリティは意識された実装にはなっていなかったように思います。
私が初めてインターネットに触れたのが1992年ごろの大学だったと思いますが、主に学術系の方が利用しており、情報の公開、交換の場として存在していました。基本的にオープンな情報を交換するのですから、秘匿する必要がなかったわけです。当時のブラウザのMosaicにもhttpsのような機能はなく、HTTPS over TSL(RFC2818)が規定されたのも2000年です。
メールのプロトコルのPOP3やファイル交換のFTPはID、パスワードはあるものの、平文で交換されており、通信を盗聴すればすぐ判明してしまう程度でした。また、FTPでAnonymousが認められているサーバも割とありました。メール送信のSMTPに至っては、初期の仕様では認証機能がなく、IPアドレスさえ分かれば誰でも送信ができてしまうような仕様でした。
これは、意識が低いからではなく、当時の時代背景があります。
まず、これらは当時一般的には公開されておらず、一部の知識人しか利用していなかったことがあります。つまり、十分信頼できる人たちがユーザだったわけです。また、メールを除けば、たいていの情報は公開情報だったため、盗むといった概念がなかったこともあると思います。
暗号化についても、1990年代前半の一般的なコンピュータは、メインメモリが1MB～の16bit機が普及してきていたところでした。まだまだ暗号の計算コストがばかにならなかった頃です。しかも、当時は暗号の輸出規制があり、規制を下回る弱い暗号しか使えなかったことも背景にあるかもしれません。
通信速度についても、一般の電話回線を使うと9600bpsという速度でした。今の光通信が100Mbpsとすると、速度差は1万倍にもなります。不要な通信の増大は避けたかった、という当時の思惑もあると思います（大学と繋ぐと、結構いい電話代になったんですよ・・・）。
つまり、当時はセキュリティの意識が低かったというより、必要がなかったから無かった、というのが正解だと思っています。
こういったことから、当初の通信プロトコルには、あまりセキュリティに関するものが含まれていませんでした。
ところが、普及していくに従い、センシティブな情報を含んだり、悪意をもってその情報を盗ろうとするといったことが見受けられるようになってきました。それに従い、既存のプロトコルに認証機能を追加したり、暗号化を追加したりしていきました。インターネットの普及とともに、走りながら機能追加していったわけです。
認証についても同様で、初期はパスワードのみ、しかも基本認証、FTP、POP3などは平文で送るといった状況でした。パスワードの保存も、ソルトなしMD5などが多く見られました。
しかし、扱う情報に機密性が必要になってきた一方で、平文のパスワードが通信の傍受に弱い、MD5の解読が容易になってきた、といった変化が生じました。これに伴い、認証も変化せざるを得なくなってきました。
最初は、パスワードを送受信する通信を暗号化するといったことから始まりました。
しかし、パスワードを使う機能の増加によるパスワードの使いまわしによる弊害、パスワードの解析技術の進展、リスト型攻撃などの攻撃技法の洗練化で、「パスワードは破られる可能性がある」ものとみなさなければならなくなってきました。
こうした中で、二段階認証、二要素認証が必要になってきたんだろう、と理解しています。
元々のインターネットの思想に無かったものの後付けですから、最新の動向やスタンダードを追っていかなければ、インターネットを用いた事業は難しいのではないでしょうか。
「セキュリティ審査はした」とは言うけれど・・・
例の記者会見で、「システムの安全性を確認してからサービスを開始している」といったことは繰り返し述べられていましたが、ここはネットでの反応を見ても、多くの人が疑問を呈したり反発していました。
そりゃ、事件おきてるんだもん。説得力ありませんわ。
十分セキュリティを満たしていれば、事件は起きないよ？その審査意味あるの？って話。
こうなると、いったい「誰が」、「何を基準にして」、「どのように実施して」、「指摘事項にどう対応したか」といった点が焦点になるかと思います。
このあたりは、明確な発表は今のところ目にしていないので、推測したりあるべき論くらいしか言えないんですが。
「誰が」は、セキュリティ知識がある人がやるというのは大前提（ただし、今回の事件をみていると、それすら疑いたくなる香ばしさがあるんだけどな）として、社内なのか社外なのか、その人にどの程度の権限があったのかも気になります。
つまり、指摘しても、「下っ端がなんか言ってるわｗ」でスルーされるような人に、形式的にやらせてたってことはないよね？っていう点は気になります。
次の「何を基準にして」と「どのように実施して」が重要な肝だと思います。
色々なガイドラインがあると思いますが、いまどきのガイドラインなら、認証系で二段階認証、二要素認証には触れていると思います。また、Web実装なら、OWASP top 10をみればA-2に明記してあります。つまり、ある程度のガイドラインを使っていれば、で二段階認証、二要素認証の欠如は指摘されてしかるべきではないかと思うのです。いったい、どんな基準で「セキュリティ審査」したんでしょうね？多くの方が疑問に思ったのはここじゃないでしょうか。
また、セキュリティの診断というのは、実装されているものに対して行われます。つまり、実装されていない機能については診断しないし、そこに脆弱性はでないでしょう。また、手続きの流れについても、「それが正規の流れ」といわれれば、診断しているほうとしてはそれまでです（それでも、親切なところはツッコんでくれるんですけどね）。
つまり、設計、仕様策定の段階でセキュリティチェックをしていれば指摘されたと思うのだけど、なぜされなかったのだろう？というのも大きな疑問です。
実は、問題になっているWebのパスワードリセット画面は、渦中のセブンペイの持ち物ではなく、親会社かシステム会社の持ち物で、そこの指摘はとばっちりだったんじゃないか・・・と思ってもいるんですが。まあ、それはグループ会社の宿命なのと、アプリ画面のフローからやっぱり同程度のセキュリティレベルなんだろうなと理解しています。
また、「指摘事項にどう対応したか」といったところも気になります。
多くの人が思うように、「二段階認証、二要素認証の不備を誰も指摘しなかったのか？」という疑問があります。そして、開発現場でたまにある、指摘事項に対して「これが仕様だから」で問題なしと落とされてなかったか？ということは懸念しています。要は、指摘しても言い訳して問題なしで落としていくアレです（どこの会社での開発時代の部課長とは言いませんが・・・）。
コレに関しては、最初の「誰が」にもかかってきます。要は、折角の指摘も、組織の力関係や都合でもみ消してなかったか？といったところには大いに興味があります。
また、実装上の問題は本当になかったか、という点も気になります。
むかーし見た酷いものでは、適当なユーザを作ってログインしたあと、hiddenになっているIDを他人のものに変更すると、他人に成りすましできちゃうっていうとんでもない仕様の実装をされていたところもあったので・・・。
流石に、脆弱性診断していれば見つかる・・・とはいえ、あのパスワードリセットを実装する会社のすることといわれると・・・おお、怖い怖い。
「セキュリティ審査をした」といくら強弁したところで、事件が起きてしまった以上、言い訳にならないということが良く分かる例だと思います。
せめて、どのような基準を用いて、どのような実施方法だったかくらいは説明しないと、誰も信じないんじゃないですかね。
このあたりは、情報公開の考え方にも一考の余地がありますね。
え・・・長い・・・まだ続くの・・・。
時間的に明日ということで、ここでまたぶった切り・・・。