ソルト＆レインボーテーブルを整える。

そもそもソルトとレインボーテーブルとは

パスワードのハッシュに「塩」を混ぜて、使い回しの攻撃表を無効にする。

どこで・どんな場面で出会うか

• 会員サイトやログイン機能を作るとき

  パスワードを保存する設計は、最初に決めておくべき部分です。ここを雑にすると、後から直すのが大変になります。

• 「ハッシュ化されていた」という漏えいのニュース

  パスワードが漏れた報道で見かける言葉です。ソルトの有無や方式によって、実際の危険度は大きく変わります。

• 古い社内システムや自作ツールを引き継いだとき

  昔のシステムは、ソルトなしで単純なハッシュのまま保存していることがあります。棚卸しのときに確認したい点です。

• フレームワークやログイン部品を選ぶとき

  多くの部品は、ソルトつきの方式が標準で入っています。自分で作らず、定評のあるものを選ぶ理由がここにあります。

• セキュリティ診断や監査を受けるとき

  パスワードの保存方法は、診断で必ず確認される項目の一つです。説明できるように、意味を知っておくと役立ちます。

知らないと何が困るか

• 「ハッシュ化しているから安全」と思い込む。ソルトなしの単純なハッシュは、よくあるパスワードなら早見表で割り出されることがあります。
• 自作して SHA-256 だけで保存してしまう。動くものはできますが、守りとしては弱い設計になります。
• 漏えいのニュースを他人事にする。パスワードを使い回していると、別のサービスにまで影響が広がります。報道を見たら、変更するきっかけにできます。

上のツールで、ソルトなしとありでハッシュ値がどう変わるかを比べてみてください。

正しいパスワード保存・4つの作法

「ハッシュにした」だけでは、守ったことにならない。

1. 1

   ユーザーごとに違うソルトを使う

   ランダムなソルトを1人1人に発行し、ハッシュと並べて保存します。これで事前計算テーブルが共通で使えなくなり、同じパスワードの人どうしでも保存値が一致しません。ソルトは秘密でなくてよく、漏れても効果は保たれます。

2. 2

   パスワード用の「遅い」関数を使う（bcrypt / Argon2 / scrypt / PBKDF2）

   SHA-256 を1回かけるだけは速すぎて、GPU で毎秒何十億回も試せてしまいます。あえて計算を重く・メモリを食うようにした専用関数（ストレッチ）を使い、総当たりを現実的でない速度に落とします。生の SHA-256 単体はパスワード保存に不適切です。

3. 3

   ペッパー（アプリ側の共通秘密）を足す

   ソルトとは別に、DB ではなくアプリの設定（秘密）側に置く共通の追加値がペッパーです。DB だけが漏れてもペッパーが分からなければクラックがさらに難しくなります。鍵管理サービス等で安全に保管します。

4. 4

   そもそも弱いパスワードを作らせない

   どんなに保存方法を整えても、「password」「123456」のような単語は表に載っていて一瞬で破られます。長いパスフレーズ・パスワードマネージャ・パスキー（FIDO2）への移行が根本的な防御です。

🔒 計算はすべてあなたのブラウザの中（Web Crypto API）で完結します。入力した文字もハッシュもサーバには送られません（送信ゼロ）。crypto.subtle は安全な接続（https / localhost）でのみ動作します。