漏れても「復元できない」パスワード|ハッシュ化とソルトの仕組み

情報漏えいのニュースで「パスワードは復元できない形式で保管」という一文を見て、本当に安全なのか気になったことはありませんか。仕組みがわからないと、先輩に聞くのも少し気が引けますよね。

この記事では、その一文の正体であるハッシュ化とソルトのしくみがわかります。結論から言うと、漏れても元に戻しにくいが、弱いパスワードや使い回しは守りきれないというのが正確な理解です。

目次

「パスワードは復元できない形式」とは?タイムズカーの発表から

この言葉は、パーク24が2026年9月28日に公表した、タイムズカーの不正アクセスに関する第2報に出てきます。

発表によると、9月25日に不正アクセスを検知し、翌26日の午前7時25分までに侵入経路の遮断を完了しています。漏えいの対象は、会員に加えて退会済みの人や入会手続きが完了していない人なども含む、約660万件です。

  • 氏名・住所・生年月日・電話番号・メールアドレス(法人会員は所属部署名も)
  • 運転免許情報と本人確認書類の情報(運転免許証の画像など)
  • パスワードと、連携サービスのID

そのうえで同社は、パスワードは「復元できない形式」で保管しており、その情報を使ってアカウントが不正に利用される恐れはないと説明しています。クレジットカード情報は漏えいしていないことも確認したとしています。

具体的な方式は公表されていません。ただ、元に戻せない形でパスワードを保管する方法としては、ハッシュ化と呼ばれる技術が一般的です。

パスワードのハッシュ化とは?ミキサーにかけた果物のたとえ

ハッシュ化とは、パスワードを決まった計算で別の文字列に変え、元に戻せない形で保存することです。暗号化と違い、鍵を使って戻す前提がありません。

たとえるなら、果物をミキサーにかけてジュースにするイメージです。同じ果物からは毎回同じ味のジュースができますが、ジュースから元のリンゴを取り出すことはできません。

ログインのときは、入力されたパスワードも同じ計算にかけます。できた文字列が保存済みのものと一致すれば、本人だと判断するわけです。

つまりサービス側は、あなたのパスワードそのものを持っていません。だからこそ、データが盗まれても「中身はすぐには読めない」と言えるのです。

ソルトとストレッチングでパスワードハッシュを強くする

ただし、ハッシュ化だけでは不十分です。攻撃者は、よく使われるパスワードのハッシュ値を事前に大量に計算した表を持っているからです。

たとえば「password123」のハッシュ値は、同じ方式で計算する限り、どのサービスでも同じになります。表と照らし合わせれば、弱いパスワードは一瞬で見抜かれてしまいます。

そこで使われるのが、次の2つの工夫です。

  • ソルト:ユーザーごとに違うランダムな文字列を混ぜてから計算する。同じパスワードでも結果がバラバラになり、事前の表が使えなくなる
  • ストレッチング:計算をわざと何千回もくり返し、1回の試行を重くする。総当たりにかかる時間が大きく延びる

ジュースのたとえなら、人ごとに違う隠し味を入れ、さらに何度もミキサーを回すイメージです。bcryptやArgon2といったパスワード保管用の方式は、この2つを最初から備えています。セキュリティの指針をまとめたOWASPの資料でも、Argon2idを第一候補に挙げています。

ハッシュ化だけだと同じパスワードは同じ値になり事前の表で見抜かれるのに対し、人ごとのソルトを混ぜて計算を何度もくり返すと人ごとに違う値になり総当たりも重くなることを示した図
図: ハッシュ化だけの保存と、ソルト+ストレッチングの違い(筆者作成)

パスワードがハッシュ化されていても変えるべき3つの理由

ハッシュ化されていても、心当たりがあればパスワードは変えておくのが安全です。守りは「時間を稼ぐ」ものであって、絶対ではないからです。

  1. 短い・よくあるパスワードは、時間をかければ総当たりで当てられる
  2. 同じパスワードを他のサービスで使い回していると、そこが狙われる
  3. 漏れた氏名やメールアドレスを使った、なりすましメールが届きやすくなる

同社は、今回の情報でアカウントが不正に利用される恐れはないと説明しています。1つ目と2つ目は、あくまで一般論としての備えです。

特に3つ目は、パスワードとは関係なく起こります。同社も、当社を装ったメール・SMS・電話に注意し、身に覚えのない連絡のリンクや添付ファイルを開いたり、パスワードや認証コードを入力したりしないよう呼びかけています。

パスワード以外の本人確認の弱点は、SMS認証が弱いと言われる理由とパスキーの記事でも解説しています。

筆者の考察:パスワード保管は運用チームも確かめられる

筆者は、この話は運用・インフラ担当にとっても他人事ではないと考えます。保管方式はアプリの話に見えて、実は日々の運用で確かめられる部分が多いからです。

たとえば、担当システムについて次の3点を先輩に聞いてみてください。

  • ユーザーのパスワードは、bcryptやArgon2などの専用方式で保存しているか
  • 退会したユーザーの情報は、いつ、どうやって消しているか
  • アプリやミドルウェアのログに、パスワードが平文で出ていないか

今回の件では、退会済みの人の情報も対象に含まれていました。持っていないデータは漏れないので、保管期間の設計も立派なセキュリティ対策です。

また、侵入の兆候はアクセスログにも残ります。アクセスログから侵害の兆候を見つける記事とあわせて読むと、守りの全体像がつかみやすくなります。

漏えいの報道が続く背景を統計で確かめた記事として、情報漏洩ラッシュは本当か|件数は横ばいで規模が倍増した統計もあわせて読んでみてください。

まとめ:パスワードのハッシュ化は「時間稼ぎ」と理解する

  • 「復元できない形式」とは、元に戻せない計算で変換するハッシュ化のこと
  • ソルトとストレッチングを組み合わせると、事前の表や総当たりに強くなる
  • それでも弱いパスワードや使い回しは守りきれないので、心当たりがあれば変更する

まずは担当システムのパスワード保存方式を、先輩に1つ質問して確かめてみましょう。

参考リンク

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

この記事を書いた人

インフラの運用・構築に10年以上携わり、AWS 認定8資格を持つ運営者です。いまは Claude Code などの AI ツールを日々の作業の自動化に使いながら、これから使う人のための教科書サイトを運営しています。

コメント

コメント一覧 (4件)

コメントする

目次