「パスワード平文保存」が今なお繰り返される真因 徳丸浩が警告する「形だけのセキュリティ」：特集：ID・パスワードから始める「引き算」のセキュリティ（3）（1/3 ページ）

「パスワードの平文保存」や「トークンの誤公開」など、なぜ「やってはいけないこと」は繰り返されるのか。Webセキュリティの専門家・徳丸浩氏にその真因と「足し算セキュリティ」のわな、バズワードに惑わされず自組織の「真のリスク」を洗い出すためのアプローチを聞いた。

[石川俊明，＠IT]

　近年発生したランサムウェア攻撃の多くが認証情報の窃取から始まる状況を踏まえ、基礎中の基礎である認証情報（ID・パスワード）保護を基点にしたセキュリティ対策の見直しの重要性を問う本特集「ID・パスワードから始める「引き算」のセキュリティ〜ゼロトラスト狂騒曲の果てに」。初回は、「サイバー攻撃の高度化・複雑化」という決まり文句を見直し、その奥にある「複雑化のわな」を整理。続く第2回は、攻撃側と防御側の実態をよく知る専門家に、防御側が「絶対的に優位」に立てる術を聞いた。

　一方で、特集のテーマである「認証情報保護」は、社内インフラや特権アカウント管理だけの問題にとどまらない。自社サービスで預かる顧客のID・パスワードや、開発現場で扱う「APIキー」「トークン」などにも目を向ける必要がある。

　事実、昨今相次ぐ個人情報漏えい事例も、高度なランサムウェア攻撃ばかりが原因ではない。パスワードの平文保存、ソースコード内への直書き（ハードコード）、GitHubへのアクセストークン誤公開といった「基本の不備」が引き金となっているケースが後を絶たない。

　では、なぜセキュリティで「やってはいけないこと」が多くの現場で放置され、インシデントとして顕在化し、組織の信用失墜という同じ「失敗」が繰り返されているのか――Webアプリケーションセキュリティの専門家・徳丸浩氏に、その「真因」と、「引き算のセキュリティ」を始めるためのアプローチを聞いた。

「パスワード平文保存」「トークン誤公開」が今なお繰り返される真因

――開発現場や組織において、「パスワードの平文保存」や「APIトークンの誤公開」といった、セキュリティで「やってはいけないこと」といえるリスクが放置され続けている実態の背景には何があるのでしょうか。過去には2019年に発生した「宅ふぁいる便」の情報漏えいなど、パスワードの平文保存が引き金となってサービス終了にまで追い込まれ、社会的に批判を浴びた事例もあります。

EGセキュアソリューションズ 徳丸浩氏

徳丸氏　「なぜ今も繰り返されているのか」という本質的な理由は一言で片付けるのは難しいですが、歴史的ないきさつと認識のズレが背景にあると考えています。

　昔のシステム開発における仮説として、「どうせシステム内に侵入されてしまったらもうアウト（全てを奪われる）なのだから、パスワード単体にそれほど価値はない。だから平文で保存していても、侵入された後なら同じことではないか」という思い込みがあったのではないかと見ています。

　しかし、そのパスワードに大きな価値があることが、2012年頃から日本でも流行し始めた「パスワードリスト攻撃」によって明確化したのです。ユーザーが同じパスワードを複数のサービスで使い回している実態があるため、1つのWebサイトから漏えいしたパスワードが、他のサイトへの侵入口という強力な「価値」を持っているのです。

――ソースコードの管理不備（APIキーのハードコードなどクレデンシャルの誤公開）についても共通する部分がありますか。

徳丸氏　そうですね。ソースコード自体が漏えいすることは重大な事態であり、それを防ぐべきだという意識はあるはずです。しかし、ソースコードそのものを保護する意味に比べて、その中に「認証情報」がハードコードされていることの危険性に対する重み付けや重大性の認識が、まだまだ希薄なのだと感じます。言い換えれば、「さまざまな理由によって、ソースコードは外部に漏えいすることがあるのだ」という前提の意識や緊張感が足りていないのだと思います。

なぜ「基本に立ち返える」ことは難しいのか

――パスワードの平文保存のような「やってはいけないこと」を防ぐために、「パスワードは暗号化して保存する」「パスワードを忘れたらリセットURLを発行してユーザー自身に再設定を促す」といった方法論が確立されています。システムに関わるどの立場の人でもこうしたリスク・対策を認識していると思いますが、なぜ基本に立ち返ることが進まないのでしょうか。

徳丸氏　パスワードの平文保存に関しては「ユーザーサポートの都合」という、非常に根深い現実があります。

　パスワードを忘れた顧客から「自分のパスワードを教えてほしい」と問い合わせが来た際、ベストプラクティスに従って「仮パスワードを発行する」とか「再登録用のURLを送るのでご自身で変更してください」と案内しても、お客さまのITリテラシーによってはその操作自体が難しいという実態があるのです。

　そのため、サポートの効率や顧客の利便性を優先して、「平文でパスワードを保存しておき、問い合わせにそのまま答えられるようにしよう」という運用側の判断が優先されてしまうケースはいまだに存在します。

　メールでパスワードを平文で送ってくる事業者の中には、ハッシュ保存ではなく可逆暗号化で対応しているケースもあるでしょう。しかし、2022年に決済代行事業者のメタップスペイメントで発生したインシデントでは、報告書の中に「特定の顧客向けサイトでパスワードを平文表示する機能が存在した」という旨が記載されていました。

　私の見立てでは、これは表示機能だけでなく、データベース側にもパスワードを平文で保存していたのではないかと考えています。金融系で厳しい業界基準があるはずの事業者でも、利便性のためにこうした運用が残されてしまうのです。

――直近では、KDDIが提供するISP事業者向けメールシステムで起きた不正アクセスに関連して、メールの認証方式に「APOP（Authenticated Post Office Protocol）」を残していたことが話題になりました。

徳丸氏　APOPは古い「MD5ハッシュ」を使う方式で、認証の仕組み上、サーバ側でパスワードを平文で保持する必要があります。そのためハッシュ保存への移行ができません。APOPについては、IPA（情報処理推進機構）が2007年の時点で「使用を停止すべき」と注意喚起をしています。

• 参考記事：APOPにパスワード漏えいの脆弱性、IPAは「根本的な対策ない」（＠IT）

　すでに20年近くが経過しているにもかかわらず、なぜ残っていたのか。それは「やめます」と言った瞬間に、一般ユーザーから問い合わせが殺到することを恐れたからでしょう。お客さまに対して「『Microsoft Outlook』の設定を変更してください」と求めても、多くの方は「何を言っているのか分からない」と混乱し、顧客数が多いサービスであればあるほどサポート窓口がパンクしてしまいかねません。

　このように、「ユーザーからの問い合わせコストをどう抑制するか」という業務側の事情が、古い仕様を廃止する阻害要因になっているのが実情だと考えます。