A significant number of WordPress professionals strongly advise against using auto-installers to launch a site running on this CMS. Why?
In principle, the answer to this question is not difficult. Those who warn against the consequences of using auto-installers consider first of all the security of our future website. The immense, almost unbelievable popularity of WordPress makes it a catch-all for all sorts of hackers, who mercilessly exploit symptoms of ignorance, unawareness and carelessness. That's why it's so important to take care of security from the very beginning, which many auto-installers effectively make difficult.
Why do we say no to auto-installers?
First of all, because most of them use established schams, which is what burglars expect in the first place.
Some time ago, WordPress offered us a standard "admin" admin login during the installation process. As a consequence, the vast majority of sites had and still have exactly that user. So there is a very good chance that if you browse one or another site running on WordPress you will also find a user with admin rights with the login "admin". Well, if this is the case, then if you were a burglar at the start you would have an easy task. You would only have to crack the password, the username is given to you on a platter.
Despite the fact that the WordPress installer does not currently suggest this username, a great many auto-installers still do, and beginners take it at face value and do not change this login. Because: If the hosting provider's system suggests it, it probably should be, they know better than I do after all.
This is also a common problem with a significant proportion of autoinstallers, which generate the database name and user in a predictable way. Fortunately, this factor is disappearing, although it is still possible to come across autoinstallers that generate an identical database name and user.
Additionally, giving default prefixes to database tables is a problem. This prefix has a form of "wp_" and it is another element, which burglars expect. In other words, if we use such a prefix, we make that the intruder will know exactly the map of tables in our database and thus we make it easier for him to launch attacks, which in some circumstances may end up in success to our despair.
Are all auto-installers evil?
To a large extent hosting companies offer quite primitive tools for automatic installation of WordPress. I decided to check how it currently looks like for one of the biggest players on our market home.pl. To analyze the topic I chose a special series of hosting services, at least in theory dedicated to WordPress. The cost of such service (not counting the promotional campaign) starts from 500 PLN net / year, and if we would like to run SSL certificate, such account will cost us 620 PLN net per year (51,66 PLN net per month).
After ordering the service, WordPress was automatically installed on it, and here it is interesting that it is version 4.9.8, while we already have WordPress 5.1. So you can see that the system is probably installed from the local repository, where version 4.9.8 is still waiting. Of course, this is not a problem, because after a while the CMS updated itself to version 4.9.9 and informed that version 5.1 is also available. I could have updated manually, but the question is how many beginners will do it?
Out of curiosity I ran the second instance installation process manually in the hope that I might find the latest WP version, but unfortunately it turned out that the auto-installer actually offers the old version 4.9.8 for the moment. For this I selected a set of plugins to install. In total the autoinstaller installed 10 of which 8 were old versions that needed updating.
OK, so I took a peek at the next configuration parameters for the new instance. The default login is of course admin. I could change that, but I might as well move on thinking that's how it's supposed to be. Besides, the default WordPress installation that went live immediately after ordering the service didn't give me a chance to decide. I received an email with login details and of course the admin login as you can probably guess was "admin".
During the installation process I had no possibility to interfere with the database name. So I checked what was created. It consists of two parts. The first is a constant identifier, and the second appears to be randomly generated. And here it is OK, although one could have doubts whether giving identical name to the database and its user is a good direction. In this case it is:
Moving on I checked the prefixes of the database tables that had been created. Unfortunately my fears were confirmed. The prefix used is the standard, trite "wp_", so everyone knows the names of all my WordPress tables from the get go. Unfortunately, I didn't have the option to define my own prefix during the installation process.
For a service that costs 500 PLN net or over 600 PLN per year and is a service supposedly dedicated to WordPress I would expect something more. Unfortunately, this auto-installer is a textbook example that can be successfully used by opponents of WordPress auto-installation mechanisms.
A significant number of hosting companies serve us such auto-installers, so it's no surprise that the community of people specializing in WordPress and its security strongly advises against this form of installation. So if you decide to get hosting from one of these companies, let go of the auto-installer. Do the installation manually, which is not a complicated process and will allow you to properly secure the foundation for your future website.
However, it is possible to do otherwise
Fortunately, there are hosting services that care about WordPress users and provide such automatic installation tools that allow us to completely customize the process and, consequently, the underlying architecture of our future site. These include hosting platforms such as Kinsta , WPEngine, A2 hosting and others. Also our hosting services for WordPress They offer a completely different level. Let us take a look at them.
After running the auto-installer, by default the system sets the installation so that our future site uses an SSL certificate (https protocol). The WordPress version is not installed from the local repository of the hosting, which results in old versions of this system as in our example above, but the installation is initiated each time from the main WP repository, thanks to which we install the newest version of the CMS available at a given moment.
We say NO to admin
The system will not suggest you a common, well-known name of the main administrator site. The suggestion will be there, but it will be generated randomly making the login string hard to break. Don't modify it, unless you want to make it even more complicated 🙂 .
The database section does not even need to be developed because here too the data will be generated randomly. What is also important is the very fact that we have influence on the prefix, the name of the database and its user. The database name and its user are not only appropriately complex, but also different from each other, and the prefix itself, is a randomly generated string, which as with the rest of the data will be difficult to guess.
However, that is not all. We also have the option to implement mechanisms to automatically update both WordPress itself as well as plugins and themes, and going one step further, the auto-installer will analyse and implement security measures on a good day. Here are some of them:
You can implement further security measures suggested by the autoinstaller yourself with a click of the mouse. You can undo them if necessary:
The differences between the auto-installers of at least the two I showed are huge. On one hand you have very basic mechanisms, which basically give you nothing but time savings, but at the same time unnecessarily expose you to negative consequences of attacks. On the other hand, they actually make sure that your future website is properly configured and protected from the very beginning.
If I were to address the question posed in the title of this article. Is that autoinstallers are evil? I would probably confirm such an opinion analysing many such tools available on the market. However, generalising in this field is a step too far. As you can see, there are tools that give you an excellent foundation and not only when it comes to the basic configuration like "don't serve me admin login" or "don't use wp_ prefix in table names", but they also allow you to implement additional security measures, which you can't find in vain on most hosting services. Including - horror of horrors - on those that call themselves "WordPress Hosting". If you are interested in hosting accounts that have specific tools on board both when it comes to the auto-installer as well as those that allow you to manage your WordPress instances later on, check them out at: WordPress hosting.
Since this morning I have been waiting for the moment when I can share with you the information about the "interesting" event that took place yesterday: 28 March 2021. Only
Websites running on WordPress and WooCommerce, or in short online shops (how to set up an online shop), have significantly higher security priorities than other
Probably everything has been written about website security on the Internet and in books, but unfortunately only a small proportion of blog, website and shop owners take the trouble to analyse this
Free information on JZS news
I invite you to become a subscriber! Thousands of readers already subscribe to news from JZS.
You can unsubscribe at any time. Your address is safe here.
Featured LifeTime Offers!
One of the best chat rooms for websites. Mature with lots of...
Create ads, publish them and increase conversions for Facebook campaigns,...
Collect opinions about your products or services also in the form of...