パスワードに「コア」となる文字列を設定する管理策について

このほど、IPA（独立行政法人情報処理推進機構）が「安心相談窓口だより」の第16-10-355号（掲載日：2016年8月3日）として、「不正ログイン被害の原因となるパスワードの使い回しはNG ～ちょっとした工夫でパスワードの使い回しを回避～」（以下、「当文書」）という文書を公開しています。ここ数年のオンラインサービスで起きている大規模な情報漏洩では、異なるサービスについて同じパスワードを設定している人が多数いるため、一つのサービスから情報が漏洩すると他のオンラインサービスでもアカウントを攻撃者に奪われてしまったり、なりすましによって色々な被害が起きていると報告されています。そうした被害を防ぐ一つの対策として、「パスワードを使い回してはいけない」というスローガンが叫ばれるようになりました。

しかし、当文書で推奨されているパスワードの生成・管理・運用の方法は、僕が見たところでは推奨しかねるものと言えます。まず、最も重大な誤りと言える点は、色々なサービスで使う各々のパスワードとなる文字列に、「コアパスワード」という共通の文字列を設定せよと推奨していることです。これは、端的に言って「パスワードの使い回し」は駄目でも「コアパスワードの使い回し」は良いという、筋の通らない発想です。ここには、利便性、あるいはパスワード運用のわかりやすさといった指標との妥協を見て取れるため、事情として分からなくもないと言えるかもしれませんが、果たしてそういう指標はどれほど譲歩して妥協するべき正当な指標なのでしょうか。もし妥協することなく理想的な指標の方（たとえば暗号学的な強さ）を優先してパスワードを生成したり運用したところでさほど複雑でも面倒でもない方法があれば、それを推奨することも一つの提案として有効な筈です。

コアパスワードを設定して複数のパスワードを生成する手順は、次のとおりです。

1. 自分の趣味や興味のあることなどから決めた短いフレーズを基に、任意の変換ルールを適用して、憶えやすく、強度の高いパスワード（コアパスワード）を作成します。
2. サービス名の略称や頭文字、URLの一部などから、サービス毎に任意の短い文字列を決めます。これをサービス毎の識別子として、コアパスワードの前または後に追加します。

まず第一段階では、パスワードを使う当人の興味、例えば僕ならペリカンの万年筆が好きなので “pelikan” というフレーズをもとにして、あらかじめ決めておいた変換ルール（例えば最初と最後を大文字にしたり、“i” を “1” へ換える）によって、“Pel1kaN” とし、これに記号と適当な数字を繋げて “Pel1kaN&!2016” などとしたものが「コアパスワード」です。

ただちに指摘できることですが、自分の興味あることがらから決めたフレーズや数値をパスワード文字列の素にするのは、攻撃者が当人の趣味や関心を何らかの情報源から知っている場合には、パスワード文字列を推定するための仮定が当人と攻撃者とで（一致とまではいかなくても推定するには十分なほど）近似することとなり、パスワード文字列を短時間で推定されるリスクが高まります。ATM などの暗証番号を設定するときに生年月日や電話番号や学生番号の一部を使って設定しないように注意されるのはなぜかということを、IPA の方は本当に理解されているのでしょうか。

次に、強いパスワードを作るためと称して推奨されている「変換ルール」というものが、攻撃者に短時間でパスワードを推定されてしまうリスクを引き上げるという点を指摘できるでしょう。なぜなら、パスワードを生成するために「決まったルール」を使うということは、パスワードとして生成されうる文字列のバリエーションを逆に狭めてしまうことになるからです。アルファベットと形状のよく似た数字とを置き換えるというルールは「単表式換字暗号」という古典的な暗号化の方式に分類され、単純な変換ルールであれば、現代の計算機リソースを使わなくても暗号学的には暗号としての強度など話になりません。

そして第二段階では、利用するサービスごとに異なる「識別子」としての文字列を設定して、コアパスワードの前後に追加します。Facebook = “fb” とか Google+ = “gp” といった文字列を、さきほどのコアパスワードの前後に追加して、Facebook 用のパスワードなら “fbPel1kaN&!2016” となるわけです。

