LinkedIn情報漏洩から学ぶ、パスワード保存の本質と漏洩前提の備え

「パスワードってハッシュ化してあれば、流出しても安全なんじゃないの？」
「LinkedInほどの大企業が、なぜそんなに脆い保存方式を選んでいたの？」

チップス

ボス、LinkedInの情報漏洩って、ニュースで何度も聞いた気がするでしゅ。
でも、ハッシュ化されてたなら平気だったんじゃないでしゅか？

ボス

そこが今回の本題だな。
2012年に発覚したLinkedInの流出は、ハッシュ化していたからこそ油断を招いた事件でもある。
SHA-1でソルトなし。
当時の常識からしても、十分に脆い設計だったんだ。

2012年6月、LinkedInのパスワードハッシュ約650万件がロシアの犯罪フォーラムに公開されました。
当初の被害規模はそれだけかと思われましたが、4年後の2016年に1億1,700万件規模であったことが判明します。
ハッシュ化されていたはずの情報が、なぜ短時間で危険にさらされたのか。
本記事は、この事件を通じてパスワード保存の本質と漏洩前提の防御設計を整理します。

本記事を最後まで読めば、SHA-1ソルトなしの設計が抱えていた問題と、現代の標準である鍵導出関数の使いどころが整理できます。
運用中のサービスのパスワード保存設計を、自信を持って見直す指針になるはずです。

2012年LinkedInで何が起きたのか

事件は、ロシア語フォーラムへの一件の書き込みから始まりました。
発覚から本当の被害規模が確定するまでに、約4年もの時間がかかったのが特徴です。

650万件のハッシュ流出から始まった事件の発覚

最初に表に出た数字は、約650万件のSHA-1ハッシュでした。
2012年6月5日、ロシア語の犯罪フォーラム「InsidePro.com」のスレッドに、解読を呼びかける形でアップロードされたのが始まりです。
セキュリティ研究者が即座に気づき、報道機関を通じてLinkedIn側に通報されました。

LinkedInは同日中に侵入の事実を確認し、6月6日に公式に流出を認めます。
ただし、当時の公式声明には件数の明示はなく、影響範囲もはっきり示されないままでした。
事件の経緯を時系列で整理します。

注意したいのは、流出した650万件が「重複を除いたユニークなハッシュ」の数だった点です。
実際にはもっと多くのアカウントが影響を受けている可能性が、当時から専門家に指摘されていました。
しかし、LinkedInは対象を狭く見積もって対応を進めてしまいます。

チップス

650万件でも十分多いでしゅ…！
当時のLinkedInって、登録者どれくらいいたんでしゅか？

ボス

2012年時点で約1億6,000万ユーザーだ。
650万という数字は、その時点では「ごく一部の被害」と説明されていた。
だが結論からいえば、これは事件の氷山の一角にすぎなかった。

4年後に判明した実際の被害規模1億1,700万件

事件の全貌が見えたのは、4年後の2016年5月でした。
「Peace」と名乗るハッカーが、ダークウェブのマーケットプレイス「The Real Deal」で1億1,700万件のLinkedInアカウント情報を販売したのです。
価格はビットコイン5枚、当時のレートで約2,200ドル相当でした。

販売されたデータには、メールアドレスとSHA-1ハッシュ化されたパスワードがセットで含まれていました。
2012年時点で流出した範囲は、研究者の追加調査によってより広範囲だったことが裏付けられた格好です。
判明した被害の概要を整理します。

LinkedInは2016年5月18日、改めて影響を受ける可能性のあるアカウントすべてに強制パスワードリセットを実施しました。
4年越しの後追い対応です。
2012年時点で「徹底的な調査」を行わなかったツケが、ここで一気に表面化することになります。

チップス

4年経ってから「もっといっぱい流出してました」って…
遅すぎるでしゅ！

ボス

ふふふ、お前の感覚は正しい。
2012年の段階で全件強制リセットを行っていれば、この後の二次被害は大幅に減らせていた。
調査範囲を狭く取りすぎたのが、後の傷を深くしたわけだ。
インシデント対応で、初動の見立てがいかに重要かを示している。

なぜパスワードハッシュが短時間で解読されたのか

公開されたハッシュは、わずか1日で大半が解読されたと報告されています。
「ハッシュ化＝安全」という常識が、根本から覆された瞬間でした。

SHA-1の高速ハッシュとレインボーテーブル攻撃の関係

SHA-1はもともと、データの改ざん検知のために設計された暗号学的ハッシュ関数です。
高速に大量のデータを処理できる点が強みですが、これがパスワード保存では裏目に出ます。
攻撃者にとっては、辞書攻撃やレインボーテーブル攻撃を高速に回せる関数になってしまうのです。

