パスワードのハッシュ化は、ユーザーの大切な情報を守るための基本技術です。この記事では、ハッシュ化の仕組みやアルゴリズム選び、ソルトの重要性、平文保存の危険性について詳しく解説します。安全なパスワード管理のために必要な対策を総合的に学べます。
パスワードのハッシュ化は、ユーザーのパスワードを安全に保護するための重要な技術です。アカウントのパスワードは単なる文字列のように見えますが、ウェブサイトにとっては最も機密性の高いデータのひとつです。万が一、サービスがパスワードを平文で保存していた場合、データベースが流出すると攻撃者はすぐにアカウントへアクセスできる組み合わせを手に入れてしまいます。そのため、現代のシステムではパスワードのハッシュ化という方法--つまり、パスワードそのものではなく、元に戻せないデジタル表現のみを保存する方式--が採用されています。
ユーザーが登録する際、パスワードは特定のアルゴリズム(ハッシュ関数)によってハッシュ値へと変換されます。このハッシュ値だけがデータベースに保存され、ログインの際には入力されたパスワードから再びハッシュ値を計算し、保存済みの値と比較します。一致すればパスワードが正しいと認証されます。
このプロセスにより、システムが完全に無敵になるわけではありませんが、万が一データベースが流出した場合でも攻撃者が元のパスワードを直接入手するのは困難になります。攻撃者がハッシュ値を元に推測しようとしても、しっかりと設計されたハッシュ化システムなら膨大な計算リソースが必要です。
パスワードのハッシュ化とは、元のパスワードを一定の長さの文字列に変換する処理です。たとえば「PixelBurn2026!」というパスワードも、ハッシュ化すると全く異なる文字列になり、そこから元のパスワードを推測することはできません。
ハッシュ関数は一方向性で、パスワードからハッシュ値を作るのは簡単でも、ハッシュ値から元のパスワードを逆算することはできません。この点が暗号化との大きな違いです(暗号化は鍵さえあれば復号可能ですが、ハッシュにはそのような鍵はありません)。
また、同じパスワードならば常に同じハッシュ値が得られるという予測可能性も特徴です。これにより、サイトは元のパスワードを保存せずとも認証処理が行えます。一方で、入力データが少しでも変わるとハッシュ値は全く異なるものになります。たとえば「Password123」と「Password124」では、たった1文字違いでも大きく異なるハッシュ値が生成されます。
ただし、ハッシュ値自体も絶対に安全とは言えません。攻撃者が様々なパスワード候補をハッシュ化し、その中から一致するものを探す「総当たり攻撃」が可能です。したがって、ハッシュ化そのものだけでなく、ハッシュアルゴリズムの種類や「ソルト」、計算コストの設定も重要な要素となります。
ユーザーがアカウントを作成した際、サーバーは入力されたパスワードを平文で保存せず、ハッシュ化してその値だけをデータベースに記録します。さらに、認証時には再度同じハッシュ関数で計算し直し、保存されたハッシュ値と比較します。
この仕組みにより、ユーザー登録後に運営側が元のパスワードを知る必要は一切ありません。そのため、信頼できるサイトでは「パスワードを表示する」機能は存在しないのが通常です。
パスワードを忘れた場合も、セキュアなサービスはパスワードそのものを送信するのではなく、再設定手続きを行います。本人確認が完了すると新しいパスワードを登録できる仕組みです。
このような設計は、万が一データベースが漏洩した際にも有効です。もし平文でパスワードが保存されていれば流出時にアカウントが直ちに危険に晒されますが、適切にハッシュ化されていれば攻撃者はまずパスワード候補を推測する必要があります。
もしサイトがパスワードをそのまま保存していた場合、データベースの流出はアカウントの即時危殆化を意味します。攻撃者はログイン名やメールアドレス、実際のパスワードのペアを一度に手に入れてしまいます。
さらに、多くのユーザーは同じパスワードを複数のサービスで使い回す傾向があり、1つのサイトから漏れた情報を使って他のサービスへの不正アクセスも可能になります。
このようなインシデント後の適切な対応方法については、以下のガイドで詳しく解説しています。
データ漏洩後のチェック方法とパスワードを守るためのポイント(2025年最新版)
単にハッシュ化しているだけでは不十分な場合もあります。たとえばSHA-256のようなアルゴリズムはデータ整合性の検証には適していますが、もともとパスワード保護のために設計されていません。現代のGPUなら膨大な数のハッシュ値を短時間で計算できるため、単純な・よく使われるパスワードは容易に突破される恐れがあります。
攻撃者はハッシュ関数を数学的に逆算するのではなく、一般的なパスワードや単語、日付、記号の組み合わせリスト(辞書攻撃)を使い、それぞれのハッシュ値と漏洩データを突き合わせて一致するものを探します。アルゴリズムの計算速度が速ければ速いほど、1秒間に試せる候補数も多くなってしまいます。
そのため、安全なパスワード保存には「ソルト」や計算コストの高い専用アルゴリズムなど、複数のレイヤーで保護する仕組みが必要です。
どんなに優れたハッシュアルゴリズムでも、同じパスワードが常に同じハッシュ値になるならば、その安全性は大きく損なわれます。2人のユーザーが同じパスワードを設定した場合、追加措置がなければハッシュ値も一致してしまうからです。
この問題を解決するのがソルト(salt)です。ソルトとは、パスワードにランダムな値を加えてハッシュ化することで、同じパスワードでも全く異なるハッシュ値を生成できる仕組みです。ユーザーごとに固有のソルトを生成し、これをパスワードと組み合わせてからハッシュ化します。
例えば2人のユーザーが「qwerty123」というパスワードを選んでも、それぞれ異なるソルトを加えれば最終的なハッシュ値は全く異なるものになります。攻撃者が事前に「レインボーテーブル」と呼ばれる膨大なハッシュリストを用意していた場合でも、ソルトがあれば個別に計算し直さなければならず、効率的な総当たり攻撃を防げます。
ソルト自体は秘密である必要はなく、一般的にはハッシュ値と一緒にデータベースへ保存されます。その目的は「ハッシュ値を一意にすること」であり、機密性を保つことではありません。ただし、ソルトだけでは弱いパスワードの脆弱性を完全には防げませんので、必ず高コストなハッシュアルゴリズムと組み合わせて使う必要があります。
パスワードのハッシュ化には、SHA-256やSHA-512といった高速な関数ではなく、わざと計算コストを高く設計した専用アルゴリズムが推奨されます。代表的なものとしてbcryptがあります。bcryptは計算の難易度(costパラメータ)を設定できるため、通常のログインにはほとんど影響が出ませんが、攻撃者が大量のパスワードを試すのは非常に困難になります。
さらに進化したものがArgon2です。Argon2は計算時間だけでなく、必要なメモリ量も設定できるため、GPUや専用機器による大規模な総当たり攻撃にも強い特長があります。特にパスワード保存にはArgon2idというバージョンがよく使われます。
bcryptとArgon2のどちらが優れているかという議論もありますが、bcryptも十分な設定を行えば依然として強力な防御手段です。ただし、より柔軟な設定や将来的な拡張性を考えると、最近の新規システムではArgon2idの導入が推奨される傾向にあります。
また、パラメータの設定次第で安全性は大きく変わります。あまりに低いコスト設定では、どんなに新しいアルゴリズムでも計算が速すぎて意味がなくなってしまうため、ハードウェア性能の向上に応じて定期的に見直しが必要です。
なお、パスワード自体を使わない「パスワードレス認証」も近年注目されています。パスワードレス認証やPasskeys、FIDO2、WebAuthnについては、下記の記事で詳しく解説しています。
パスワードを使わない新しい認証方式とPasskeys、FIDO2、WebAuthnの仕組み
パスワードのハッシュ化は、ユーザーのパスワードをサイトが平文で保存せず、ハッシュ値のみを管理することで安全性を高める技術です。認証時は入力パスワードから再度ハッシュ値を生成し、保存済みの値と照合します。
安全なパスワード管理は、単なるハッシュ関数だけでなく、ユニークなソルトやbcrypt・Argon2idといった高コストなアルゴリズムの活用が不可欠です。もしサービスがパスワードを平文のまま保存していたり、ソルトなし・低コストなアルゴリズムを使っていたりすると、データベースの流出時に数千のアカウントが一度に危険に晒される可能性があります。
現代のウェブサービスでは「パスワードを直接読める・復元できる形で保存しない」ことが、最も基本的で重要な原則となっています。