今回の記事は、All-in-One WP MigrationでWordPressサイトの移転後にログインできなくなるケースの解決策ですが、
最も多いケースは、
「移転先のWordPressのパスワードが、移転元のパスワードに上書きされてしまったことに気づかず、移転先の古いパスワードでログインしようとしているだけ」
のパターンです。
「いや、このパターンではないぞ！」と場合、今回記載する内容を参考にしてみてください。
問題が起こった経緯
- WordPressのプラグイン「All-in-One WP Migration」を使って、本番環境(さくらサーバー)からテスト環境(エックスサーバー)にデータをまるごと移行し、HPの改修を行いました。
- 改修完了後、再度「All-in-One WP Migration」でテスト環境(xserver)から本番環境(さくらサーバー)へデータ移行。
- 移行完了後に何故かテスト環境と同じユーザー名とパスワードでログインできない事態に陥りました。（「エラー: 入力内容を確認の上、もう一度送信してください。」と表示されるようになります）
管理者メールアドレスも別会社のものであったため、パスワードの再設定も難しい状態になりました。
※おそらくパスワード再設定しようにも、正規のログイン情報でも管理画面に入れないので再設定すらできないと推測される状況。
そもそもの原因
パスワードの文字列自体が消えたり変わったりしたわけではなく、原因は移転先である「さくらサーバー」のセキュリティ仕様によって不具合が起きていました。
原因①：認証用ユニークキー（SALT）のミスマッチで「暗号」が読めなくなった
WordPressは、パスワードをそのまま保存せず、wp-config.php に書かれている「認証用ユニークキー（ソルト）」という秘密の文字列と掛け合わせて、複雑な暗号にしてデータベースに保管しています。
エックスサーバーとさくらサーバーは、それぞれが独自のルールでパスワードを暗号化しているようで、データを丸ごとさくらサーバーに持ってきた際、サーバー環境が変わったことで、さくら側のWordPressが「エックスサーバー時代の暗号ルール」を正しく解読できなくなってしまったと推測されます。
———————————————————————————
WordPressはセキュリティを高めるために、以下のような「足し算」をしてパスワードを暗号化しています。
$| ユーザーのパスワード(256) ＋ 認証用ユニークキー | ➔ データベースに保存される値$
例えば、パスワードが「256」だったとします。
もし、認証用ユニークキーがなかったら、世界中のどのWordPressサイトでも「データベースに保存される暗号の値」が完全に同じになってしまいます。ハッカーに「この暗号の形はパスワード『256』だな」とパターンを覚えられたら終わりです。
そこで、WordPressはセキュリティを高めるために、上記のような数式のなかに「認証用ユニークキー（ランダムな数字）」を足し算することにしました。
これを踏まえて、今回の場合暗号はこのようになっています。
- エックスサーバーの数式：
$| 256 ＋ c81e7…（エックスサーバーごとに違うランダムな認証用ユニークキー） | = 暗号A$ - さくらサーバー（引越し後）の数式：
$| 256 ＋ 0（初期状態のキー） | = 暗号B$
引越しによって「認証用ユニークキー（足し算する数字）」が消えてしまったため、同じパスワードを入力しても、さくらサーバーが計算した結果（カギ）が「暗号B」になってしまい、データベースにある「暗号A（鍵穴）」と一致しなくなった。これがログインできなかった原因です。
——————————————————————————-
原因②：さくらサーバーの「ガードの固さ（WAF）」が発動した
さくらインターネットには、標準で非常に強力なセキュリティ機能（WAFや国外IPフィルタなど）が備わっています。
引越し直後の「以前のサーバーの空気感（古いCookieやセッション情報など）」が残った状態でログインを試みたため、さくらサーバー側が「不審なアクセス（総当たり攻撃など）かもしれない！」と勘違いし、WordPressの処理に入る手前で通信をブロックしていました。
「エラー: 入力内容を確認の上、もう一度送信してください。」という不自然なエラーメッセージは、WordPressではなくサーバー側のガードマンが弾いていた証拠だったのです。
※エックスサーバーは比較的懐が深いため、逆方向の引越し（さくらサーバー→エックスサーバー）の時はすんなり通してくれていました。
解決策
phpMyAdminから「MD5」でパスワードの強制書き換えを行いました。
メールでのパスワード再設定もできない状態から、一発でログインできるようにできた方法が
「データベースを直接書き換えて、さくらサーバー側に新しい鍵穴を作らせる」という手段です。
解決のステップ（さくらインターネット版）
1. さくらサーバーのコントロールパネルにログインし、「データベース」の管理ツール（phpMyAdmin）を開きます。
2. 該当するデータベースを選択し、wp_users（接頭辞がある場合は xxxx_users）というテーブルをクリックします。
3. ログインしたいユーザー（今回なら admin）の行にある「編集（鉛筆マーク）」をクリック。
4. user_pass という項目を探し、以下のように書き換えます。
・関数（Function）の列：ドロップダウンから「MD5」を選択（※重要！）
・値（Value）の列：もともと入っている暗号を消して、新しいパスワード（生の文字列）をそのまま入力。
5. ついでに user_email も自分のメールアドレスに書き換えておきます。
6. 画面最下部の「実行」ボタンを押します。
7. ログイン画面で新しいパスワードを入力します。
8. 管理画面に入れたら完了です。
MD５とは？
MD5とは「どんなデータも、絶対に元に戻せない形に粉砕してしまうミキサー」、数学でいう「絶対値の記号 $|x|$ 」のような計算ルールのことです。
前述のとおり、通常、WordPressはセキュリティを高めるために、以下のような「足し算」をしてパスワードを暗号化しています。
$| ユーザーのパスワード(256) ＋ 認証用ユニークキー | ➔ データベースに保存される値$
「認証用ユニークキー」はサーバーごとに異なるランダムな文字列です。
今回の引っ越しでログインできなくなったのは、サーバーが変わって認証用ユニークキーがズレてしまい、正しいパスワードを入れても鍵穴と形が合わなくなってしまったからでした。
MD5の役割は認証用ユニークキーを無視すること
phpMyAdminを使ってMD5でパスワードを上書きしたことで、WordPressに対して「認証用ユニークキーは一回完全に無視して、純粋な絶対値(MD5)の計算だけで暗号を作ってデータベースに保存してください」という命令したことになります。
そうしたことで、例えばMD5で設定したパスワードが「123456」の場合、以下のようになります。
$| MD5で設定したパスワード(123456) ＋ 認証用ユニークキー | = 暗号C$
認証用ユニークキーの足し算を無しにした、シンプルな「暗号C」という鍵穴をデータベースに直接書き込んだということです。
暗号Cを作成したことで安全性はどうなったのか
結論から言うと、初回ログインをしてしまえばまったく問題ありません。
シンプルな暗号Cだったのは、初回ログインに成功するまでの「ほんの一瞬」だけだからです。
WordPressには、「自動セキュリティ強化機能」が備わっています。
- 「暗号C」を使って無事にログインに成功する。
- WordPressが「この鍵穴はユニークキーが混ざっていない昔のシンプルな暗号（MD5）だ」と気づく。
- 入力したパスワードが手元にあるうちに、裏側で一瞬にして「強力な暗号規格 ＋ 今のサーバーのユニークキー」を混ぜ合わせた暗号に作り直して、データベースを勝手に上書き保存する。
つまり、管理画面に入れたその瞬間にセキュリティは自動でアップデートされています。
セキュリティが自動でアップデートされたのか確認する方法
- 先ほどの解決のステップで開いたphpMyAdmin（データベース）でwp_users（接頭辞がある場合は xxxx_users）のuser_passを確認します。
- $P$B… や $2y$… など、頭に「＄」マークがついた、めちゃくちゃ長い文字列に変わっていたらWordPressの自動セキュリティ強化が成功している証拠です。
頭に $ がついたこの長い文字列は、WordPressが「最新の強力な暗号（Bcryptやphpassという規格）に作り直したよ！」というサインです。
まとめ：サーバー移転時は「MD5の書き換え」を知っておくと無敵
- パスワードは消えていない（変わっていない）。サーバー環境が変わって「暗号が読めなくなった」だけ。
- エックスサーバーは引っ越しに寛容だけど、さくらサーバーはガードが固い。
- パスワードはあっているのにログインできなくなったら、焦らずphpMyAdminから「MD5」で上書きすればOK
All-in-One WP Migrationでのサイト移行で同じように締め出されてしまった方は、サーバーのデータベースを覗いてみてください。
以上、初めての予期せぬトラブルで頭が真っ白になったWebデザイナーのYUYAでした。
