Scribble at 2022-01-01 21:44:01 Last modified: 2022-01-01 21:48:24

どうやら続報によって最悪の事態は想定しなくてもいいらしいが、これは問題の始まりあるいは一端にすぎないと思う。

僕は恐らく LastPass というサービスが登場するよりも前から（これのリリースが2008年なので、つまりは15年近く前から）、オンライン・サービスとして credentials（認証情報）を一括管理するなどというアイデアは情報セキュリティの観点から言ってクレイジーだとしか言いようがないと明言してきたし、社内でも同じことを吹聴して、パスワードをクラウド・サービスなどに登録して管理するのはやめようと言ってきた。

その理由は簡単である。僕らがリモートのストレージに対して〈元に戻せるデータ〉としてパスワードを LastPass のような管理サービスへ登録するということは（元に戻せなければ、パスワード管理サービスを利用してパスワードを活用できない）、要するに攻撃者も攻撃が成功すればパスワードを復元できてしまうからだ。そして、この手のサービスにパスワードを一括で登録していれば、攻撃が成功するといっぺんに全てのパスワードを奪われる恐れがある。

他のオンライン・サービスでユーザがパスワードを登録する場合、設計者やプログラマが馬鹿でもない限り、「ハッシュ化」という処理を加えて、復元できないようにデータを変換してデータベースに保存するのが常識だ。たとえば、あなたが Google にログインするパスワードを "tokyoTokkyoKyokakyoku2023" などと登録すれば、Google の認証システムはハッシュ関数という一方通行の（つまり「ハッシュ」と呼ばれる文字列に変換するけれど、その文字列から元のパスワードに戻すことができない）処理を加える。よく使われる Blowfish というハッシュ関数（PHP の password_hash() 関数で採用されていたりする）を使えば、このパスワードは、"$2y$10$eGJQw2ln.w.oUMvxhOmHD.BBH6dnfke0d647qAyWz.Z.PQ92FUHv2" という文字列（ハッシュ値）に変換される。そして、たとえ Blowfish の変換処理について数学的な基礎まで含めて熟知している人がいたとしても、その人物にハッシュ値から元のパスワードを復元することは（現実的な時間内では）できないので、一定の実用レベルの安全性が保証される。

しかし、LastPass では登録したパスワードを復元できなくてはならない。登録してあるパスワードが何だったのか、ユーザがサービスの画面で確認できなければ意味がないからだ。しかし、それはつまりパスワードをハッシュ化していないということでもある。もちろん、データを暗号化するときには、元のデータを復元できるような処理もあって、多くの人が「暗号化」と呼ぶときは、寧ろ復元できるような処理を指していることが多いかもしれない。しかし、もちろん暗号というものが考案されてから長い歴史を通じて、復元できる情報は敵にも復元される危険性がある。復元するための別の情報が正しく保護されていなければ、いくらドアに鍵をかけても鍵を奪われたらドアを開けられてしまうのと話は同じである。しかも、LastPass の場合は同じ鍵（暗号化と復元に使う「秘密鍵」と呼ばれる情報）でいくつものドアを開けてしまう。そして、本来は、そういう鍵の管理は秘め事の当事者である僕ら自身が管理するのが最善の筈だが、LastPass という他人に、しかもどう管理しているのかが分からない（これがバレても困るだろう）状態で任せているのだから、これが危険でないわけがない。

このような情報は、利用する僕ら自身が自らの責任で管理するべきだし、それが結局はいちばん安全である可能性が高く、そして何かが起きて情報が失われたり奪われても、その責任は自分自身にあるという点でも納得がゆくだろう。他人に任せるなどという手抜きをしておいて、たかが月額で数百円を払ったていどで事故が起きた時に顔を真っ赤にして「責任」がどうの「詫び石」がどうのと騒ぐのは、はっきり言って情報通信ネットワークやコンピュータを扱う資格がない人間の類であろう。