目次
パスワードを画面に表示しない、DBを非公開にする。それだけでは、保存データが流出した場合の推測に備えたことにはなりません。パスワード保存では、元の値を取り戻さずに照合する仕組みと、推測に必要なコストを引き上げる設計が重要です。
本記事は2026年10月18日にOWASPとPHPの一次資料を確認した実務解説です。特定サイトの漏えい事件を報じるものではありません。会員サービスの移行は仮想例で、段階的な改修と試験方法は本サイトの提案です。パスワードの再設定手続きではなく、サーバーに保存する方式を中心に扱います。
スポンサーリンク
暗号化とパスワード用ハッシュを区別する
通常のログインでは、管理者が利用者のパスワードを復号して読む必要はありません。OWASPは、原則として平文や可逆の暗号化ではなく、現代的な適応型のハッシュ方式で保存することを勧めています。元の値を取得できる設計は、鍵の保管と運用にも別のリスクを持ち込みます。
一般的な高速ハッシュを一回かけることと、パスワードの保存用に設計された方式を使うことも異なります。攻撃者が流出したデータへ大量の候補を試す状況を考え、推測にかかる処理量やメモリーを調整できる方式を選びます。
OWASPはArgon2idを優先する候補として挙げています。ただし、実行環境、ライブラリの対応、組織の要件を確認せず方式名だけで切り替えるべきではありません。本記事では一律の設定値を配布せず、現行資料を基準に実機でコストと負荷を測る手順を提案します。
出典：OWASP Password Storage Cheat Sheet。
ソルトとペッパーは役割が異なる
ソルトは各パスワードの計算に組み合わせる値です。適切な標準APIを使う場合、生成や保存をライブラリへ任せられる構成があります。秘密の固定値を全利用者へ足すだけで、個別のソルトを置き換えたことにはなりません。
ペッパーは、保存データとは別に管理する秘密を利用する設計です。導入するなら、DBと同じバックアップへ秘密を一緒に保存しないなど、分離の効果を維持する必要があります。追加しただけで自動的に安全になるものではなく、秘密を紛失・交換した場合の認証への影響も増えます。
自作の組み合わせを急いで導入するより、利用する認証基盤の仕様を確認してください。ペッパーを交換するにはパスワードの再入力や再設定が必要となる設計もあります。鍵のローテーションと同じ感覚で、全件を簡単に変換できると思わないことが重要です。
スポンサーリンク
照合と再ハッシュを標準APIへ任せる
PHPにはpassword_hash、password_verify、password_needs_rehashなど、パスワード保存と照合のためのAPIがあります。ハッシュを手で解析したり、同じ文字列になるはずだと独自に比較したりせず、採用する標準の照合処理へ渡します。
password_hashの既定方式は将来変更され得るため、保存先の長さを現在の出力だけで固定しないことも重要です。文字列の切り詰めや文字コード変換が保存時に起きていないかを確認します。異なる環境へ移したときの対応方式も検証してください。
認証に成功し、現在の設定に対して再ハッシュが必要だと判断したときは、入力されたパスワードを使って新しい保存値へ更新できます。成功する前にパスワードが正しいと扱ったり、古いハッシュをそのまま新方式へ入れて通常の照合と混在させたりしないようにします。
既存アカウントは利用状況に合わせて移行する
仮想の会員サイトに旧方式の保存値が残っているとします。利用者全員へ一度に変更を求める方法と、認証成功時に順次更新する方法では、負担と移行の速度が異なります。旧方式をどの条件で受け付け、いつまで残すかを明文化します。
認証時の移行だけでは、長くログインしない利用者が残ります。本サイトは、未移行数を把握し、一定の基準で再設定やアカウントの見直しへ進める手順を用意することを勧めます。移行の期限は業務とリスクで決め、永続的に旧方式を許す状態を避けます。
移行処理で旧値と新値を複数箇所へ保存すると、弱いコピーが残る可能性があります。正規の保存先と履歴、バックアップ、開発環境への複製を含め、どこに何が残るかを確認します。現在のDBを更新したことと、過去のコピーを消したことは別です。
関連する公式仕様：PHP password_hash。
スポンサーリンク
コストの設定は通常時と混雑時を測る
コストを上げると攻撃者の推測を重くできる一方、正規のログインにも資源が必要になります。単一の認証が何ミリ秒で終わるかだけでなく、想定される同時ログイン数で、メモリー、CPU、待ち時間、失敗率を測定します。
本サイトの提案は、通常のピークと、不正な反復がある場合を分けて試すことです。パスワード保存方式の強化を理由にサービスが容易に停止しないよう、ログインの頻度制限や同時実行の扱いも確認します。オンラインでの試行制限は、流出後のオフライン推測を止めるものではありません。
エラー時に軽い旧方式へ黙って戻す設計は避けます。対応しない方式やメモリー不足を検知したら、利用者に秘密を出さず、運用者が原因を追えるようにします。高い設定値を入れたという記録ではなく、運用できる条件を試験して記録します。
移行のテストをアカウントの状態ごとに分ける
専用のテストアカウントを、新方式、旧方式、長期未利用、停止済み、再設定待ちに分けます。正しい入力と誤った入力を試し、認証の結果と保存値の変化を照合します。誤ったパスワードで保存値だけが更新されることがないかも確認します。
旧方式の認証に成功した後は、新方式へ移ったことを確認し、同じパスワードで通常の認証が続くことを試します。二つの端末から同時にログインした場合や、移行中に再設定された場合には、古い処理が新しい値を上書きしない条件が必要です。
ログへパスワード、平文の入力、再設定トークンを出す必要はありません。ハッシュ自体も不要な共有を避け、試験レポートには方式の種別と移行結果など、秘密を再現しない情報を記録します。
| 状態 | 確認する動作 | 保存側の確認 |
|---|---|---|
| 新方式の会員 | 正しい入力だけが成功する | 不用意な再保存がない |
| 旧方式の会員 | 成功後に移行する | 新方式で以後も照合できる |
| 誤った入力 | 認証を拒否する | 保存値が書き換わらない |
| 同時ログインと再設定 | 決めた最新状態を守る | 旧処理で新しい値を戻さない |
保存先以外へ秘密が流れる経路を閉じる
DBで安全に保存しても、要求本文を監視サービスへ送れば平文が別の場所へ残ります。ログイン、登録、変更、再設定の各処理について、アクセスログ、エラー監視、デバッグ出力、サポート用の画面を点検します。
テストに本番の会員データをそのまま使わず、専用の架空アカウントを用意します。バックアップへのアクセスも必要な担当者へ制限し、開発者が気軽に保存値を持ち出せる構造を減らします。ハッシュ化は、保存したデータを公開してよいという意味ではありません。
パスワードを問い合わせで尋ねたり、運用担当者が本人のパスワードを読み上げたりする手順は見直します。本人が忘れた場合は正規の再設定経路へ進め、管理者が元の値を取り戻す必要のない設計を維持します。
移行中の障害と切り戻しを想定する
仮想のサービスで新方式へ移行した直後、古いアプリへ切り戻す必要が生じたとします。旧アプリが新しい保存値を照合できなければ、DBをそのままにしてもログインへ影響します。逆に、古いDBのコピーを戻せば、移行後のパスワード変更などを失う可能性があります。コードの切り戻しとデータの復元を同じ操作だと扱わないことが重要です。
本サイトは、導入前に新旧のアプリが受け付ける保存方式を確認し、対応する段階を用意する方法を勧めます。新しい値を保存し始める時点と、古い方式を受け付けなくする時点を分ければ、問題が起きたときの判断をしやすくなります。互換性のために弱い方式を永久に残すのではなく、移行の終わりまで計画します。
測定には、通常の認証、誤った入力、認証成功に伴う再ハッシュを別々に含めます。移行期間だけ保存処理が増えるため、通常時の測定だけでは混雑を見落とす可能性があります。負荷が高いときに移行をどのように進めるかも、認証基盤の機能に合わせて検討してください。
バックアップから復旧する訓練では、保存方式だけでなく直近の変更の扱いと利用者への案内を確認します。平文を保管しておけば移行が楽になるという設計へ戻らず、正規の照合と再設定で回復できる手順を維持します。
スポンサーリンク
流出が疑われたときは方式変更だけで終えない
保存値の流出が疑われる場合、強い方式へ更新しただけでは、すでにコピーされた旧データを取り消せません。侵害の範囲、取得された情報、既存セッション、回復先の変更などを調べ、必要な失効と利用者への対応を別に判断します。
対応で方式を変える場合は、移行の理由と対象を記録します。認証基盤に入れる変更と、侵入経路を閉じる変更を分けて追跡すると、片方だけ完了している状態を把握しやすくなります。ハッシュ方式の選択だけでアカウント保護全体を説明しないことが重要です。
適切な保存方式、維持できるコスト、移行の終わらせ方、秘密を残さない周辺処理を一つの運用として整えることが、パスワード保存を長く改善するための基準になります。
参考資料
以下は2026年10月18日に直接確認した一次資料です。製品やサービスの設定は、実際に利用する版と環境に対応する資料で確認してください。
