ひしもち 
最近、EC-CUBE2.4系を2.13系までバージョンアップするというお仕事をしました。
元のサイトがそもそもデータベースも絡めてのカスタマイズがなされていて、管理画面からバックアップを取ることも出来ず、バージョンアップ用のモジュールもうまく動かず、という、トラウマ級に手の掛かるお仕事でした。
実際にバージョンアップに伴うデータ移行をしたのは先輩で、私はデザイン部分の移行が主な作業でしたので、データベース側の大手術についてはよく分かりません。
けれども、先輩が「はぁ……もうだめかも……」と、この世の終わりのような声で呟くのを聞いたのはこれが初めてでした。
そんな大仕事の最後の最後に、「パスワードを再発行するとマイページにログインできなくなる」という問題が発生したので、そのことについて書いておきます。
パスワードを再発行するとマイページにログインできなくなる
現象としては、移行前の会員登録メールアドレス/PWそのままでログイン可能。
しかし、パスワードの再発行手続き後、発行されたパスワードでログインしようとするとログインできない。
もちろん、再発行前のパスワードでも（再発行時に書き換えられているので）ログインできない。
という感じでした。
EC-CUBE本体のファイルは、移行前の機能を保持するために多少カスタマイズしたのでデフォルトの状態ではなかったのですが、会員登録情報やパスワードの発行が絡むようなところは一切触っていません。
もちろん、データの移行後に「AUTH_MAGIC」の値は合わせてあります（移行前と同一のメールアドレス/PWでログインできている）。
なぜ再発行したパスワードでログインできないのか
2.4系ではsha1によってパスワードが暗号化されていたようですが、2.13系ではsha256によって暗号化されるようになっています。また、2.4系と2.13系では暗号化に使用されるkeyも異なっていて、ざっくりいうと2.13系のほうが複雑になっているようです。
もしかして、sha1で暗号化されたものがsha256で暗号化されたものと照らしあわされてしまうからログインできなくなったのかしら！
と思ったのですが、再発行したパスワードはsha256によって暗号化されてデータベースに送られるわけですから、再発行後にそのパスワードでできないワケないですよね。
でも、目の付け所は悪くなかったみたいです。
本当の原因は、会員登録時に発行されるもう一つの暗号化キー、「salt」の値でした。
2.13系では、パスワード+salt（乱数）とAUTH_MAGICを組み合わせて、sha256で暗号化しているようです。2.4系にはそもそもsaltはなかったので、移行時にどこかでおかしなことになっちゃったに違いないのです！
phpMyAdminでデータベースをチェックしてみる
パスワードを含む会員登録データは、dtb_customerに入っています。
肝心の「salt」フィールドの値がどうなっていたかというと……移行前（2.4系）から登録されていたデータの部分は、値がすべて「0」になっていました。
移行後（2.13系）に登録した会員データには、アルファベット乱数が入っています。
こ、これ、「0」入ってたらアカンのちゃう？？
試しに、パスワードを再発行して入れなくなってしまったアカウントの「salt」の値を空にして、もう一度パスワードを再発行→ログインしてみると……入れました！！！
ちなみに、「salt」を空にした後パスワードを再発行すると、空だった「salt」にアルファベット乱数が入ります。移行は問題なくログインできますし、パスワードの変更も可能です。
【まとめ】バージョンアップしたEC-CUBEでパスワードを再発行してもマイページにログインできないときは……
データベースの「dtb_customer」内にある「salt」の値をチェック！
「０」など、アルファベット乱数でない値が入ってしまっている場合は空にしてみましょう！
EC-CUBEのバージョンアップはただでさえ手間がかかるのに、カスタマイズ済みのものをバージョンアップとなるとほんとうに大変です。
この記事がすこしでも（地獄をさまよっている）誰かのお役に立つことがあればいいなと思います。