『SHA-256でパスワードを保存』が危険な理由

理由1：SHAの『速さ』が攻撃側に有利

SHA-256は元々「大量データを高速にハッシュ化する」ことを目的に設計されています。最新のGPUでは1秒間に10億回以上のSHA-256計算が可能です。これは「改ざん検出」では正義ですが、パスワード保存では完全に裏目に出ます。

パスワードハッシュのDBが漏洩した攻撃者は、「よく使われるパスワード辞書（1億語程度）」を片っ端からSHA-256で計算して、DB内のハッシュと突き合わせます。GPU1台で1分かかりません。8文字以下の単純なパスワードはほぼ全て復元される、というのが現代のオフライン攻撃の実態です。

理由2：レインボーテーブル攻撃

「よく使われるパスワード→SHA-256ハッシュ」の対応表を事前に巨大なファイル（レインボーテーブル）として用意しておけば、DB流出後はテーブル参照だけでパスワードが復元できます。ソルト（後述）を入れていないSHA-256単体保存は、このレインボーテーブル攻撃の格好の的です。

対策1：ソルト

ユーザーごとにランダムな文字列（ソルト）を生成し、「パスワード＋ソルト」をハッシュ化する手法です。同じパスワードでもユーザーごとにハッシュが変わるため、事前計算したレインボーテーブルが使えなくなります。

ただし、ソルトだけではGPUによる総当たり攻撃の速さは変わりません。攻撃者はユーザー単位で「辞書×ソルト」を計算すればよく、1ユーザーあたりの所要時間はやはり1分未満です。

対策2：ストレッチング（時間を稼ぐ）

「ハッシュ化を何万回も繰り返す」のがストレッチングです。1回のハッシュ計算で1ミリ秒かかるようにすれば、攻撃者の総当たりも比例して遅くなります。これを担うのが KDF（Key Derivation Function：鍵導出関数） です。

• bcrypt：1999年設計。コストパラメータで反復回数を調整。長年デファクトの位置を占めてきた、枯れた選択肢。
• scrypt：2009年設計。メモリ消費もパラメータ化し、GPU/ASIC攻撃に対する耐性が高い。
• Argon2：2015年のPassword Hashing Competition優勝。現代のパスワードハッシュの標準的推奨。Argon2idの利用が一般的に推奨される。
• PBKDF2：NIST標準。ハッシュ関数（HMAC-SHA-256など）を反復するシンプルな設計。レガシー互換目的で残ることが多い。

いずれも「ソルト＋反復」を内部で正しく行うため、SHA-256単体で自作するより遥かに安全です。

補足：『ブラウザでSHA-256して送ればいい』も誤り

「クライアントJSでSHA-256してから送れば、ネットワーク上にパスワードが流れないから安全」というアイデアは時々見ますが、これは安全性を上げません。サーバー側から見ると「SHA-256(パスワード)」がそのままログイン用の文字列になっただけで、それを盗まれれば成りすませる構造になります。

通信路の安全はTLS（HTTPS）に任せる、サーバー側でbcrypt/Argon2でハッシュ化して保存する——この組み合わせが正しい設計です。本サイト『手軽屋』もインフラ方針として、独自パスワード認証は実装せず、Cloudflare Accessによるメールアドレス制限の認証に統一しています。

SHA-256を使ってよい場面

SHA-256自体が悪いわけではなく、用途を誤ると危険、というだけです。次のような場面ではSHA-256（や本サイトの ハッシュ値生成ツール）は適切に機能します。

• ダウンロードファイルの改ざんチェック（チェックサム照合）
• 2つのファイルの内容が同じか確認
• 電子署名で署名対象のハッシュとして使用
• ブロックチェーン・Gitオブジェクト識別など、内容アドレッシング
• HMACを通したメッセージ認証コード