パスワードマネジャーのパスワードは、どうやって管理すればいいの？：こうしす！ こちら京姫鉄道 広報部システム課 ＠IT支線（41）

情報セキュリティの啓発を目指した、技術系コメディー自主制作アニメ「こうしす！」の＠ITバージョン。第41列車は「漏えいとパスワードの使い回し」です。※このマンガはフィクションです。

[原作：井二かける（OPAP-JP）, 解説：京姫鉄道，＠IT]

「こうしす！」とは

ここは姫路と京都を結ぶ中堅私鉄、京姫鉄道株式会社。

その情報システム（鉄道システムを除く）の管理を一手に引き受ける広報部システム課は、いつもセキュリティトラブルにてんてこ舞い。うわーん、アカネちゃーん。

「こうしす！＠IT支線」とは

「こうしす！」制作参加スタッフが、＠IT読者にお届けするセキュリティ啓発4コマ漫画。

今回の登場人物

祝園アカネ（HOSONO Akane）

広報部システム課　係員。情報処理安全確保支援士。計画的怠惰主義者で、有休取得率は100％。しかし、困っている人を放っておけない性格が災いし、いつもシステムトラブルに巻き込まれる

英賀保芽依（AGAHO Mei）

広報部広報課係員。天才的トラブルメーカーで、システム課やシステム子会社からは「アルティメットバグトリガー」として知られる。アカネの同期

第41列車：会社のパスワードは使い回していないよ！

※Live2Dモデル：Live2D 高嶋るみあ、背景3D：OPAP-JP contributors

井二かけるの追い解説

　マンガのテーマは、「漏えいとパスワードの使い回し」です。

　GMWが運営する「pictBLand」「pictSQUARE」で発生した不正アクセスにより、データベースの内容が漏えいするというインシデントが話題となりました。

　最新の発表では、「メールアドレス」「銀行口座」「電話番号」「住所情報」が漏えいしたとされている他、当初の発表では「パスワード」も漏えいした可能性があるとしていました。

参考記事

不正アクセス受けたBL特化SNS「ピクブラ」、9月21日にサービス再開へ　「考えうる対策を全て施した」（ITmedia NEWS）

　公式発表では技術的な詳細が明かされていないため、正確にはどのようなことが起きたかは不明ですが、「ソルトなしのMD5パスワードハッシュが漏えいした結果、総当たり法で解読されたのではないか」「X（Twitter）のトークンが漏えいしたのではないか」と指摘する声もあります。

　同社のサービスが同人活動で広く活用されていたことから、同じく同人系や創作系のサービスを提供する他社でも、ユーザーに対して「パスワードを使い回していた場合はパスワードを変更する」ように案内するなど対応に追われました。

自衛策1 パスワードを使い回さない

　利用者の立場で自衛のために大切なのは、まず「普段からパスワードを使い回さない」こと、そして「できる限り長いパスワードを使用する」ことです。

　「大文字」「小文字」「数字」「記号」などの「複数種類の文字種を織り交ぜた複雑なパスワードを使用する」ことも効果はありますが、それよりも「ランダムで長いパスワードを使用する」ことの方が重要でしょう。

　方法の一つとして、単語を用いた「パスフレーズ」があります。

参考記事

えらい立派なパスワードどすなぁ（こうしす！）

えらい立派なパスワードどすなぁ、再び（こうしす！）

　とはいえ、全てのサイトで異なるパスワードを覚えることは困難です。

　以前、アニメ「コウシス！　LITE」でコアパスワード法を紹介しました。しかしこの方式では、複数のサイトで漏えいした場合に、その規則がバレてしまうデメリットがあります。

　今回の事例は、まさに複数のサイトで情報漏えいが発生したパターンとなるため、このようなケースには効果が薄いといえるでしょう。

　推測しづらくするための工夫も考えられますが、ブラウザのパスワードマネジャー機能や単体のパスワードマネジャー製品を使用するのが、現実的な選択肢です。とはいえ、パスワードマネジャーに頼り切るのも問題があります。なぜなら以下のようなリスクが存在するからです。

• パスワードマネジャー自体に脆弱（ぜいじゃく）性がある
• パスワードマネジャーの運営者が信頼できない
• 同期に使用しているアカウントに不正アクセスされる
• マルウェアによりパスワードマネジャーの情報を盗まれる

　ブラウザ標準のパスワードマネジャーを使っていたとしても、ブラウザ自体に脆弱性が存在する可能性があります。偽ブラウザをインストールさせられていたり、インストールしている拡張機能がマルウェアであったり、ブラウザ開発元の内部不正により漏えいしたりする可能性は否定できないでしょう。

