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.

Admin

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.

Database

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.

WordPress installation - old version

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".

Poor login for the administrator

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:

The same database name and its user

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.

prefixes in tables set to standard wp_

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.

WordPress auto-installer - latest version

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 🙂 .

WordPress auto-installer random user

Database

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.

complex database, user and prefix names

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:

additional security measures

You can implement further security measures suggested by the autoinstaller yourself with a click of the mouse. You can undo them if necessary:

additional safety measures for manual activation

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.

Summary

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.

Share

See also

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!

JivoChat lifetime offer
JivoChat

One of the best chat rooms for websites. Mature with lots of...

Scalify LTD
Scalify

Create ads, publish them and increase conversions for Facebook campaigns,...

Leave a Reply

Your email address will not be published. Required fields are marked *