This is the crux of the article.

(1) Kerckhoffs's Principle doesn’t say that. It says to design the system AS IF the adversary has all of the info about it except the secrets (encryption key, certificates, etc).

(2) this rule is okay if you are a solo maintainer of a WordPress installation. It’s a problem if you work at a large company and part of the company knows the full intent of this, while the rest of the company doesn’t know the other layers of security BECAUSE of the obscurity layer. In this way, it’s important to communicate that this is only a layer and shouldn’t replace any other security decisions.

But it can add a bit of delay to someone breaking actual security, so maybe they'll hit the next target first as that is a touch easier. Though with the increasing automation of hole detection and exploitation, even that might stop being the case if it hasn't already.

The biggest problem with obscurity measures IMO is psychological: people tend to assume that the measures⁰ are far more effective than they actually are, so they might make less effort to verify that the proper security is done properly.

----

[0] like moving SSHd to a non-standard port¹

[1] a solution that can inconvenience your users more than attackers, and historically (in combination with exploiting a couple of bugs) actually made certain local non-root credential scanning attacks possible if you chose a high port

However "Not Having Stuff to Steal" works like a charm. It's thousands of years old, and has never gone out of style.

I know that it's considered blasphemy, hereabouts, but I've found that not collecting information that I don't absolutely need is pretty effective.

Even if someone knocks down all my gates and fences, they'll find the fox wasn't worth the chase.

It does make stuff like compiling metrics more of a pain, but that's my problem; not my users'.

One example I remember is Pidgin storing its passwords in plain text in $HOME. They could have encrypted them with some hardcoded string, and made a lot of people happy that they would no longer grep their $HOME and find their passwords right there. However this had the side effect that now people were dropping the ball and sharing their config files with others. Or forgetting to setup proper permissions for their $HOME, etc.

In addition, these layers of obscurity are also not overhead free: they may complicate debugging, hey may introduce dangerous dependencies, they may tie you to a vendor, they may reduce computing freedom (e.g. Secure Boot), etc.

