CyberPanel 1.8.8: Rehashes Any Preexisting, Already Hashed Email Passwords

I warned CyberPanel about this but there are still issues with their upgrade password migration scripting. Days earlier, I had reset all my passwords in 1.8.7 using CyberPanel’s change password tool. Today, as I upgraded, 1.8.8 reencrypted over top of all my preexisting encrypted passwords. All passwords are hashed to “$2y$05” level BCRYPT encryption. Observing their code in action, I can see what is going on. Their code hashes over top of the hashing, or double encrypts those passwords. Repeat: this impacts you even if your passwords were properly reset and re-hashed by CyberPanel in 1.8.7 using their password reset tool or the CyberPanel Rainloop password reset plugin. The bottom line is the upgrade script is again (still) broken and will hash over top of your password hashes, making them all corrupt and unreadable, again needing to be reset one by one. So whatever you do, by all means, don’t upgrade to 1.8.8 until @CyberPanel addresses this!

That does not matter, update and everything very well

@rebnaque said:
That does not matter, update and everything very well
Which version did you upgrade from? I observed the passwords in the database and it did exactly what I described. I have a few hunches about what it could be.

@Hifihedgehog

No, if you look here passwords are only updated if that check is 1 → cyberpanel/upgrade.py at e66f061a4a42289d20a2980db175304f0c47986f · usmannasir/cyberpanel · GitHub

Check is only true if you have default_pass defined in /etc/dovecot/dovecot-sql.conf.ext

Which CyberPanel removes it and does not expect again.

@Hifihedgehog

No, if you look here passwords are only updated if that check is 1 → https://github.com/usmannasir/cyberpanel/blob/e66f061a4a42289d20a2980db175304f0c47986f/plogical/upgrade.py#L1556

Check is only true if you have default_pass defined in /etc/dovecot/dovecot-sql.conf.ext

Which CyberPanel removes it and does not expect again.

Strange. Then why did my passwords get rehashed? I definitely did not change default_pass. I’ll let you know if this happens again with a future update.

Out of curiosity, I tried redownloading and rupgrading over top to see what would happen. The upgrade script doesn’t seem to cause the issue again. So it must have been something that was there from 1.8.7 that caused it. At any rate, all’s well that ends well.