　この中でも注意が必要なのは、パスワードの同期に使用しているアカウントに不正アクセスされてしまうリスクです。

　例えば、「Google Chrome」や「Android」で使用される「Googleパスワードマネジャー」は、Googleアカウントを使用して複数端末で同期すると、Google Webサイトのアカウント管理ページでパスワードを閲覧できます。そのため、Googleアカウント名とパスワードが判明すれば、攻撃者はパスワードマネジャーに保存された全てのサイトのパスワードを知ることができるということになります。

　そのため、少なくともパスワードマネジャーのアカウントやメールアカウントだけはパスワードを使い回さないようにして、強力なパスワードを使用し、なおかつ暗記する必要があるといえるでしょう。

自衛策2 二要素認証を設定する

　加えて、設定しておきたいのが「二要素認証」です。

　例えば、仮に、パスワードマネジャー自体の脆弱性、信頼性の問題、あるいはアカウント乗っ取りなどによりパスワードが漏えいしてしまうリスクを想定すると、最後のとりでとなるのは二要素認証です。

　もし利用しているサービスで二要素認証を設定できるなら、設定しておきましょう。

　ただ、二要素認証に用いている携帯電話やハードウェアトークンを滅失してしまうと、自分でもログインできなくなってしまうことがあります。

　SMS認証の場合は、携帯電話を解約する際に特に留意が必要です。

　SMS認証には他にもSIMスワップなどのリスクが指摘されているため、もし選択可能であるならば、SMSを使用した二要素認証よりは、TOTP（Time-based One-Time Password）やパスキー（WebAuthn）を用いた二要素認証を選択する方が安心でしょう。そして、複数の認証手段を登録しておく、バックアップコードを安全な場所に保管しておくことも重要です。

自衛策3 パスワードマネジャーに同期パスフレーズを設定する

　例えば、Googleパスワードマネジャーには、同期パスフレーズを設定する機能があります。

　これは、パスワードマネジャーなどの同期データをGoogleに送信する前にクライアントサイドで暗号化するというものです。この機能を有効にすることで、パスワードマネジャーに保存したパスワードをGoogleのサイト上で閲覧できなくなります。

　さらに、仮にGoogleのパスワードが漏えいしたとしても、パスワードマネジャーの情報は暗号化されているため、攻撃者はパスワードマネジャーの情報を閲覧するために暗号を解読しなければならなくなります。もちろん、同期パスフレーズが弱いパスワードであれば一瞬で解読されてしまうリスクがありますから、それなりに強いパスワードを設定する必要がありますが、安全性は増すといえるでしょう。

自衛策4 セキュリティトークンやパスキーを使用したパスワードレス認証を使用する

　近年では、セキュリティトークンやパスキーを使用したパスワードレス認証に対応しているサイトが増えてきました。こうした機能を活用して、そもそもパスワードを使用しないというのも一つの選択肢といえるでしょう。

番外編 毎回パスワードを再設定する

　ジョークの文脈で語られるセキュリティ対策ではありますが、ログインの度にパスワード再設定の手続きをする前提で、使い捨てのランダムなパスワードを設定して、すぐにパスワードを忘れてしまうという方法があります。

　二要素認証が利用できないサイトで、なおかつパスワードマネジャーも使用できないという状況であれば、1つの方法としては検討できるかもしれません。

Webサービス運営者がすべきこと

　このようにユーザー側の自衛も大切ですが、そもそもこうした事態が起きないよう、Webサービスを運営する側も細心の注意を払う必要があります。

　pictBLand、pictSQUAREの事例では技術的な詳細が明らかにされていませんが、一般論として、以下の点は大切です。

• ソフトウェアは一度作れば終わりではなく、使用するライブラリやフレームワークを常にアップデートし続けていく
• 認証周りの仕組みは自作せず、ライブラリを使用するか、IDaaS（Identity as a Service）を使用する
• どのようなリスクに対してどのような対策をするのかを明確化する
• インシデントの際に、焦って復旧しない

ソフトウェアは一度作れば終わりではなく、使用するライブラリやフレームワークを常にアップデートし続けていく

　経営層は「一度思い切って投資したのだから、そのソフトウェアは末永く使いたい」と思いがちですが、むしろお金がかかるのは保守運用だということに留意しなければなりません。

　特にWebサービスとしてインターネットに露出するソフトウェアは、作ったそばから朽ちていく家のようなものです。10年も経過すれば丸ごと作り直さなければならなくなることもあります。

