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.
> 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.
> Security ONLY through obscurity is bad (Kerckhoffs's Principle).
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.
Regarding Counterstrike (game) example, there were already a lot of cheaters and a cheater ecosystem that still exists to this day. I suspect Valve could address it if it wanted to, but the gameplay/development cost trade-offs aren't enough.
Valve pivoted to server-side anti-cheat and toleration because someone probably did the math on max(profit) with lootboxes.
Cryptography is "just" a mathematically sophisticated version of manufacturing obscurity, so that's missing the point a bit. Obscurity is just information asymmetry, which is the only way we have to "secure" / anchor anything. That quote is about all the other forms of manufactured obscurity not being anywhere near as rigorous, which should be obvious.
The problem with this argument is that you can justify an infinite amount of crap with it, the security equivalent of cockroach papers; which inevitably people ends up treating as real security.
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.
Secret storage isn't considered "security through obscurity". Everyone knows that when you find the key to the door, you've won. Security through obscurity is more like hiding the keyhole: it isn't going to stop anyone determined, but it can be effective against someone who isn't all that motivated (well, all that motivated to target you, anyway).
Yeah, security through obscurity as part of securing a system is good. Security through obscurity as the only way of securing a system is not.
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.
Security which has layers of obscurity can be incredibly powerful especially if you believe in counter intelligence. You want attackers to find the wrong key sometimes because it will lead to you collecting intelligence on them. But this increases the cost in time and infrastructure.
That isn't what the article is talking about. He is literally talking about running the JS code through an obfuscator and changing the default DB schema name. That isn't security and you know it.
I get what this post is saying, but I'm going to push back that "security through obscurity" isn't just something that people parrot without understanding.
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.
I want to add that Obscurity is ambiguous.
Is changing the port of SSH "obscurity"?
Some may say yes, because you could find it by bruteforce.
But a password with infinite attempts can also be bruteforced.
Here, the defining factor of security is maximum number of attempts (either on ports, username or whatever).
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
The delay can also be infinite in practice. If a really bad zero day is discovered, it might protect you from becoming a victim. No guarantees, but it can improve your chances.
The other thing though is that there are situations where you only have a limited amount of tries for a password, and incorrect tries can have dire consequences. If you are being asked for a password by an armed guard, and you hack the system completely and get the password, but didn't know about the last obscured step that you were supposed to type it with your left hand, not your right, you will still face whatever consequences even though that step didn't add any security.
Obscurity can be combined with security for much better results. Machines as well as AI in extension thrives off patterns and making illogical off-pattern decisions is usually to the benefit of the defender, not the attacker. As you said, the attacker has a wide attack surface to cover while the defender only has to fortify his home NAT. E.g. port knocking may very well throw off the hoard of scanners on the wide net simply because its not standart and the combination is known only to you. Similarly, fail2ban may not work as well on a standart SSH port, because every attacker is going to hammer that and one may get your misconfigured password root login right.
Now, in both instances, the obscurity provided does not necessarily cure your infrastructure's vulnerabilities, a dedicated attacker wouldn't have a single problem with either of these. But for someone who hammers the whole internet in a dim hope of finding another Wordpress server from 2017, or the latest flawed online security cam, your disguise is as good as perfect.
I have always replied to colleagues who poohpoohed "security through obscurity!" as if it was proof of ignorance or bad culture with "a password is just a string of obscure characters. ;-)"
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.
It's useless for the example given because obfuscating JavaScript as protection no longer has any purpose, if you can let AI analyze the code, and/or in this case the API requests.
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.
My take: Do proper security, but if you are short on time or resources, you can start with security through obscurity, to block a few percentage of attacks, and then when you have time and resources, go ahead and add the proper security measures.
I could see AI massively changing the calculus here. Its ability to hack and reverse-engineer (even obfuscated) artifacts may leave obscurity (read: not sharing code or binaries at all) as the primary security mechanism in the industry.
This was largely true before. But AI reduces the cost of comprehension and finding vulnerabilities en-masse to zero, so this no longer holds, and I’m increasingly convinced that hiding in noise and complexity is no longer a valid strategy. But AI symmetrically makes it easier to secure your system so it’s not like all hope is lost even if the transition period will be brutal.
Obscurity can be fine but it's not security. I think of it like cover and concealment in the military. Security is cover. Something you can get behind so the bullets don't hit you. Obscurity is concealment. Harder to see, harder to find, so the enemy doesn't know where to shoot, but it's not stopping any bullets. Both have advantages and disadvantages and can complement each other depending on how they're used.
All security is security through obscurity. When it gets obscure enough we call it “public key cryptography”. Guess the 2048-bit prime number I'm thinking of and win a fabulous prize! (access to all of my data)
Agreed with your sentiment, and that was a great example.
Just like any security control, if it's your only means of security, it will not offer much risk reduction. Just like all security controls, the if you want risk reduction use more security controls together. Like all security controls, there is no way to eliminate risk, just reduce it as much as possible while still being able to effectively achieve your mission.
Because of this I believe security through obscurity to be important component in a healthy and mature risk posture.
It irks me when it's dismissed because obscurity is not security. No single security control is security on its own.
The problem with that statement is that a lot of people who yield it fail to see the advantages that come with these extra shenanigans ; and let's just take pure concealment so I don't pushing weird arguments ; in the age of AI - each time we are able make an attacking AI misaligned we are essentially buying time ; an on-going attack is never a on-shot event ; it's an ongoing process where the attacker has to understand where it is located and what it can do ; since each element will be a resource ; do not let it have it in the first place.
It's a bit of an elitist view of security that romanticize concepts without thinking about what they can actually be used for. My personal bad experience with that was a manager who was stating me that having a different subdomain for the admin panel was a concealment and not a security practice.
I mean - it's very easy to see how this kind of argument actually prevents from doing something that can help just on the basis of philosophical purity - which often just miss the point - security is not a mechanism that will solve all your problems ; heck in fact I have to layer at least 4 mechanisms just on the http interface to feel safe ; it's more of a lot of layers that together form a barrier ;
We sit too much on TLS thinking "That's it, security job is done" - then we get some crazy stuff like French ANTS that get pawned with some IDOR ; as IF f* using some hash or something ; ANYTHING PLEASE F* HELL ; would have not helped
Example: there are teenage gangs going around on high powered scooters in my city, carrying hammers and mini grinders. They pair up on a scooter, steal a bike and disappear.
I watched them. They don't want to hang around longer than necessary. They will only approach a bike rack that is clearly visible from the road. They will only steal a bike that has unobstructed access to the road (no tricky bollards or other bikes to get around). Even though they are full of bravado, and shout obscenities and threats at me when I tell them to fuck off, they still run away (even though the one approaching the bikes is carrying a weapon while his companion stays on the scooter ready to escape)
Anything that even mildly inconveniences these guys is enough to stop them attempting theft. The bikes they steal needs to be expensive, out in the open, with direct access to the road, and with a shitty lock. And believe it or not, those tumblers line up a lot.
Throwing a blanket over a bike is probably enough to stop them from even approaching it.
That's fine as long you are really clear in your mind about what's going on.
It IT there are a lot of people tossing a blanket over the scooter and believing they're affecting the ability of the the attacker when they're really changing the likelihood of an attack.
Imagine if every single person put a blanket over their bike. Now imagine if everyone got a chain that was 10 times stronger. Which world would you rather live in?
Security through obscurity is mitigation basically. You reduce risk/impact, not eliminate it. There are problems - such as denial of wallet attacks - where you can only mitigate and can't eliminate the problem completely
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"?
88 comments
[ 2.8 ms ] story [ 95.5 ms ] threadSecurity 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.
> 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.
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.
Might give you enough time to change the locks. But not provably — which can matter to a lot of people.
Valve pivoted to server-side anti-cheat and toleration because someone probably did the math on max(profit) with lootboxes.
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.
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.
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.
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
The delay can also be infinite in practice. If a really bad zero day is discovered, it might protect you from becoming a victim. No guarantees, but it can improve your chances.
Now, in both instances, the obscurity provided does not necessarily cure your infrastructure's vulnerabilities, a dedicated attacker wouldn't have a single problem with either of these. But for someone who hammers the whole internet in a dim hope of finding another Wordpress server from 2017, or the latest flawed online security cam, your disguise is as good as perfect.
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 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.
I wrote a blog about this: https://tanyaverma.sh/2026/03/01/nowhere-to-hide.html
Ideally we want a viable plan B, for when it’s leaked/figured out. (E.g. generate new passwords)
(For convenience let’s label air-gap as kind of physical security)
"The Integrated Survivability Onion"
https://cogecog.com/the-threat-onion/
1. Don't be seen.
2. Don't be acquired
3. Don't be hit
4. Don't be penetrated
5. Don't be killed
It's actually not a bad mental model training aid for teaching people who might find themselves in an active combat environment.
if you were hiding in cover during ww1, maybe you had a chance.
But if you were hiding from the Terminator, who is "Tireless, Fearless, Merciless", it might not last that long.
same might be said of exploits hiding from people... vs AI.
All security is security through obscurity. When it gets obscure enough we call it “public key cryptography”. Guess the 2048-bit prime number I'm thinking of and win a fabulous prize! (access to all of my data)
Asking because of the Baader–Meinhof phenomenon :)
Just like any security control, if it's your only means of security, it will not offer much risk reduction. Just like all security controls, the if you want risk reduction use more security controls together. Like all security controls, there is no way to eliminate risk, just reduce it as much as possible while still being able to effectively achieve your mission.
Because of this I believe security through obscurity to be important component in a healthy and mature risk posture.
It irks me when it's dismissed because obscurity is not security. No single security control is security on its own.
It's a bit of an elitist view of security that romanticize concepts without thinking about what they can actually be used for. My personal bad experience with that was a manager who was stating me that having a different subdomain for the admin panel was a concealment and not a security practice.
I mean - it's very easy to see how this kind of argument actually prevents from doing something that can help just on the basis of philosophical purity - which often just miss the point - security is not a mechanism that will solve all your problems ; heck in fact I have to layer at least 4 mechanisms just on the http interface to feel safe ; it's more of a lot of layers that together form a barrier ;
We sit too much on TLS thinking "That's it, security job is done" - then we get some crazy stuff like French ANTS that get pawned with some IDOR ; as IF f* using some hash or something ; ANYTHING PLEASE F* HELL ; would have not helped
Obscurity alone isn't security. Security that includes obscurity in it's architecture is relevant.
I watched them. They don't want to hang around longer than necessary. They will only approach a bike rack that is clearly visible from the road. They will only steal a bike that has unobstructed access to the road (no tricky bollards or other bikes to get around). Even though they are full of bravado, and shout obscenities and threats at me when I tell them to fuck off, they still run away (even though the one approaching the bikes is carrying a weapon while his companion stays on the scooter ready to escape)
Anything that even mildly inconveniences these guys is enough to stop them attempting theft. The bikes they steal needs to be expensive, out in the open, with direct access to the road, and with a shitty lock. And believe it or not, those tumblers line up a lot.
Throwing a blanket over a bike is probably enough to stop them from even approaching it.
It IT there are a lot of people tossing a blanket over the scooter and believing they're affecting the ability of the the attacker when they're really changing the likelihood of an attack.
Imagine if every single person put a blanket over their bike. Now imagine if everyone got a chain that was 10 times stronger. Which world would you rather live in?
Obscurity is decreasingly effective as more people use it. Security is more effective as more people use it.
You literally just read how Obscurity protected OP in a cybersecurity incident. Now you are just playing word games, which are a waste of time.
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"?