「パスワードはハッシュ化してDBに入れているから安全」
「通信はSSL/TLSで暗号化されているから問題ない」
現場でこうした言葉を無邪気に口にするエンジニアに出会うたび、強烈な危機感を覚える。「暗号化」や「ハッシュ化」という言葉を唱えれば、魔法のようにセキュリティが担保されると思い込んでいる盲信。その思考停止こそが、最大の脆弱性だ。
セキュリティの歴史は、SSL/TLSの暗号スイートの変遷を見れば明らかなように、常に攻撃者と防御側の「終わりのないいたちごっこ」である。パスワードハッシュ化の進化もまた、計算機の性能向上とそれに対抗するエンジニアたちの血みどろの持久戦そのものだ。
そして何より、どれだけアルゴリズムを最新鋭に整えようと、Webアプリケーションは「常に攻撃されるもの」であり、ミドルウェアのパッチ1枚の怠慢で脆くも崩れ去る。その現実を直視しなければならない。
ハッシュ化の歴史：計算コストを巡るいたちごっこ
ハッシュ化の歴史は、SSLが古い暗号化方式を次々と切り捨ててきた歴史と完全に軌を一にする。
かつてWebの世界で標準のように使われていたMD5やSHA-1は、もともと「巨大なデータの完全性を素早くチェックする」ために設計されたアルゴリズムだった。つまり、計算が「高速であること」が最大の美徳だった。
しかし、攻撃者がGPUという並列計算の怪物を手に入れた瞬間、その美徳は致命傷へと転化する。家庭用のグラフィックボードですら毎秒数十億回のハッシュ計算が可能になり、平文とハッシュ値の対照表であるレインボーテーブルの登場もあって、MD5は一瞬でパスワードを暴かれるゴミクズ同然の存在に成り下がった。
ここから、防御側の発想の転換が始まる。「破られない関数を作る」のではなく、「計算にわざと時間をかけさせ、攻撃者のマシンを悲鳴させる」という消耗戦へのシフトだ。
- ソルトとストレッチング（PBKDF2 / bcrypt）：ユーザーごとにランダムな文字列（ソルト）を付与して事前計算テーブルを無力化し、さらに何千回、何万回と反復計算（ストレッチング）を強制することで、1回の認証にかかる時間を物理的に引き延ばした。
- メモリ拘束型への進化（Argon2）：しかし攻撃者は、GPUの次に専用計算チップ（ASIC/FPGA）を投入してきた。これに対抗するため、計算回数だけでなく「膨大なRAM（メモリ）を強制的に消費させる」ことで並列処理を物理的に窒息させるArgon2が誕生し、現代のデファクトスタンダードとなった。
速さを求めた時代から、重さを課す時代へ。攻撃者のリソースを削り殺すためのパラメータ調整という、冷酷なコストの持久戦が今も続いている。
「暗号化されたから安心」という盲信を捨てろ
この歴史を知れば、「ハッシュ化してあるから安心」「SSLがあるから安全」などという言葉がいかに浅薄かが分かるはずだ。
暗号化もハッシュ化も、所詮は「突破されるまでの時間を引き延ばしている」に過ぎない。SSL/TLSであっても古いプロトコル（SSL 3.0やTLS 1.0/1.1）が脆弱性を突かれて廃止に追い込まれてきたように、今日安全とされている暗号強度も、明日の計算力の前には無力化する。
「暗号化したから終わり」ではない。暗号強度の陳腐化を監視し、定期的にコストパラメータやアルゴリズムを見直し、移行し続ける運用設計があって初めて成立するものだ。暗号という技術名に胡坐をかいて思考停止した瞬間、そこはすでに突破口になっている。
アプリが堅牢でも死ぬ：ミドルウェアのアップデート漏れという現実
さらに残酷な現実がある。どれほどアプリケーションコードを綺麗に書き、最新のArgon2idでパスワードをハッシュ化していたとしても、システムはあっけなく死ぬ。
原因の多くは、OSやミドルウェア、フレームワークのアップデート漏れだ。
- データベース自体の既知の脆弱性（CVE）
- Webサーバ（NginxやApache）の設定不備やパッチ未適用
- アプリが依存している古いオープンソースライブラリの放置
攻撃者はわざわざ真正面からArgon2のハッシュ関数を解読しようとはしない。そんな面倒なことをするくらいなら、ミドルウェアのパッチが当たっていない古いポートや、ライブラリのリモートコード実行（RCE）の脆弱性を突き、サーバのルート権限を奪って環境変数や秘密鍵を丸ごと引っこ抜く。
「アプリのコードだけ見ていれば良い」という視野狭窄な開発体制は、裏口の鍵を開け放したまま玄関に最新の電子錠を取り付けているようなものだ。
Webアプリは「攻撃されるもの」：最低限WAFで防ぐ多層防御
インターネットに公開されているWebアプリケーションである以上、大前提として「24時間365日、世界中から機械的に攻撃され続けている」と認識しなければならない。
アクセスログを見れば、脆弱性を探索するスキャンボットのリクエストが絶え間なく押し寄せているはずだ。それらを「アプリのバリデーションだけで全部弾く」と考えるのは傲慢であり、設計の敗北だ。人間がコードを書く以上、どこかに必ず実装の隙が生まれる。
だからこそ、最低限WAF（Web Application Firewall）を前段に噛ませることが必須になる。
- SQLインジェクションやクロスサイトスクリプティング（XSS）の既知パターンをネットワーク境界で遮断する
- 悪意あるスキャンボットや怪しいIPからのブルートフォース（総当たり）をアプリに届く前に蹴落とす
WAFは万能の銀の弾丸ではないが、初歩的なミスやゼロデイ以外の既知攻撃による「即死事故」を防ぐためのシートベルトだ。境界防御（WAF）と、内部防御（セキュアコーディング・適切なハッシュ化・ミドルウェア更新）の双方が揃って、ようやく最低限の多層防御が成立する。
「フレームワークがやってくれる」で思考を放棄するな
最近のWebフレームワークは優秀だ。コマンドを一つ叩けば、認証機能が勝手に生え、デフォルトで適切なハッシュ化処理が裏側で実行される。
だが、それに甘えて「ライブラリがよしなにやってくれるから中身は知らない」と技術の理解を放棄していないか。
- なぜそのハッシュアルゴリズムが選ばれているのか？
- コストパラメータ（ストレッチング回数やメモリ割り当て）は自社のインフラ規模と合致しているか？
- 認証周りのライブラリに致命的な脆弱性が見つかった時、自力で安全な代替案へ切り替えられるか？
中身をブラックボックスにしたまま組み上げられたシステムは、トラブルが起きた瞬間に誰も手を出せない粗大ゴミと化す。フレームワークやクラウドサービスがどれほど便利になろうと、背後で動いている暗号技術の力学、計算コストのゲーム理論、そしてインフラレイヤーの泥臭い運用から目を背けてはならない。
「動けばいい」で済ませる素人から脱却し、足元の土台を疑い、学び続けること。それが、攻撃に晒され続けるWebの最前線に立つフルスタックエンジニアの最低限の責務である。
