Generate random table prefix during installation

[discobot]

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

---

Read-only archive: Issues · ClassicPress/ClassicPress · GitHub

Author: Viktor Nagornyy

Vote count: 12

Status: open

---

Comments

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

~ posted by Wells

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

~ posted by Viktor Nagornyy

You can set the table prefix for installation…

~ posted by Wells

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

~ posted by Viktor Nagornyy

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 WordPress Table Prefix: Changing It Does Nothing to Improve Security

~ posted by Bart Kuijper

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.

~ posted by Viktor Nagornyy

One more thing, it’s still a recommended step to secure WP by OWASP:
OWASP Wordpress Security Implementation Guideline - OWASP

~ posted by Viktor Nagornyy

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

~ posted by Bart Kuijper

[anon66243189]

The prefix can be chosen by all major aided installs such as softacoulos and also easily altered else how by simply setting the prefix during install, WordPress Tutorial => Set a custom prefix for WordPress tables

I don’t see the need to add the code for this which basically won’t do much more than add an already available feature but micromanage it.

Considering benefit versus work required the work required is more than the benefit

A notice on the installs screen that a “custom prefix might aid security” would be less work and do the same - yet as others pointed out security wise this is really little to no betterment.

[anon71687268]

Yeah, there’s really no security benefit in changing the prefix; it is trivial to retrieve anyway, no matter what it is.

[anon95694377]

I always change the prefix, but not for security reasons: it just helps me remember what I’m looking at when I’ve got a database open in Sequel Ace.

So I appreciate being able to set it, but I don’t think there are additional benefits in randomising it. As noted above, there’s no security impact.

[anon98749105]

Really? There’s no security benefit at all?!!

Shouldn’t have listened then to this advice of changing the table prefix.

[anon71687268]

It’s like removing the ClassicPress/WordPress version number. Somewhere along the line, someone decided it was a security measure and, in time, it became such widespread conventional wisdom that even security plugins built a setting for it. These days, we know better.

[anon66243189]

I think we all will trust the “experts”

WordPress Table Prefix: Changing It Does Nothing to Improve Security

I think with this and all comments above this can be set to auto destruction within 7 days…

[anon66243189]

It doesn’t hurt renaming it - but the purpose isn’t security

Rather organization.
So once you’ll have many databases in your server it’ll benefit you