Argon2idをWordPress案件の標準にするべきか――Web制作会社の診断・基本方針・行動
OWASP推奨なら、そのまま使えばよいのか
昼下がりの事務所。ずんだもんは、ホスティング会社の仕様ページを見ながら、満足そうにうなずいていた。
💚ずんだもん
「OWASPはArgon2idを推奨している。PHPにも機能がある。XServerでも使える。だったら、今後のWordPress案件は全部Argon2idにすればよいのだ」
🎀めたん
「気持ちは分かります。ただ、WordPress 6.8以降の標準はbcryptです。WordPress側も、何も考えず古い方式を残しているわけではありません」
💚ずんだもん
「推奨されている方式と、WordPressの標準が違うのだ？」
⚔️つるぎ
「ここでは三つの判断を分けましょう。技術的に利用できること。会社の標準として採用できること。そして、将来も使い続けられることです」
🎀めたん
「現在のサーバーで動いたとしても、復旧先や移転先で動かなければ、会社の標準にはしにくいんです」
技術的に使えることと、会社の標準として使い続けられることは別の問題です。
診断
Argon2idは何を守るのか
💚ずんだもん
「Argon2idに変えれば、WordPressへの侵入を防げるのだ？」
🎀めたん
「そこは違います。Argon2idが主に守るのは、データベースからパスワードハッシュが漏れた後です」
⚔️つるぎ
「攻撃者は、候補となるパスワードを大量に試して、漏れたハッシュと一致するか調べます。bcryptは計算時間を必要とさせます。Argon2idは、それに加えてメモリも使わせることで、大量並列の解析を高コストにします」
💚ずんだもん
「漏洩した後の被害を広げにくくする技術なのだな」
🎀めたん
「そうです。ただし、WordPressやプラグインの脆弱性、フィッシング、パスワードの使い回し、管理者権限の与えすぎまでは防げません。ログイン画面への攻撃、更新漏れ、バックアップ不備も別の対策が必要です」
Argon2idは侵入を防ぐ万能策ではなく、漏洩後のパスワード解析コストを高める対策です。
なぜWordPressはbcryptを選んだのか
💚ずんだもん
「では、OWASPがArgon2idを推奨しているのに、なぜWordPressはbcryptを標準にしたのだ？」
🎀めたん
「WordPress Coreは、世界中の多様なPHP環境で動かなければならないからです」
⚔️つるぎ
「Argon2に対応していない共有ホスティングもあります。独自構成のPHPや、利用者がビルド条件を確認できない環境もあります。将来どこへ移転するか分からないサイトも支えなければなりません」
🎀めたん
「WordPress Coreは、不特定多数の環境を対象にします。一方、制作会社は利用するサーバーをXServerなどに限定できる場合があります。支える範囲が違えば、妥当な標準も変わります」
💚ずんだもん
「bcryptは遅れているのではなく、広い環境を支えるための選択なのだな」
WordPress Coreと制作会社では、支える環境の範囲が違うため、同じ技術でも判断が変わります。
問題は使えるかではなく、使い続けられるか
⚔️つるぎ
「XServerの本番環境でArgon2idを使えた。それだけでは、診断は終わりません」
💚ずんだもん
「ほかに何を見るのだ？」
🎀めたん
「ステージング環境、バックアップからの復旧先、PHP更新後の環境、将来の移転先です」
⚔️つるぎ
「Argon2idで保存されたハッシュを、Argon2非対応環境へ持っていっても、自動的にbcryptへ変換はできません。再ハッシュには、利用者が入力する元のパスワードが必要だからです」
💚ずんだもん
「つまり、一度採用したらArgon2対応PHPがサイトの条件になるのだ」
🎀めたん
「本番だけではありません。復旧と移転まで含めた実行要件です」
Argon2idを採用した時点で、Argon2対応PHPは本番だけでなく、復旧先と移転先にも必要な実行要件になります。
案件によって優先度が違う
💚ずんだもん
「それでも、強い方式なら会社案内サイトにも入れておけば安心なのだ？」
🎀めたん
「管理者が数人だけの会社案内サイトなら、Argon2idにも意味はあります。ただ、二要素認証、管理者数の削減、更新管理、ログイン制限、バックアップのほうが先になることがあります」
⚔️つるぎ
「会員サイトや予約サイトでは事情が変わります。多数の利用者パスワードを保存するため、データベース漏洩時の影響が大きくなります。制作会社が環境を継続管理できるなら、Argon2idの優先度は上がります」
🎀めたん
「反対に、納品後は顧客が自由にサーバーを変更し、制作会社がPHP更新にも移転にも関与しない案件があります。その場合、bcryptを維持することも合理的です」
セキュリティ要件はサイトの種類だけでなく、納品後に誰が環境を管理するかで変わります。
基本方針
全案件必須ではなく、条件付き標準にする
⚔️つるぎ
「診断を踏まえると、制作会社の基本方針はこうなります」
⚔️つるぎ
「WordPress 6.8以降のbcryptを最低基準とする。制作会社がPHP環境、保守、復旧、移転条件を管理できる認証付き案件では、Argon2idを標準採用する」
💚ずんだもん
「動いた案件だけ、気分で有効にするわけではないのだな」
🎀めたん
「はい。任意設定ではなく、適用条件を持つ会社標準です。ただし、全案件へ押し込む絶対条件にも禁止条件にもしません」
Argon2idは全案件の絶対条件ではなく、環境と保守を管理できる認証付き案件の条件付き標準にします。
採用する案件と見送る案件を分ける
🎀めたん
「たとえば、制作会社がホスティングを選び、保守契約があり、本番とステージングと復旧先を確認できる会員サイト。これは採用しやすい案件です」
⚔️つるぎ
「共通プラグインを継続管理し、サーバー移転の手順まで制作会社が持っているなら、責任範囲も明確です」
💚ずんだもん
「顧客指定の共有ホスティングへ納品して、その後は誰が移転するか分からない案件は？」
🎀めたん
「見送りやすい案件です。保守契約がなく、復旧先も保証できず、顧客が自由にホスティングを変えるなら、Argon2idを必須にするほど将来の制約が増えます」
アルゴリズムの強さだけでなく、実行環境を継続して保証できるかで採用を決めます。
認証ポリシーをテーマから分離する
💚ずんだもん
「設定はテーマのfunctions.phpに書けば簡単なのだ？」
⚔️つるぎ
「簡単ですが、責務が違います。テーマは表示やデザインを担当します。テーマを変更しただけで、パスワード保存方式まで変わる設計は避けるべきです」
🎀めたん
「通常のプラグインは、管理画面から停止される可能性があります。制作会社が継続保守する案件なら、サイト運用に必須のポリシーを置けるMUプラグインが候補になります」
⚔️つるぎ
「MUプラグインが認証ポリシーを保持し、ホスティングが必要なPHP環境を提供する。役割を分けておけば、どこを確認すべきかも明確になります」
パスワード保存方式はテーマの機能ではなく、サイト全体の認証ポリシーとして管理します。
bcryptを使う案件も失敗ではない
💚ずんだもん
「Argon2idを使わない案件は、セキュリティ意識が低いと言われないのだ？」
🎀めたん
「移転先や復旧先を保証できないのに、強い方式だけを必須にするほうが危険です。WordPress標準のbcryptを維持し、二要素認証や更新管理を確実にする判断もあります」
⚔️つるぎ
「標準化は、すべての案件を同じ設定にすることではありません。標準を適用する条件と、例外にする条件を説明できる状態にすることです」
標準化とはすべてを同じにすることではなく、標準と例外の条件を説明できる状態にすることです。
行動
対応ホスティングを一覧化する
🎀めたん
「まず、普段使うホスティングの対応状況を一覧にしましょう」
💚ずんだもん
「対応と書いてあれば終わりではないのだ？」
🎀めたん
「公式情報に加えて、実環境で利用できるか、対象PHPバージョンは何か、ステージングや復旧環境でも使えるかを確認します。PHP更新後の再確認も必要です」
⚔️つるぎ
「XServerのように、公式情報と実環境確認の両方をそろえられるサービスは、会社の標準候補にしやすくなります」
ホスティングの対応状況を担当者の記憶に任せず、会社の確認済み情報として一覧化します。
共通のMUプラグインとして管理する
⚔️つるぎ
「次に、案件ごとのコピー＆ペーストをやめます」
🎀めたん
「Argon2idを選択する設定、コスト設定、対応環境の確認、エラーや警告の扱いを、共通のMUプラグインへまとめます。ソースコードだけでなく、バージョン管理と運用資料も必要です」
💚ずんだもん
「担当者が退職したら、設定の意味が分からなくなる状態を避けるのだな」
セキュリティ設定は担当者の記憶ではなく、会社が保守する共通資産として管理します。
公開・更新・移転時に確認する
🎀めたん
「動作確認は、初回実装時だけでは足りません」
⚔️つるぎ
「新規公開、ステージング構築、PHPバージョン変更、サーバー移転、バックアップからの復旧。このたびに確認します」
💚ずんだもん
「何を確認すればよいのだ？」
⚔️つるぎ
「Argon2idを利用できること。ハッシュを生成できること。生成したハッシュを検証できること。この三点に絞れば、手順として残しやすくなります」
実行環境に依存するセキュリティ要件は、環境が変わるたびに再確認します。
案件資料へ実行要件を残す
💚ずんだもん
「MUプラグインを見れば、採用していることは分かるのではないか？」
⚔️つるぎ
「障害復旧や移転を担当する人が、最初にコードを読むとは限りません。仕様書と引き継ぎ資料にも残します」
🎀めたん
「使用するハッシュ方式、設定の管理場所、必要なPHP機能、移転時の確認事項、非対応環境への移転制限、保守担当者。これらを実行要件として記録します」
Argon2idを採用した事実は、コードだけでなく、仕様書と引き継ぎ資料にも残します。
会員サイトから段階導入する
🎀めたん
「最初から全案件を切り替える必要はありません」
💚ずんだもん
「どこから始めるのだ？」
⚔️つるぎ
「自社の検証環境で確かめ、次に自社サイトへ入れます。その後、保守中の会員サイト、新規の予約・会員案件、条件を満たす既存案件へ広げます」
🎀めたん
「利用者パスワードが多く、制作会社が環境を管理できる案件ほど、導入効果と運用可能性の両方が高くなります」
導入効果が大きく、実行環境を管理できる案件から段階的に始めます。
まとめ 強い方式を、仕事として運用する
窓の外が少し暗くなり、ずんだもんは開いたままだった仕様ページを閉じた。
💚ずんだもん
「Argon2idは強いから全部に入れる、という話ではなかったのだ」
🎀めたん
「案件の種類、保守契約、サーバーの管理範囲によって判断は変わります。会社案内サイトと会員サイト、継続保守案件と納品後に顧客が管理する案件では、優先順位が同じではありません」
⚔️つるぎ
「診断では、Argon2idが漏洩後のパスワード解析を難しくする一方、対応PHPを本番、復旧先、移転先の実行要件にすることを確認しました」
⚔️つるぎ
「基本方針は、全案件必須ではありません。制作会社がPHP環境、保守、復旧、移転を管理できる認証付き案件で、Argon2idを条件付き標準にします」
🎀めたん
「行動は、対応ホスティングの一覧化、共通MUプラグインでの管理、公開・更新・移転時の確認、案件資料への記録、会員サイトからの段階導入です」
💚ずんだもん
「どの方式が一番強いかだけでなく、誰が将来まで面倒を見るのかを決めるのだな」
⚔️つるぎ
「はい。アルゴリズムの選択を、実装担当者だけの判断で終わらせないことです。復旧する人、移転する人、保守する人が同じ前提を共有できて、初めて会社の標準になります」
Web制作会社の仕事は、強いアルゴリズムを選ぶことだけではありません。どの案件へ適用し、誰が環境を守り、移転時に何を確認するかまで決めることが、セキュリティを仕事として扱うということです。