当時のGPUを使った場合の試行速度のイメージを、簡単な表で示します。

つまりSHA-1のハッシュは、攻撃者から見れば「逆引きのコストが極めて低い」関数なのです。
2012年6月8日には、流出した650万件のうち約60%が解読されたとの報告も出ています。
解読というよりも、突き合わせ作業に近い速度だったわけです。

チップス

ハッシュ化しても、こんなにあっさり解読されちゃうんでしゅか…
じゃあパスワードって、どうやって守ればいいんでしゅか？

ボス

いい質問だ。
パスワード保存に「速い」ハッシュ関数を使ってはいけない。
むしろ、わざと「遅く」する仕組みが必要だ。
このあと話す鍵導出関数の出番だな。

ソルトなし設計が引き起こした集団的脆弱性

LinkedInのもうひとつの致命的な失敗が、「ソルト」を使っていなかった点です。
ソルトとは、ユーザーごとに固有のランダム値をパスワードに連結してからハッシュ化する仕組みを指します。
これがあるかないかで、攻撃者にかかるコストは何桁も変わります。

ソルトなし設計が引き起こした問題を整理します。

ソルトを正しく実装していれば、たとえ流出してもひとりひとりに対して個別の攻撃が必要になります。
1億1,700万件すべてに対し、個別計算を強いる設計になっていれば、攻撃者の経済合理性は大きく崩れていたはずです。
「攻撃にかかるコストを上げる」ことが、現代の暗号設計の基本になっています。

チップス

つまり同じパスワード使ってる人は、まとめてやられちゃったってことでしゅか…！

ボス

そういうことだ。
当時の調査では、「123456」「password」「linkedin」のような単純なパスワードは数秒で全件特定された。
ユーザーがパスワードを使い回していれば、被害は他サービスにそのまま波及する。
これが次の話に繋がる、二次被害の温床だ。

流出が招いた二次被害と社会的責任

パスワードハッシュの流出は、LinkedIn単独の問題にとどまりませんでした。
解読されたパスワードは数年にわたり、他サービスへの侵入手段として使われ続けたのです。

パスワードリスト攻撃で広がった他サービスへの被害

流出データが活用された代表的な攻撃手法が、「パスワードリスト攻撃（クレデンシャルスタッフィング）」です。
あるサービスから漏れたメールアドレスとパスワードの組み合わせを、別のサービスでそのまま試す手口を指します。

2016年以降に報告された二次被害の例を見てみます。

引用元：WIRED – Mark Zuckerberg Finally Gets Hacked—On Twitter and LinkedIn

技術コミュニティのトップ層であっても、パスワードの使い回しが深刻なリスクになると示した事例ばかりです。
LinkedInの流出データは攻撃者にとって、「使い回しユーザーを炙り出す踏み台」として4年以上活用され続けました。

チップス

ザッカーバーグもパスワード使い回してたんでしゅか！？
「dadada」って…
オイラの方がまだマシでしゅよ…！

ボス

ふふふ、誰でもやってしまう失敗だな。
「あの天才がそんな初歩的ミスを」と思うだろうが、人間の記憶には限界がある。
使い回しを防ぐにはパスワードマネージャーが必須だ。
一般ユーザーから経営者まで、例外なく適用される話だぞ。

集団訴訟と規制当局の動き

事件発覚の直後から、LinkedInには法的責任を問う動きが集中しました。
米国カリフォルニア州ではプレミアム会員から集団訴訟が提起され、最終的に125万ドルの和解金で決着しています。

訴訟と規制対応の主な動きを整理します。

LinkedInが支払った125万ドルという金額は、当時としても突出した数字ではありませんでした。
しかし、これがGDPR時代に発生していれば、年間売上の4%という上限のもとで桁違いの罰金が科されていた可能性が高い事件です。
規制環境の変化を象徴する境界線上に位置する事件、ともいえます。

チップス

今なら罰金がもっと跳ね上がってたかもしれないんでしゅね…！

ボス

そういうことだ。
個人情報保護の規制は、世界的に厳しくなる一方だ。
「漏らしたら経営が傾く」レベルにコストが上がっている。
セキュリティ投資はもはや「コスト」ではなく、経営判断の中核に位置づけられている。

セキュリティエンジニアが受け取るべき教訓

LinkedIn事件の本質は、パスワード保存の設計と、漏洩を前提とした多層防御の不在にあります。
現代のサービス設計に直結する原則を、ふたつの軸で整理します。

パスワード保存はハッシュではなく鍵導出関数（KDF）で行う

