Question New password hashing option for email accounts

[TorbHo]

Server operating system version

Ubuntu 24

Plesk version and microupdate number

18.0.72

Hi everyone,

I just read in the Plesk changelog for 18.0.72:

(Plesk for Linux) You now have the option to use hashing for email-account passwords instead of symmetric encryption. This option is enabled by default. To disable password hashing and re-enable symmetric encryption, add the following lines to the panel.ini file:

[passwordManagement]
features.allowAdminAliasPasswordHashing = false

My understanding is the following:

• Hashing is now the default setting.
• This applies not only to new installations, but also to existing ones after updating Plesk.
• Newly set passwords will be hashed, while existing passwords remain symmetrically encrypted until they are changed.
• If I add the lines above to panel.ini, Plesk will revert to the old behavior (symmetric encryption).

Did I get this right?

Will existing email account passwords automatically re-saved as hashes after the update, or only when the user/admin actively changes the password?

Thanks in advance for clarifying!

 

[Bitpalast]

Great question!

I'd like to add: Does this mean, that in the future the "plesk sbin mail_auth_view" will become obsolete?

 

[mizar]

Hello,

The RN entry is a bit misleading, we will update it. Regarding the questions:

> Hashing is now the default setting.
> This applies not only to new installations, but also to existing ones after updating Plesk.

No, it is not default yet. You need to go to Tools & Settings -> Security policy and explicitly select Hashing in Storing email passwords section. Or you can use plesk bin server_pref CLI utilty with email-password-hashing parameter. Symmetric encryption is still default for new and upgraded installations.

> Newly set passwords will be hashed, while existing passwords remain symmetrically encrypted until they are changed.

Yes. If you need hash existing password, you can you instructions from KB article.

> If I add the lines above to panel.ini, Plesk will revert to the old behavior (symmetric encryption).

No, the panel.ini setting `passwordManagement.features.allowEmailPasswordHashing` only affects visibility of the feature. If it set to the fase, appropriate section will disappear in Tools & Settings -> Security policy and in plesk bin server_pref.

> Does this mean, that in the future the "plesk sbin mail_auth_view" will become obsolete.

As hashed passwords cannot be decrypted, mail_auth_view will unable to show plain password.

 

[GerdSchrewe]

Why do you confuse customers more and more with every update? Plesk is also used by many customers and non-experts as simple, easy-to-understand management software.
For quite some time now, I no longer perform updates automatically, but instead wait to see which bugs need to be fixed first—just like with the second-to-last update, when no website was accessible anymore (421 Misdirected Request).
Please check more carefully before releasing an update.
It would be better to release fewer updates and provide clearer explanations

 

[ChristophRo]

hmm, using hashed passwords but still advertising DIGEST-MD5/CRAM-MD5 screams for disaster....

...but so does disabling DIGEST-MD5/CRAM-MD5 on a server that is already "in use" by customers

 

[TorbHo]

One more question: what happens during a server migration to a new Plesk server where password hashing is enabled — will previously encrypted passwords be converted to hashes during migration, or will they remain encrypted until the next password change?

I couldn’t find anything about this behavior in the documentation: (Plesk for Linux) Enabling Mail Password Hashing

 

[Sebahat.hadzhi]

@TorbHo , thank you for the question. I will confirm with our team and I will follow-up as soon as possible.

 

[Sebahat.hadzhi]

@TorbHo , if the migration is performed through Plesk Migrator, the Storage method of passwords (hash or sym) for the migrated passwords will depend on the default method selected on the destination server. If the default method is hashing, then all migrated email account passwords will be hashed. If the sym method is selected, then the passwords will retain the same storage method as on the source server.

 

[TorbHo]

@Sebahat.hadzhi
Perfect, that’s exactly the behavior I was hoping for!
This way I can ensure the target server consistently uses the desired method without having to adjust anything manually after the migration.

 

[trialotto]

@mizar

This

As hashed passwords cannot be decrypted, mail_auth_view will unable to show plain password.

is not desirable.

I am not even sure which kind of hash is being used for password hashing - MD5, SHA1, SHA256, SHA512?!??


There should ALWAYS be a method of getting passwords in plain text.


It certainly is not the first time that forms to set / reset passwords are used to gain access to servers.

A hash of thousands of lines of codes can collide with the hash of a relatively short password.

No matter what kind of hash is being used, the simple fact is that collisions will always occur and more frequently with weak hashing.


Hashing is just like putting AMG tags on your Mercedes - it will not go faster if the engine is not the appropriate one.

So, what is happening under the hood is more important - the kind of hashing used AND a method to check wether the hash originates from a password!!


For that reason, I simply say that there should always be a tool of some kind that allows to check plain text input of passwords.

The mail_auth_view cli utility should not become obsolete when implementing or allowing for password hashing.

If the existence of mail_auth_view can only be preserved by disallowing password hashing, then so be it.

