ClassicPress PetitionsClassicPress Petitions
This is a read-only archive. Post or comment on the live version of this page on our forums.

Generate random table prefix during installation

January 8, 2019 · 20:31 · Viktor Nagornyy

It's usually a recommended step to improve security, changing table prefix from wp_ to something random.

+6 more

Perhaps clarify that the prefix would only be generated if the user hasn't changed it from "wp_" (I'm pretty sure that's what you meant).

Viktor Nagornyy

This is for installation, so nothing has been set yet. Not migration.


You can set the table prefix for installation...

Viktor Nagornyy

The suggested prefix should be random. Typical users won't change it during installation.

Bart Kuijper

A randomized table prefix does nothing to increase security, this idea has been debunked years ago. When an attacker performs a succesful SQL injection, they can just as easily find out what table prefix is being used. For more details see

Viktor Nagornyy

If you take the time to read through comments of that post, there are examples of where changing prefix can help.

The biggest takeaway from that article is that you need a firewall to successfully block SQL injection attacks. Average users do not install any security plugins, let alone firewalls. They are wide open for attacks. Different prefix can provide a tiny protection from specific attacks for users that do not have firewalls on their websites.

Viktor Nagornyy
Bart Kuijper

"One more thing, it's still a recommended step to secure WP by OWASP"

Probably for the same reason every other security-oriented article recommends changing WordPress' database table prefix. It's become one of those things that everyone's recommending because everyone's recommending it and so many people can't be wrong, right?

I read through the comments to the article and found only 1 hypothetical example where it would work (well two actually, but they both boil down to the same single requirement). Having a non-default table prefix only offers protection against an attacker using a hard-coded default table prefix. Any half-decent exploit doen't rely on this. Once they have access to the database, finding all tables is trivial. Many tools (all the ones I've seen anyway, so this is anecdotal) are aimed at retrieving the entire database, not just the WordPress tables, in order to look for things such as email addresses, credit card details, etc.

In conclusion, the protection would be marginal at best and once a randomized table prefix becomes the new default, this marginal protection will disappear entirely as soon as the few badly coded scripts either become disused or are updated.

Changing the prefix is only really useful if you're running multiple WP installs on a single database. Other than that, it gives the illusion of safety, which I think outweighs the very minor potential benefit.