パスワード保存の現代的なベストプラクティスは、「単純なハッシュ関数を使わない」ことから始まります。
使うべきなのは、わざと計算を遅くする「鍵導出関数（Key Derivation Function、KDF）」と呼ばれる仕組みです。
代表例にはbcrypt、scrypt、Argon2があります。

現場で守るべき設計原則を整理します。

NIST SP 800-63B（米国国立標準技術研究所のデジタル本人確認ガイドライン）は、メモリハード関数であるArgon2の利用を推奨しています。
OWASPのPassword Storage Cheat Sheetも同様で、bcryptもしくはArgon2idを第一選択肢として案内しています。
引用元：OWASP – Password Storage Cheat Sheet

「ハッシュ化していれば安心」という認識は、もはや過去の常識です。
2012年のLinkedIn事件から十数年が経った今、設計の前提が大きくアップデートされています。
古い実装のまま運用しているサービスは、現代の攻撃者から見れば格好の的になります。

チップス

bcryptとかArgon2って、名前は聞いたことあるんでしゅけど、ちゃんと使えてるか不安でしゅ…

ボス

多くの現場が、レガシーシステムでSHA-1やSHA-256をそのまま使い続けている。
パスワードの保存方式を今すぐ確認しろ。
「ソルトなしのハッシュ」が残っているなら、それはLinkedInと同じ時限爆弾を抱えていることになる。

漏洩を前提とした多層防御と利用者側の備え

もうひとつの教訓は、「漏洩はいずれ起きる」という前提に立った設計です。
サーバー側の対策に加え、ユーザー側の認証要素にも厚みを持たせることで、流出時のダメージを抑え込めます。

現代のサービス運用で組み込むべき多層防御の要素を、ステップごとに見ていきます。

「Have I Been Pwned」は、自分のメールアドレスが過去の流出データに含まれているかを照合できる無料サービスです。
LinkedInの1億1,700万件のデータも、ここで照合できます。
運営者のTroy Hunt氏は、企業向けにもAPIを提供しており、新規登録時のパスワードチェックに活用が広がっています。
引用元：Have I Been Pwned

サービス側だけで攻撃を止め切ることはできません。
ユーザーが使い回したパスワードは、技術的にどう保存しても、他サービスから流出すれば突破されてしまいます。
多要素認証やパスワードレス認証への移行は、もはや差別化要因ではなく、最低限の備えになっています。

チップス

多要素認証、社内システムでも使ってるんでしゅけど、たまに「面倒だな」って思っちゃうでしゅ…

ボス

その「面倒」が、攻撃者には大きな壁になる。
パスワードが流出しても、もう1段の認証要素があれば99%以上の不正アクセスは止められるとされている。
面倒さに価値がある仕組みだ。
意味を理解した上で使えば、見方が変わるはずだぞ。

まとめ

2012年のLinkedIn情報漏洩は、当初は650万件と発表されたものの、4年後に1億1,700万件規模であったと判明した事件でした。
SHA-1という高速なハッシュ関数を、ソルトなしで使っていた設計が、攻撃者に大きな抜け道を残していたのです。
事件の影響は他サービスへのパスワードリスト攻撃に長く尾を引き、世界中のSNSや企業アカウントが二次被害を受けました。

LinkedInが負担した直接的な和解金は125万ドル程度でしたが、ブランドへの長期的影響と業界全体に与えたインパクトは桁違いに大きい事件です。
パスワード保存の常識は「ハッシュ化していれば安全」から「鍵導出関数とソルトと多要素認証の組み合わせが前提」へと書き換わりました。
2012年の事件は、その分岐点に位置するものです。

セキュリティエンジニアとして、この事件から受け取るべき教訓はシンプルです。
パスワードはbcryptやArgon2を使い、ユーザーごとのソルトと十分なストレッチングで守る。
多要素認証を標準にし、既知漏洩データベースとの照合を組み込む。
そして、流出が起きた瞬間に動ける運用と訓練を整えておく。
2012年のLinkedIn事件は、これらの基本があるかないかで被害規模が文字通り桁違いになることを、強烈に示してくれた事件です。

チップス

ボス、オイラのLinkedInアカウント、まだ古いパスワードのままかもしれないでしゅ…！
家に帰ったら、すぐに変えるでしゅ！

ボス

ふふふ、いい心がけだ。
ついでにパスワードマネージャーを導入しろ。
長く複雑でランダムなパスワードを、サービスごとにすべて変える。
これがユーザー側でできる、もっとも費用対効果の高いセキュリティ対策だ。

セキュリティの専門知識を活かして活躍したい方は、セキュリティフリーランス案件もぜひチェックしてみてください。