Email Passwords hashed! how to retrive email password in plesk 11.0.9

[FatanehE]

Hi to all,

I bought new dedicated server, with centos, I installed Plesk 11.0.9
I want to retrieve emails passwords with query in mysql but passwords are hashed,
I have another server with plesk 10 and passwords aren't hashed and I can find them easily.

how to prevent to hashed password in plesk database?

Thanks

 

[IgorG]

Hint: Backup your domain and find mailbox passwords in backup XML file.

 

[Nikolay.]

Hint: mail_auth_view utility.

 

[FatanehE]

Where is location of XML file?
and I want passwords for every week.

 

[FatanehE]

Hint: mail_auth_view utility.

how does it work?
is there any way to cancel hashed passwords?

 

[Nikolay.]

how does it work?

Just run it and you'll see. You need to be root, obviously.

is there any way to cancel hashed passwords?

No, you cannot turn off enhanced security mode off.


BTW, why do you need passwords in the plain form?

 

[FatanehE]

BTW, why do you need passwords in the plain form?

this server is hosting type.
we check all password every week because very persons use weak password and our server is going to hack.
also I want to have password of databases for export and ,,,,

but why does in my old server password didn't hash??!!

 

[Nikolay.]

but why does in my old server password didn't hash??!!

I guess because it was an older Plesk version.


You'll probably be pleased to know that in Plesk 11.5 server-wide password security policy (minimum complexity) applies to mail passwords as well.

 

[Sven L.]

You'll probably be pleased to know that in Plesk 11.5 server-wide password security policy (minimum complexity) applies to mail passwords as well.

this is all nice and fancy, but what if i transfer domains hosted in 9.5.4 to a 11.5 (because that's my upgrade plan)? what will happen to currently lowsec passwords? i can't just change passwords of 1000s of mailboxes, it will drive my users crazy and my users will drive ME crazy...

 

[Nikolay.]

Policy obviously applies only to new passwords, at least for mail passwords. So... nothing bad will happen.

 

[BoMbY]

Hint: Backup your domain and find mailbox passwords in backup XML file.

Wait, what? Are you just saying the passwords aren't stored securely (salted hash), or as plain text in a secondary location?

 

[FatanehE]

Wait, what? Are you just saying the passwords aren't stored securely (salted hash), or as plain text in a secondary location?

Yes, I want to see passwords,

 

[FatanehE]

Hint: Backup your domain and find mailbox passwords in backup XML file.

where is its (XML file) location file?

 

[IgorG]

http://kb.parallels.com/5816

 

[FatanehE]

http://kb.parallels.com/5816

what a bout mysql password's databases? in plesk 10 I could see passwords in psa database with query. how do I check it new version?

 

[Nikolay.]

what a bout mysql password's databases? in plesk 10 I could see passwords in psa database with query. how do I check it new version?

What about 'em?

Why would you need to see your customers' passwords?

 

[Sven L.]

What about 'em?

Why would you need to see your customers' passwords?

well, I am at the same time server admin and helpdesk for all those who have accounts, webs, emails, whatever on my server, so I can see where he is coming from.

however I usually am the one who actually creates all those passwords, so I document them in a secure storage I have at home and can check them whenever needed.


what worries me most is this:
for what I have understood, passwords should now be secure, yet they are stored in plaintext in the backup XML? that's a security problem right there, or?

 

[FatanehE]

What about 'em?

Why would you need to see your customers' passwords?

for Import and export by command line we need to know passwords,

 

[IgorG]

Guys, sorry for my mistake. Xml backup contains encrypted passwords. They are encrypted with server's key. Correct answer is using /usr/local/psa/admin/bin/mail_auth_view utility. For example:

mysql> select mail_name,name,password from mail left join domains on mail.dom_id = domains.id inner join accounts where mail.account_id = accounts.id and postbox='true' order by name asc, mail_name asc;
+-----------+------------+----------------------------------------------------------------+
| mail_name | name | password |
+-----------+------------+----------------------------------------------------------------+
| rt | tttest.gov | $AES-128-CBC$f9qDGZ0SZqJv3yoUd8pMSA==$uoVzaIWEz/dDyy6Nglf7mw== |
+-----------+------------+----------------------------------------------------------------+
1 row in set (0.00 sec)

# /usr/local/psa/admin/bin/mail_auth_view
Authentication database contents:
+--------------------------------------+-----+--------------------------------------+
| address |flags| password |
+--------------------------------------+-----+--------------------------------------+
| [email protected] | | vbn321 |
+--------------------------------------+-----+--------------------------------------+
Flags
A - account disabled
D - domain disabled
E - password encrypted

 

[MislavO]

well, I am at the same time server admin and helpdesk for all those who have accounts, webs, emails, whatever on my server, so I can see where he is coming from.

however I usually am the one who actually creates all those passwords, so I document them in a secure storage I have at home and can check them whenever needed.

I'm working as well as system/server admin and helpdesk but I've never come to idea to store clients DB pass. I mean, if problem occurs, you can always find, with you knowledge as server admin, db password in plain text under his domain, you just have to search for it. As simple as that is. Don't take that big responsibilty on yourself, if client forgot password just say, we don't store your password and change it too the new one, explain them how to change it by themself in future and that's it. If they will think all the time you have their password for email, it will be like, OOO YOU ARE STALKING US, reading all my bussiness emails....and you just don't want to end there and go with that conversation with your client. I mean, if you're really bad, you can always change pass in the panel and do what ever you want.

So yeah...I don't like this at all nor I'm supporting this.