An account recovery/self-service password reset tool would be desired instead.
Where the account owner can provide challenge questions to reset their password, or
Use a linked facebook, or google account to prove account ownership.

Does using the facebook password module for authentication auto-sign someone in if they are logged into facebook? I haven't bothered setting it up to know.

Maybe, I say again mayyyybe a password sync/api tool where it could exchange the password securely and encrypted relaying it via TLS with another application (billing panel/forum software, helpdesk) on a password change/new account creation before it get's hashed. Even then, it would STILL be sketchy if the traffic gets intercepted, but this would be a notch above decryptable passwords. As a consumer I'd would want to know upfront if a concept like this was being used so I could make more informed decisions. (Might be suited for an addon pack $)

I vote NO! This is a very scary practice, to make it easier on the host provider. This opens some many possibilities for abuse, and creates a rather large security hole. I hope Plesk rethinks this.

I completely understand the thinking behind not wanting to display or decrypt passwords - However in the real world changing passwords for clients is often not a realistic option. Many of our users just can't understand how to use a new password from their login or FTP client or even email for that matter which means that our support team then have to re set a password to test an account for a client - After the password is re set the client has no clue about how to change it on their client app so we then have to remotely do it for them which is also not very secure

I fully disagree with the requestor of this feature. As explained at https://talk.plesk.com/threads/encrypt-email-passwords-even-for-root.343090/, it is a security issue if passwords are stored either as plain text or even if stored as a symetrically encrypted phrase. Thus, I fully argue agains this feature request but instead ask the Plesk developers to ONLY use one-way cryptographic functions to store passwords!

@Azurel, very good point! Ideally passwords should be un-decryptable by design (one-way hash).

I shall openly and frankly say that decryption of passwords isn't our intention at all and we will keep sticking to secure side. However we respect the pain of those who supported this request despite there are only few votes. So we are ready to listen for typical scenarios where password is needed and then consider alternative solutions for them.

Don't take it wrong - we are not going to even consider decryption tool, but we are ready to consider alternative solutions for scenarios where password is needed now.

For example:
- we are introducing one-time login "tickets" for the case when system administrator ("root") needed Plesk CP password - it will replace exposure of real CP password https://docs.plesk.com/en-US/17.0/cli-linux/plesk-utility.75661/
- for the case below (external system exposing password for its users), our recommendation is to process password in such system and then push changes into Plesk via Plesk XML API. Such external system would bear complete responsibility for password security then, but Plesk won't weaken its security.

We are ready to listen further cases and provide guidelines for them at our best capacity.
But there will be no built-in decryption facility

Decrypt a password is a BAD choice in many ways! When I get my plain password from a hoster, I would immediately quit, here is no trust in this service. A "Set a new password and send this him as mail"-function is better. When you can decrypt a password easily... why at all encrypt it?

I hope that this will be implemented soon.
For the previous versions, there was a commercial addon (Plesk Password Viewer) but that only worked on Non encrypted versions.

any update on this feature ?

A single page to be able to alter any password would be advantageous to people who work in the hosting industry and use Plesk every day.

Something along the lines of:

Select Domain

This will list all associated accounts for that domain in an table, the type of account it is and its current username. You can then change each one or bulk change them, with the option to email the new passwords to the account holder of the domain.

Can you confirm whether mailbox password can be fetched from even_handlers on creation of mailbox?

Hi Dave,

XML API for update is

<packet version="1.6.3.0">
<mail>
<update>
<set>
<filter>
<site-id>12</site-id>
<mailname>
<name>admin</name>
<password>
<value>123456</value>
<type>crypt</type>
</password>
</mailname>
</filter>
</set>
</update>
</mail>
</packet>

http://download1.parallels.com/Plesk/PP11/11.5/Doc/en-US/online/plesk-api-rpc/34509.htm

For event handlers catching password may be possible, please see here
http://download1.parallels.com/Plesk/PP11/11.5/Doc/en-US/online/plesk-administrator-guide/67897.htm#o67974

Hi Sergey,

Mailbox will already exist, so we need XML to just update the password.

Is there anyway to grab password with event handler when mailbox is being created?

Hi Dave,

Thanks for explaining your scenario in details.

Specifically for email, would it work if you pass the password in XML API like in the example here?

http://download1.parallels.com/Plesk/PP11/11.5/Doc/en-US/online/plesk-api-rpc/34502.htm

<?xml version="1.0" encoding="UTF-8"?>
<packet version="1.6.3.5">
<mail>
<create>
<filter>
<site-id>1</site-id>
<mailname>
<name>techdept</name>
<mailbox>
<enabled>true</enabled>
<quota>1024000</quota>
</mailbox>
<password>
<value>test123</value>
<type>plain</type>
</password>
</mailname>
</filter>
</create>
</mail>
</packet>

Plesk will automatically convert the password passed into crypted or hashed form depending on current implementation.

Example of what one of our clients might do:

1. Login to Plesk and create a mail account.
2. Login to Customer control panel and select add mail account to iphone.
- This would generate a mobileconfig (xml file) to install a profile on their phone.

Plesk 12:
3. Mobileconfig will no longer work, because we cannot grab the password due to encryption.

From what we can see the passwords are stored as AES encrypted, which means they can be decrypted. I understand the reason to store them encrypted but for root access to the server there should be a way to decrypt them.

You have a secret key stored in the psa directory so there must be a way to use this to decrypt them. As already mentioned, we have a complete customer control panel where out clients login and can see all their passwords and aswell as automatically set up mail accounts on iphones / ipads etc.. with a click of a button. This is now not possible because the mail passwords are encrypted.

If you still insist on not giving us a way to decrypt the passwords, then give us a way to encrypt them using xml