• Our team is looking to connect with folks who use email services provided by Plesk, or a premium service. If you'd like to be part of the discovery process and share your experiences, we invite you to complete this short screening survey. If your responses match the persona we are looking for, you'll receive a link to schedule a call at your convenience. We look forward to hearing from you!
  • The BIND DNS server has already been deprecated and removed from Plesk for Windows.
    If a Plesk for Windows server is still using BIND, the upgrade to Plesk Obsidian 18.0.70 will be unavailable until the administrator switches the DNS server to Microsoft DNS. We strongly recommend transitioning to Microsoft DNS within the next 6 weeks, before the Plesk 18.0.70 release.
  • The Horde component is removed from Plesk Installer. We recommend switching to another webmail software supported in Plesk.

Questions regarding enhanced security mode

Bevan

Basic Pleskian
Hi!

I just enabled the enhanced security mode as one of my longest wished features. Thanks for implementing it :)
Now I have a few questions about the detailed functionality:

1. Passwords stored in the accounts table with type "sym" (passwords beginning with "$AES-128-CBC$") and the password in /etc/psa/.psa.shadow are encrypted using the key in /etc/psa/private/secret_key. Is that correct?

2. What are those passwords with type "crypt" in the accounts table? Are those hashed values and if so: what hashing algorithm is used?

3. There are still several unencrypted password in the accounts table, whose type is 'plain'. To what kind of account do those passwords belong and is there a way to encrypt those, too? I wasn't able to find any reference to those account_id's in the database.

Thank you in advance!

Michael
 
2. man 3 crypt
3. Since there are no references to these entries in accounts table, this must be some leftover junk (probably from old non-critical errors). This also explains why they are still plain.
 
2. man 3 crypt
That was the hint I needed. So what I have here is salted SHA-256. :)

3. Since there are no references to these entries in accounts table, this must be some leftover junk (probably from old non-critical errors). This also explains why they are still plain.
If all references to the accounts table are called "account_id" there are no references. I will have another close look at it and then remove those entries (after a backup of course).

Thanks for your reply!

---
edit: I double checked with the following query that gave me exactly those unencrypted accounts:
SELECT * FROM accounts WHERE
id NOT IN (SELECT account_id FROM clients) AND
id NOT IN (SELECT account_id FROM db_users) AND
id NOT IN (SELECT account_id FROM dom_level_usrs) AND
id NOT IN (SELECT account_id FROM mail) AND
id NOT IN (SELECT account_id FROM pd_users) AND
id NOT IN (SELECT account_id FROM sys_users)
After that I deleted those accounts. Until now I can't see any problems. If there occur any in future I will report it here.
 
Last edited:
Back
Top