Security ONLY through obscurity is bad (Kerckhoffs's Principle).

Security through obscurity, as an additional layer, is good!

I've been saying this ever since that phrase was coined. A layer or two of obscurity keeps a lot of noise out of logs, reduces alert fatigue and cuts down on storage costs especially if one is using Splunk as their SIEM and makes targeted attacks much easier to detect. I will keep it.

”Security including obscurity“ is fine.

It's a simple probability calculation. If some automated scanning tools can't find your service, a lot of attackers will never know of its existence. So even if it has an unpatched vulnerability, they won't attack it.

If 1000 attackers find the vulnerable system, the probability is high at least one is attacking it. If it's only or two one who find it, they might just ignore your system, because they found thousands of others they randomly chose first.

Obfuscating JS is probably a decent defence against your 9 year old brother. It is not against a motivated, well funded state sponsored attacker.

Part of what bugs me about English is the practical ambiguity of the colloquial understanding of what "<foo> is <bar>" implies. Does it mean that all foos are also bars or does it mean there exists a foo where that foo is also bar? Does it mean foo is always bad or foo is often bar? Dutch is my first language and I grew up in South Viet Nam, Nigeria and Texas. I did not get the standard programming.

If and only if the security advantage it gives outweighs the the numerous disadvantages.

It never* does. That's why the comment calling it bad got so many upvotes. Mixed in with those cargoculting the meme, are people like me who have had to deal with obfuscation techniques, written by someone else, that the bad guys understood before I did.

Obfuscation as a security measure is bad, because it feels like it's positives can compete with it's negatives; but that's rarely the case.

*: effectively never

Obscurity provides, effectively, no security. There may be other benefits to the obscurity, but considering the obscurity a layer of your security is bad. I hope we all agree that moving telnet to another port provides no security (it's easily sniffable, easily fingerprintable).

If it provides another benefit, use it, but don't think there's any security in it.

For ~30 years I've moved my ssh to a non-standard port. It quiets down the logs nicely, people aren't always knocking on the door. But it's not a component of my security: I still disable password auth, disable root login, and only use ssh keys for access. But considering it security is undeniably bad.

Valve pivoted to server-side anti-cheat and toleration because someone probably did the math on max(profit) with lootboxes.

>My website was vulnerable. However, I was not impacted by any attacks, and I updated the plugin to a patched version a few days later. While other sites were "nulled" and destroyed, I was spared. I later found a PoC script on GitHub showcasing the exploitation. Using that PoC on my own site failed with a generic error like Table 'wordpress.wp_users' doesn't exist.

The biological sciences fully support this form of protection. One of the main benefits of the whole of sexual reproduction is based on this principle. Mutations introduce diversity to populations which allows otherwise extinction events to just affect a fraction of the population.

So yeah, maybe the university of Open Source internet considers your approach to security to be baseless, but (in addition to your empirical experience), security through obscurity is well recognized in zoology.

Depending on the setting and the adversary, obscurity measures can raise costs by a material or immaterial amount.

Obscurity measures usually also impose costs on defenders (and, transitively, on the intended users of the system). Those costs are different than they are for adversaries (usually: substantially lower). They might or might not be material.

Your general goal is to asymmetrically raise costs on the adversary.

Seen that way, it's usually pretty easy to reason about whether obscurity is worth pursuing or not. Don't do it if it doesn't materially raise costs for attackers, or, even if it does, if it doesn't raise costs way less for defenders and users.

What trips people up in forums like this is that we're used to dealing with security problems framed in settings where we can impose \infty costs on attackers: foreclosing all known avenues of attack (to something like a mathematical certainty, and stipulating that computer science discoveries may change the cost function tomorrow). In those settings, all obscurity measures have relatively immaterial attacker costs associated. But it's still the same underlying problem! And, in the real world, we're actually rarely operating in model situations where we really can impose \infty costs on attackers.

In some ways this is not security through obscurity. If you don't have a way to enumerate tables, this is in effect another short password being added to the data. In the same way you could say that the "obscurity" of users' passwords is security through obscurity... except we still use passwords.

The idea of security through obscurity being bad stemmed from the idea that a cryptosystem should still be secure when you know how it works. That's all.

In that way, you know how WordPress works, and yet you don't have access. You know how passwords work, and yet don't have access.

Obfuscating code is interesting because it sort of sits between the two. You could execute the code, and you may know how the obfuscation scheme works, but you can't de-obfuscate easily and see the original intent, and that way it's useful. The fact that you can still execute the code does however limit the impact.

Obscurity is the information you need to find the safe.

All security can eventually be broken, given enough time, this is why A very useful measure for the security of a lock is how long it takes to break. The same is true for cryptography.

Obscurity can add a buffer before you can start breaking the lock and it can act as a deterrent for opportunistic attacks. Additionally it can help with signal to noise and monitoring of the lock.

This is why you have a lock on your front door and don't tell anyone you meet where exactly in your house you store your valuable jewels (preferably out of sight). You also want to monitor anyone in your garden more closely than on the road passing by.

It's always someone outside your org telling you that obscurity is bad, and that you should definitely publish all your source code to let them see.

It's self serving outside judgment to get you to provide them value.

On the other side of the coin, there is a bias towards this trope that comes from exhibitionism: those of us who hold that security through obscurity is valuable, will usually not publish our thoughts on other security mechanisms, since we will consider that doing so decreases our security, whereas those that believe in the trope, will publish all of their thoughts on security, as they do not depend on or value the secrecy of their strategies.

Obscurity increases the bar, and now, some actors will be prevented just by it, some delayed and some not affected at all, but after all you dont know who is attacking you and their skills!

That's not a serious argument, of course. But consider how the spooks operate in the field. They employ all manner of obscure practices in an attempt to improve their security. Their intentional obscurity (AFAIK) is never allowed to unnecessarily complicate operational practices, which would introduce risk. And they've probably got a lot more theory and no-BS field testing behind their practices than we do.

Maybe we should ask them for advice?

I wrote a blog about this: https://tanyaverma.sh/2026/03/01/nowhere-to-hide.html

But it is also a set of trade-offs and relationships between architectural components. It worries me that this isn't displayed in the interaction described in the post

For example, while I know that ssh bruteforcing bots won’t enter my server no matter how much they try, putting ssh on a non-standard port reduces the number of tries to zero.

Like moving ssh to a different port. If you are the only one working on it, sure fine, as long as you remember the port. If you re working with others, then everyone needs to know the new port, so it has to be documented somehow. It’s a pita

I recently did use a variation of this type of security to prevent a malicious user misusing our services... But I made a not to me an everyone else it was just a quick fix not guaranteed to work long term.

[0] https://web.archive.org/web/20201128060507/https://hot3eed.g...

   I am the Modern Man (Secret, secret, I've got a secret)
   Who hides behind a mask (Secret, secret, I've got a secret)
   So no one else can see (Secret, secret, I've got a secret)
   My true identity

The way how human brain works, anything that gives you the slightly sense of "security", will make you to leave as it is without implementing an actual solution.

That security by obscurity is now a security issue.

> There is a long-standing security recommendation to change WordPress's default database table prefix to a random one. For example, wp_users becomes wp_8df7b8_users. This is often dismissed as "worthless" because it is security through obscurity.

I found that just changing the default URL for the wordpress login from the usual wp-admin to anything reduces by several orders of magnitude the number of scripts that try your site for the most common vulnerabilities---something that happens constantly for any site on the web, once a minute or so.

concealment will make specific targeting -less than straightforward,but a scorched earth obliteration will get you along with all else.

cover, is a condition that is resistant to attack when you are visible.

you should have both, resistance to sequential action when you are specificly targeted, a obfusification of presence, minimizing the frequency of targeting.

That's why forcing people to use E-mail addresses as user IDs is stupid.

Like, a lot of it comes down to 'high friction' vs 'low friction'. Obscurity means high friction. It means that the attacker needs to craft a specific solution for your site or system in particular rather than relying on an off-the-shelf solution to handle it all for them.

For example, the article's point about changing the WordPress database prefix fits into this category perfectly. Does it really make things that much more 'secure'? No, of course not. But it does mean that automated scripts that just assume tables like wp_posts exist will fail. It means that an attacker can't just run any old WordPress hacking toolkit and watch it do its thing, they have to figure out what database prefix you're using first.

Same with antispam solutions. The best solution to stop spam is to make your site unique in some way. To add some sort of challenge that a new user has to overcome to use the site, like a question related to the topic, a honeypot field they can't fill in, a script that detects how quickly they register, etc.

This won't stop a determined spammer, but it will stop or delay bots and automated scripts that rely on the target system having the same behaviour across the board. The spammer has to specifically target your site in particular, not just every forum script running the same software.

And much of society works this way to a degree. A federated or decentralised system (whether a social network or political movement) isn't technically harder to attack than a centralised one might be.

But it is more work to attack it. If a government or company wants to censor Reddit or Discord or YouTube, they have one target they can force to censor information across the board. If they want to target the Fediverse or some sort of torrent based system, then they have to track down dozens of people and deal with at least some of those people refusing or taking it to court or being in countries that aren't under their control or whatever else.

That's kinda what a good security through obscurity setup can be. You can't mass target everyone at once, you have to target different systems individually and spend more time and resources in the process.

However, you still need real security measures there. Security through obscurity is like hiding a safe behind a painting. It'll stop casual attackers from finding it, but it won't stop a targeted attack on its own. You need a strong lock, materials that are difficult to drill through and the safe itself being difficult to remove from the wall too.

Mom & Pop code shops might be high risk if nation-state level vulnerability-exploitation becomes economically viable to any disgruntled prick.

Yes, echo chambers are annoying - I remember this when I challenged them by explaining to me why being superuser is problematic (hint: I countered their arguments easily, then they got very angry about this; I did this on several IRC channels back in the day, just to prove a point. I managed to get banned on one too in the process.)

But ... obscurity is NOT a security technique. It just has a catchy slogan.

The primary reason why javascript is sometimes - or often - obfuscated is to make it harder to copy/paste and re-use stuff. That's it. Even with sanitizers, de-obfuscating it tends to increase the amount of time one has to spend to uncripple the code. This is the primary function; anything else is just decoy for the most part here.

> Security through obscurity is the practice of reducing exposure by keeping an application's inner workings or implementation details less visible to attackers

Very clearly his attempt to explain it, is already biased. Is obfuscating JavaScript security through obscurity? I mean if we can not agree to the terms, we can't agree or disagree on anything that follows.

Showing fancy images does not add any real argument to the discussion.

> For example, wp_users becomes wp_8df7b8_users. This is often dismissed as "worthless" because it is security through obscurity.

Note that this example does not even follow his own (!!!) definition.

This has nothing to do with obscurity. It simply is another name than the default login name. What would he expect of people to do? Retain the name? And if they change it, are ALL changes in his opinion valid to "security through obscurity"? He picked wp_8df7b8_users here. Is the name "foobar" instead a better name? Or is it "not obscure enough"?