Previous month:
March 2008
Next month:
May 2008

WSSEのセキュリティリスクとその対処法に関する一考察

 引き続きiPhone SDKで遊んでいる私だが、Typepadやはてなが採用しているAtomを使ったiPhoneアプリを作ってみようとしたところで、WSSE認証の仕組みを(Objective-Cで)ゼロから作らなければならないことに気づき挫折しかける。SHA1のライブラリまで自前で用意しなければならないのはちょっと荷が重かったのだが、増井さん(masuidrive)からRFC中のコード(参照)が使えることを教えていただき、それを元に実装(持つべきものは友だ^^)。

 細かな間違いをいくつもしていた上に、WSSEの仕様を少し勘違いして始めたためになかなか動かず、はてなからステータスコード200がもらえたのは夜の10時過ぎ。半日ぐらいで軽く作れると思っていたのに、結局丸一日かかってしまったが、「WSSEとは何ぞや」を何も知らないところから始めたのだから良しとしよう。

 しかし、WSSEの仕様に関して少し心配なのは、生のpasswordテキストをcreationDateとNonceをくっつけてからハッシュを作ってからサーバーに送るという部分。認証のためにはサーバー側で全く同じ計算をしなければならないのだが、そのためにはデータベースに生のpasswordをしまっておかなければならないことを意味する。これはセキュリティ上大きな問題があるように思える(参照)。

 私の知る限り、複数のアカウント間で同じパスワードを使っている人は多い(これはこれで大きな問題だが、そんなユーザーたちを非難するのではなく、ちゃんと守ってあげるのがジェダイ・ナイトのおもてなし)。そんな人たちのパスワードを「万が一のデータ漏れ」から守るには、パスワードをそのままデータベースにしまうのではなく、SHA1などの一方向関数を使ってハッシュ化してからデータベースに格納しておくべき。そうすれば、なんらかの理由(ハックされる、マシンが盗まれる、社員が暴走するなど)で「データ漏れ」が起こってしまった場合にも、被害をそのサービス内だけにとどめることができる。

 という意味では、元々のWSSEのスペックを少し拡張し、passwordをサーバーに送る際には、サービス独自のハッシュをかけたもの(hashedPassword)をcreationDateとNonceとくっつけてからさらにハッシュをかけてからサーバーに送り、サーバー側では生のpasswordではなく、hashedPasswordををデータベースにしまっておき、それを利用して認証するようにすれば良いと思うんだがどうだろう。

 もう少し分かりやすく言うと、

 base64(SHA1(password + creationDate + Nonce))

を送るのではなく、

 base64(SHA1(SHA1(password+"hatena") + creationDate + Nonce))

を送り、サーバー側ではデータベースにしまっておいたhashedPasswordを使って、

 base64(SHA1(hashedPassword + creationDate + Nonce))

を計算して比較することにすれば良いというのが私の提案である。

 WSSEの存在を知ったばかりの私が言うので、何か大きな勘違いをしているかも知れないが、こうやって文章にして公開することにより、より理解を深めようと言ういつもの作戦だ。

 それにしても、暗号の話はこんなふうに一筋縄で行かないところがとても面白い。全体としてどんな技術が何のために作られているかを理解するにはサイモン・シンの暗号解読がおすすめだ。


建物と違って、一見簡単に修正が利きそうなのがソフトウェアの問題点かな、と

 これを読んで、「SIerの仕事って『工事』だったのかあ」と思った人は私だけではないはず。

これまでSIerは、工事進行基準ではなく、開発終了時に売り上げと原価を一括計上できる「工事完成基準」を取るケースが多かった。一般的に日本のシステム開発は要件定義やユーザー企業との契約が明確でなく、開発中の手戻りや期間の超過が多い...【デスマーチがなくなる? IT業界に義務付け「工事進行基準」ってなんだ − @ITより引用】

 さらに「工事進行基準」と「工事完成基準」の定義を読むとますますそう思える。

工事進行基準
 長期請負工事契約に関する会計上の収益認識基準の1つ。工事期間中、目的物が完成に近づくにつれて徐々に収益が発生するものと考え、工事の完成度合いに応じて工事に関する収益と原価を計上し、各会計期間に分配する方法である。“発生主義”に基づく収益認識法とされる。【工事進行基準 − @IT情報マネジメント用語事典より引用】

工事完成基準
 長期請負工事契約に関する会計上の収益認識基準の1つ。工事が完成し、引き渡しを完了した時点でその工事に係る工事収益を認識し、当該会計期に一括して計上する方法のこと。【工事完成基準 − @IT情報マネジメント用語事典より引用】

 ちなみに、私はちょうど家を建てているところだが、必ずしも私が図面から想定した通りに建つとは限らないのが難しい。まあ、私がちゃんと図面を読みこなせていないのも悪いのだが、「あ、ここ思ったのと違うんで少し変えてくれませんか」と頼むと、「できるけど、やり直しになるからお金かかるよ」と言われるので我慢をしたりしている。

 まあ、建物だから「やり直すと高くつく」というのは直感的に分かるのだが、ソフトウェアの場合は、(顧客から見て)一見簡単に修正が効きそうなのがこの「開発中の手戻りや期間の超過」に結びつくのかな、と。