しかし、ここでも指摘できることとして、やはり単調な「ルール」を設定してしまうと、逆にそのルールを全てのパスワードの生成について当てはめることが、攻撃者からパスワードを短時間で推定されてしまうリスクを引き上げてしまうと言えるでしょう。この場合は、サービスごとに異なる文字列を単一に設定する（つまり Facebook を表す文字列のバリエーションが一つだけしかないということです）というルールと、その文字列をコアパスワードの前あるいは後ろに連結するというルールが、どちらも単調であればあるほど、攻撃者の推定を逆に助けてしまうことになります。Facebook のパスワード（“fbPel1kaN&!2016”）が攻撃者に漏れた場合、Google+ へ “gpPel1kaN&!2016” や “Pel1kaN&!2016gp” や “ggPel1kaN&!2016” といった文字列でログインを試してみるのは、何も高度な技術や知識をもつ攻撃者でなくてもやることでしょう。

僕には IPA の当文書には幾つかの仮定があり、そしてそうした仮定には正当性がないと言えるものが含まれていると考えます。まず、当文書には「パスワードは記憶するものである」（何かの媒体に記録してはいけないものである）という仮定があるのではないでしょうか。しかし、いまや多数の人々がパスワードの管理ソフトやオンラインの管理サービスを利用しています。そして昔から大多数の人は（自分のパソコンへのログインパスワードや銀行 ATM の暗証番号などを除いて）パスワードをメモ帳や付箋などに記録しています。そして、条件によっては全く問題がないと言えます（一人暮らしの部屋であれば、パスワードを付箋に書いてモニターや机に貼っておいても重大な脆弱性とは言えません。もちろん、ウェブカメラを使っていたり、入れ代わり立ち代わり人が出入りする部屋なら別ですが）。寧ろ、パスワードを記録してはならず記憶しなければならないなどと一律に規定するからこそ、パスワードを使い回す人が増えるのではないかとも思えます。

また、当文書には「パスワードが同じ文字列でなければよい」という、パスワードの使い回しという脆弱性だけに限った対策しか考慮されていない偏りがあるように思えます。「体系」としての情報セキュリティ・ポリシーという観点を欠いた仮定だと言わざるをえません。認証情報というものは、使い回しや複雑さの低下や記録方法の不備といった数多くの脆弱性をもちうるのと同様に、攻撃手法の進展やコンピュータの解析能力の向上やソーシャルハッキングの洗練など数多くの脅威にも晒されうるので、管理・運用ポリシー全体（体系）としてのレベルを上げたり維持しなくてはなりません。単に使い回しという脆弱性レベルを下げるために他の脆弱性レベルを（どれほど脆弱になるかは考慮しないで）上げてしまったのでは、情報資産の運用ポリシーとしての意義を失ってしまいます。

以上により、或るサービスで使っているパスワードが漏洩した場合に、他のサービスへ全く同じ文字列でアクセスされてしまうような被害は防げても、パスワード文字列の一部を固有の文字列として保持したまま単調なルールで生成した一群のパスワードを使うという、ひとたびルールが推定できてしまえば使い回しと大して変わらないリスクの運用を推奨するというのは望ましくないと考えます。

もともとは認証ごと（サービスごとというだけではなく、認証手続きを踏むセッションごと）にユニークな文字列を設定することが理想なので、ワンタイムパスワードや TFA（多段階認証）のように、複合的な情報によってユニークな情報を認証情報として使うのが望ましいでしょう。ただし、ワンタイムパスワードや TFA の一つの欠点は認証を要求する本人が認証情報そのものや認証情報を生成する複雑さのレベルを設定できないという点にあります（TFA で使う認証コードの桁数や文字種を増やしたくても、本人にはどうしようもない）。したがって、本人が自分で設定できる（つまり本来の「本人確認」の根拠になる）情報はパスワード文字列だけなのですから、これを最も強く設定することが最善の対策になります。上記でも述べたように、既にパスワード管理ソフトやパスワード管理サービスが普及してきているのですから、そろそろパスワードは記憶するものではなく「安全に記録して管理するもの」という仮定への転換が必要ではないでしょうか。もちろん、パスワード管理サービスも情報漏洩の事故がたびたび起きていたり、サービス自体の脆弱性が指摘されており、なかなか安全に記録するのは難しいと言えます。しかし、記憶しなければならないがゆえにパスワードを使い回したり単純なルールで運用するくらいであれば、最初から高度に複雑なパスワードをサービスごとに設定して記録する方が、使い回しによるリスク、あるいは単純なルールでパスワードを作るというリスクで攻撃者からパスワードが推定できてしまう事態は確実に低減できます。

冒頭に戻る