認証周りの仕組みは自作せず、ライブラリを使用するか、IDaaSを使用する

　認証関係の開発、運用、保守は非常に専門性が高い分野であり、餅は餅屋というのが現実です。

　その意味においては、「Auth0」や「Azure AD B2C」などのIDaaSを使用するのが現状ベスト、それが難しいのであれば、著名な認証ライブラリなどを使用するのが次善の策であるといえるでしょう。

どのようなリスクに対してどのような対策をするのかを明確化する

　時々「弊社は顧客情報を暗号化しております」とWebサイトに自慢げに記載されていたり、インシデントの際に「暗号化はしていたものの漏えいしてしまいました」と免罪符のように記載されたりしていることがありますが、その暗号化はどういったリスクに備えたものなのかは不明確です。

　例えば、PPAPのように「セキュリティ基準に『個人情報は暗号化すること』などと定められているから、取りあえず暗号化しました」というセキュリティ対策は意味がありません。「暗号化していたのに、暗号化キーを同じ場所に保存していたので、情報が漏えいしました」というのも同じことです。

　アプリケーション自体が乗っ取られてデータベースに侵入される状況では、当然暗号化キーも漏えいすることが考えられ、そうした状況の対策にはなり得ません。もしそういう状況に備えるのだとすれば、例えば「データベースに記録する顧客情報は公開鍵で暗号化し、Webサービスからは復号できないようにしつつ、独立したローカル環境で、秘密鍵で復号しながらバッチ処理をする」というような仕組みにすることが必要でしょう。

　しかし、それでもパフォーマンスや利便性の低下や、ローカル環境が攻撃されて秘密鍵が漏えいするリスクは残ります。そのため、現実的にこのような対策を行えるかどうか、行う必要性があるかどうかという点は検討しなければなりません。情報セキュリティを囓（かじ）っていれば誰でも思い付くような対策ですが、実際に採用された例を見掛けないのは、デメリットの割にメリットが薄いということなのでしょう。

　セキュリティ対策を講じるときは、「暗号化する」という結論ありきで考えるのではなく、例えば、「ストレージデバイスを処分する際に万が一盗難に遭う」「アプリケーションは無事でもデータベース単体で不正アクセスに遭う」というような具体的なリスクを特定し、それがどの程度起こることなのか、起こったらどれだけの被害を受けるのか、対策によって生じるメリットとデメリットをバランス良く検討した上で、「暗号化する」といった対策を決めるというプロセスが必要です。

インシデントの際に、焦って復旧しない

　そして、いざインシデントが発生した際、焦ってサービスを復旧させてしまうと、脆弱性や攻撃者の仕掛けたバックドアが残っていて、二次災害を招いてしまうことがあります。

　ビジネス上の都合だけを考えれば、1秒でも早く復旧することが求められるかもしれませんが、対外的に拙速に復旧見込み（目標）を公表してしまえば、その目標を達成できなかったときに利用者の期待を裏切るだけでなく、対応するエンジニアの焦りの原因にもなってしまいます。

　そのため、インシデント発生時には、冷静に「現在の状況」「現在判明している事実」「次回情報更新予定時刻」のみを発表するなど、希望的観測を含まないようにすることが望ましいというのも、pictBLand、pictSQUAREの事例の教訓といえるでしょう。

　情報セキュリティ対策において大切なことは星の数ほどありますが、何よりも、失敗に学ぶという姿勢が最も重要なことといえるかもしれません。

　pictBLand、pictSQUAREの事例は、利用者としても、運営者としても、情報セキュリティの運用を見直すきっかけとなったのではないでしょうか。

筆者プロフィール

原作：井二かける

アニメ「こうしす！」監督、脚本。情報処理安全確保支援士。プログラマーの本業の傍ら、セキュリティ普及啓発活動を行う。

著書：「こうしす！社内SE 祝園アカネの情報セキュリティ事件簿」（翔泳社）

「ハックしないで監査役!! 小説こうしす!EEシリーズ 元社内SE祝園アカネ 監査役編 [1]」（京姫鉄道出版）

dアニメストアにて、アニメ『こうしす！EE』配信中。

• Twitter：@k_ibuta

解説：京姫鉄道

「物語の力でIT、セキュリティをもっと面白く」をモットーに、作品制作を行っています。

原作：OPAP-JP contributors

オープンソースなアニメを作ろうというプロジェクト。現在はアニメ「こうしす！」を制作中。

• Twitter：@opap_jp、@kosys_pr
• 公式サイト：Open Process Animation Project Japan（OPAP-JP）
• 貢献者一覧：こうしす！/クレジット