wordpress security concern (some measures taken but looking for expert opinion)

  • Hi everyone,
    As the topic suggest, i am having some security concern and am looking for advice as i am just a beginner in wordpress so any kind of insight is welcomed.

    i am currently managing a wordpress site hosted in A2 hosting where the client have stored customer information (mostly contact information) on individual wordpress pages. While i think this might not be the best approach, it’s how the system has been set up for now and they want me to ensure that these data is fully protected from unauthorized access, only the customer (whose information it is) and the admin( my client that is) should be able to access them. i have taken some measures to add security layers for the website in however way possible i can think of like restricted access to files (e.g. wp-config.php) using htaccess rules, blocked bots and search engines using robots.txt (though I know this has limitations) , some security hardening measures i have found like disabling xml-rpc, changing default login url, disable file editing, 2 factor authentications etc. i have tried a lot of things i have found on the internet. for firewall and malware, A2 hosting does claim to provide both (though I haven’t seen a firewall interface in the dashboard, the hosting provider insists it’s active). For a piece of mind, i have setup wordfence for application layer firewall and security.

    The client is specifically concerned about securing the database credentials stored in the wp-config.php file in plain text. I’ve applied appropriate file permissions and restricted access via .htaccess, but they want me to explore options for encrypting the database credentials as an extra layer of protection just in case someone got access to that file. my concern is that even if the credentials are encrypted, storing the decryption key in a secure but accessible place (like environment variables or another config file) seems to defeat the purpose since an attacker who gains access to the server could find both the key and the credentials (just my opinion that is, i don’t know if there is a viable solution). I’m looking for expert advice on whether encryption is a viable solution in this case or if there are better methods to protect the database credentials and overall site security for database security and page accessibility (i know we can password protect the pages, but my client doesn’t want that as they want their customers to be able to access them as well without much issue. it is what is it i guess). So any opinions and recommendations are welcomed.

Viewing 2 replies - 1 through 2 (of 2 total)

  • Make sure your database only accepts connections from the webserver. That will prevent external attacks directly to the database (like dictionary or brute force). I don’t know your hoster, but some hosters offer this options or even restrict it by default.

    If your WordPress system can access the database (whether the credentials is in plain text or somehow encrypted), then any attacker can also access the existing database connection via the WordPress functions, who can penetrate this WP system and execute PHP code. This can happen, for example, by taking over an administrator account or via a vulnerability in a theme or plugin – the classic attack vectors.

    Moderator Yui

    (@fierevere)

    永子

    database credentials should be accessible by WordPress, even if encrypted,, the encryption key should be stored somewhere. So its mostly just obfuscation, which is weak from the poing of security.
    Its up to host system administrators to firewall mysql tcp port or make mysqld listen on unix socket/localhost only

    You also can use credential-less way to authentificate, modern mysql/mariadb allows unix-socket authentification, same way as been supported by postgresql for long time. But this has security considerations too and not usable on some webhosts dependent on their PHP user control configs.

Viewing 2 replies - 1 through 2 (of 2 total)
  • You must be logged in to reply to this topic.