Better alternatives are present, such as a key-vault mechanism that preserves original key-value pairs.


I respect the choice of Plesk to implement password hashing.

However, I feel the obligation to point out that this choice is very very likely to cause future issues that will haunt the Plesk forum.

From migration issues to basic issues (for instance, lost access) to hacks.


Kind regards....

 

[trialotto]

@TorbHo , if the migration is performed through Plesk Migrator, the Storage method of passwords (hash or sym) for the migrated passwords will depend on the default method selected on the destination server. If the default method is hashing, then all migrated email account passwords will be hashed. If the sym method is selected, then the passwords will retain the same storage method as on the source server.

@Sebahat.hadzhi

This is not a definition of expected or desirable behavior.

If a destination / target server has a different password storage method (hash or sym), then the target server should honor the settings of the source server!

Migration of a source also means migration of the settings of the source.

Deviation from that golden rule can only be allowed if the target does not support a setting that is present on the source.

To be honest, I am really suprised by this "new" behavior of Migration Manager - it deviates from the golden rule applied by the Migration Manager : maintain source settings, unless really not possible.

Is there any inclination to change the behavior suggested and let the destination / target server honor the source settings?!??

Kind regards....

 

[Sebahat.hadzhi]

Thank you for your feedback, @trialotto . I will forward your concerns to our team for further review and discussion and I will double-check if there is a way around Migrator's behavior. Will follow-up with more details as soon as possible.

 

[Martin.B]

There should ALWAYS be a method of getting passwords in plain text.

I beg to differ: passwords should NEVER be saved in plaintext. It's just too dangerous in case the system gets compromised.


Despite that, unfortunately we had to revert back from hashing to symmetrically encryption on our systems, because we got massive problems with the mail clients (especially Outlook). Like authentication worked for IMAP, but failed for SMTP or vice-versa.
Looks like the feature isn'r really ready to be rolled out in public.

 

[ChristophRo]

I beg to differ: passwords should NEVER be saved in plaintext. It's just too dangerous in case the system gets compromised.

I do agree on this one!

Despite that, unfortunately we had to revert back from hashing to symmetrically encryption on our systems, because we got massive problems with the mail clients (especially Outlook). Like authentication worked for IMAP, but failed for SMTP or vice-versa.
Looks like the feature isn'r really ready to be rolled out in public.

Of course it will not work properly, the way Plesk rushed out this feature!
As I already wrote on the 20th of August, if a mailserver does advertise any of the MD5 authentication methods, certain mail clients (Outlook ahoy!) will randomly fail when the password of the account is stored encrypted on the server.

 

[Sebahat.hadzhi]

Despite that, unfortunately we had to revert back from hashing to symmetrically encryption on our systems, because we got massive problems with the mail clients (especially Outlook). Like authentication worked for IMAP, but failed for SMTP or vice-versa.
Looks like the feature isn'r really ready to be rolled out in public.

Thank you for the report. I will bring that to our team's attention. I tested an email setup in Outlook and it doesn't go as expected with password hashing. Still, I would really appreciate if you can share some more details on the circumstances in which you are experiencing issues. Thank you in advance.

 

[trialotto]

@Martin.B

This statement

I beg to differ: passwords should NEVER be saved in plaintext. It's just too dangerous in case the system gets compromised.

should, at least in my humble opinion, be more nuanced.

Sure, any password storage method that can be reverse engineered should not be chosen - this includes plaintext, encryption and weak hashes.

However, if and when a system actually gets compromised, then it does not make any difference.

For instance, a compromised system can be used to regenerate all passwords, hence making password storage methods completely irrelevant.

Even when a system does not get compromised fully, then it still is possible to do all kinds of tricks, depending on the state of vulnerability of the system and/or the method in which passwords are secured : encrypted passwords can be hacked and weak hashes can be reverse engineered.

In essence, the nuance is that it is never safe to store passwords locally, irregardless of the question whether a system is compromised or not.

A key-vault mechanism (preferably a remote one) will reduce risks considerably, but not complete take them away.

Another nuance might be that one needs to discuss the "level" at which passwords are secured, but that is another topic for another time.


This statement

Despite that, unfortunately we had to revert back from hashing to symmetrically encryption on our systems, because we got massive problems with the mail clients (especially Outlook).

is a typical "well, there you have it".

It is - essentially - a symptom of undesirable behavior.

Migrating (read: copying) data from a perfectly working source server should not be changed due to settings on the target server.

That is the world upside down!

And if the world is upside down, one gets odd symptoms - the source server works fine, but the target server does not respect the source server settings and overrides them with (not proven) settings : this is the root cause of the problem.

The symptoms of this disrespect for the source server settings are - for instance - that Outlook will cause havoc.

Sure, this also requires a nuance : it is Microsoft Outlook, so these symptoms are more likely to occur ;-)


Kind regards....