Security by obscurity is underrated
utkusen.com
utkusen.com
People have been misinterpreting "security by obscurity is bad" to mean any obscurity and obfuscation is bad. Instead it was originally meant as "if your only security is obscurity, it's bad".
Many serious real-world scenarios do use obscurity as an additional layer. If only because sometimes, you know that a dedicated attacker will be able to breach, what you are looking for is to delay them as much as possible, and make a successful attack take enough time that it's not relevant anymore when it's broken.
I think we can kind of view obscurity in the same way. It's a way to signal to a predator that we're a hard target and that they should give up.
Of course in the age of automation, relying on obscurity alone is foolish because once someone has automated an attack that defeats the obscurity, then it is little or no effort for an attacker to bypass it.
Of course, sprinkling a little bit of obscurity on top of a good security solution might provide an incentive for attackers to go someplace else. And I can't help but think of the guy who was trying to think of ways to perform psychological attacks against reverse engineerers [2].
This has it completely backwards. Security through obscurity's goal is not to signal predators, it's the opposite. The goal is to obscure, to hide. The "signal" is there is nothing here (or nothing here worth your time). One of the best examples (it's in the article!) is changing the default SSH port. Just by obscuring your port you can usually filter out the majority of break-in attempts.
The only way security through obscurity signals to "predators" is if they've seen past your defence, and thus defeated the obscurity. Obscurity (once revealed) is not a deterrent. Likewise an authentication method (once exploited) is not a deterrent.
>Of course in the age of automation, relying on obscurity alone is foolish because once someone has automated an attack that defeats the obscurity, then it is little or no effort for an attacker to bypass it.
This is true of any exploit basically. Look no further than metasploit. Another example: a worm is a self-automating exploit.
We should distinguish obscurity from intentionally hiding the configuration, which makes attackers undertake discovery, and hence can lead to detection. But your internal red team / security review should have all the details available. If loss of obscurity leads directly to compromise then you don't have security. Cf insider threat.
Obscurity is another layer of hiding or indirection: like the owl has camouflage and it has a hole in a tree.
Advertising your fitness (your stotting metaphor) is effective when: you are part of a herd, and the attacker will only attack the weakest in that herd and then be satisfied. Like double locking your bike next to a similar bike that has a weaker lock.
Computer security is different because usually either:
a) everyone in the herd is being attacked at once (scattergun/IP address range scanning), or
b) you are being spear targeted individually (stotting won’t work against a human hunter with a gun, and advertising yourself won’t help against a directed attack).
An example of advertising your security might be Google project zero, or bug bounties.
Many security tools I've used are downright user hostile in how little information they provide the end-user (or the admin!) regarding why an auth process failed. It incentivizes people to simplify or bypass the system entirely when they can't understand the system.
Remove all obscurity and expose all your techniques and algorithms and setting up bounties for people to break your defences.
See eg https://cloud.google.com/beyondcorp and https://cloud.google.com/security/beyondprod where Google gives up on VPNs.
I think this analogy perfectly explains my hostility to security by obscurity. When I see a system that uses standard ports and demonstrates best practices, I think "oh well, they probably know what they are doing." When I see a system using strange ports and / or has extra extraneous crypto, I think "well, maybe this guy is an idiot" and take a deeper look.
edit: In the first sentence "against" is not what I wanted to say: what I wanted to say is that it "downgrades it's effectiveness". I agree that obscurity can and sometimes should be a layer of security.
No one should be applying obscurity to public-facing APIs or anything for which documentation is widely distributed outside the company.
A better example would be Snapchat's intense and always evolving obfuscation strategies: https://hot3eed.github.io/snap_part1_obfuscations.html
Even though someone took the challenge to de-obfuscate most (but not all) of the protections, just look at how much effort is required for anyone else to even follow that work. More importantly, consider how much effort is required relative to other platforms. It's enough of a pain that spammers and abusers are likely to choose other platforms to attack.
Both reductions lose practical utility by omitting nuance.
* Avoid wasting your time doing performance optimization until tuning is necessary. But definitely take obvious and easy measures to ensure your software is fast, such as choosing a high-performance language or framework with which you can be productive.
* Don't exclusively rely on obscurity. But definitely take obvious and easy measures that leverage obscurity to add another layer of defense, such as changing default ports, port-knocking, or whatever.
To use the same art of reduction to counter the common interpretation: A complex password is, in a manner of thinking, security from obscurity. Your highly complex password is very obscure, hence it's better than a common (low obscurity) password from a dictionary.
Except that can lead to operational problems down the road. For example "oh yes, we're nice and secure, not only do you need a 512bit private key to get into this device, you also need to connect from a secure network"
Then along comes covid, and you can't get into the building.
"Oh dear, you're not on the secure network, you can't come in"
So you spend 2 hours (while your network isn't working right and you're losing customers) finding and getting in through a back door.
I try to tell people this, when they poo poo port knocking, but they just don't get it.
EDIT: s/the/they/
So I confess I still don't "get it". Unless you just want cleaner logs or something. I assume you're still getting the same number of initial connection attempts per day, but just not recording them?
Is it something to do with network or CPU consumption related to failed subsequent attempts by the same actor? (Which, the same as port knocking, should be rate limited anyways?)
- Assume for every code obfuscator there's a deobfuscator or at least someone as clever as you out there.
- Randomizing variable names it just a nuisance, it won't stop any competent pen tester or attacker.
- Encrypting the database is an odd one. Your program will also have to decrypt the data to use it. Where do you store the encryption keys? In your code? Don't assume obfuscating your code and/or randomizing variables will protect your encryption keys.
As to whether this is good or bad advice, that depends on how expensive these things are (e.g., encrypting database fields may be very expensive if you write raw SQL calls as your primary DB interface but may be dirt cheap if you're using an ORM that has it as a built-in feature) and your local threat model (e.g., "dedicated, personalized attackers reading your source" is very different from "does it defeat automated scanners?"). You can't know whether these are good or bad ideas without that additional context.
There is still some information lost in the process:
- "let eigenvector_coefficient = 23" => "let x = 23"
A de-obfuscator isn't going to be able to recover the valuable information contained in the original name. Will it stop a determined attacker? Maybe not, but it would surely slow them down as they now need to spend an order of magnitude longer trying to understand what the code is doing.
> Randomizing variable names it just a nuisance, it won't stop any competent pen tester or attacker.
Believe it or not, nuisances are enough to stop some people. A lot of would be attackers are just cruising for low hanging fruit.
Remember, the goal is to "reduce risk" and not "stop any highly skilled targeted/tailored attack". Because let's face it, even if you are the greatest crypto wizard in the world, you will fall victim to a highly sophisticated attack tailored specifically to you.
Sure it will. Imagine that your old, unpatched Wordpress admin is at /random-gobbledygook instead of /wp-admin. An attacker would have to try to hit random alphanumeric directories of your webserver over and over again, hoping that he stumbles across a specific thing that they can attack. This is completely impractical, unless they're somehow clued in that the URL exists.
It's really about making life difficult for an attacker, so much so that they will simply give up, or find an easier target. That can be achieved by throwing up a series of difficult/obscure barriers, each which makes it less likely you'll be trivially penetrated.
Then it filters out people who are not using a deobfuscator or are less clever than I.
> Randomizing variable names it just a nuisance, it won't stop any competent pen tester or attacker.
Then it will stop incompetent pen testers.
I don't see how your comment refutes the point made. The point is not that it makes your likelihood of attack zero, it just reduces the likelihood via adding more roadblocks.
So it does eliminate incompetent ones? That's kind of the point of the article.
But it will stop incompetent attackers - of which there are many. In fact, they are the vast majority.
None of those 'obscurity' techniques will stop a targeted attack. That's not their function. But each of them raises the bar. The more hoops, the better.
Making sense out of code obfuscated this way is really* hard for humans, but will compile or interpret just fine so long as your obfuscator obeys the rules of your language. (We started on this at one of my early startups nearly 20 years ago, but didn't get funded soon enough for protecting the IP in our unique JS to matter. It was unique enough that we actually applied for a patent on part of it - drawing a 16 trace live strip chart of data from network sources at better than 4-10 Hz per channel was really hard with the bowsers and computers of 2002!)
Yes, most people can grab some bolt cutters, snip, and bike off. Yet, so many bikes remain unstolen with extremely week locks.
The vast majority of attacks are crimes of opportunity. Hackers aren't generally trying to target a single company or computer for a bot net, they are looking to get as many as possible. Almost any amount of effort above and beyond the typical will cause them to jump past you as a target.
Back to the bike lock analogy. Again, most locks can be bypassed, getting one that requires an edge grinder will almost certainly ensure that your bike won't be stolen (Why steal that bike when there are 20 with simple wire locks?). Add 2 locks and you've got a bike that will almost never be knicked.
https://www.youtube.com/watch?v=oPDHPpnXPv8
This video can teach you a LOT about software security.
This. Putting a tarpit on port 22 isn't going to stop an attacker, but it will slow the ssh scans down for everyone.
Security and obscurity: if you make something secure and then obscure information about that system from an attacker that can increase the security. However obscurity is often organizationally expensive and very fragile. A key can be rotated, but changing how something functions is very hard to rotate.
For instance, the port 22 example. Suppose you have a bastion host. SSHD running on port 22, root password disabled, passwords disabled (only SSH keys), no other services running, all other ports filtered/closed. It should be fairly secure, even if exposed to the internet, right?
Now you can change the port. Change the SSH banner and hide the version. Add some port knocking. And so on. None of these measures would work by itself, but they will discourage non-targeted attackers.
Someday, someone will have problems connecting and waste half a day debugging it before they realize what is up.
Or troop movements during war... Sure, the locations can be figured out, but by not broadcasting locations that's more work for the enemy and thus a bit more secure.
Obscurity is absolutely a key piece of security, because it adds the complexity of discovery.
It works for the military, for spy agencies, and governments.
If obscurity didn't have any benefit, then the military's latest weapons wouldn't be tested in the Nevada desert, or some remote island; they'd be tested in Illinois, or off the coast of Long Island.
Of course, if any of these things are known the entropy drops to zero... Just like a private ssh key that gets pwnd.
All too often I see tickets on open source projects asking for changes to allow better obfuscation, which are then denied using the mantra "obscurity is not security".
They all add bits of entropy to a security and/or threat model that maintainers ignore.
> Instead it was originally meant as "if your only security is obscurity, it's bad".
Since all security is essentially "through obscurity" somehow, I would simply reframe that into the onion model. Good security is like an onion, it has many layers. When you only have one layer, that's bad security.
A better example of security by obscurity would be to, for example:
* Flip all the SSH bits or XOR it with some long key.
* Encapsulate SSH inside another protocol, such as websockets over HTTP port 80, or embedded inside what look to an outsider as cat pictures being sent over HTTP.
* SSH over TCP over Skype video.
Incidentally, any of these methods work well for confusing China's firewall and keeping the SSH connection alive, and would probably confuse hackers as well for a little while. They could all be implemented in a router box that doesn't affect your actual deployment.
This last year, I found out about knockd and if that isn't some awesome shit, I dunno what is. Yet, there are plenty of articles saying, incorrectly, how it's awful. It is simply another layer of security on top of everything else you have. Like you said, security by obscurity is more about making it fucking slow, irritating, tedious, and without any sense of reward. "Aha! After only a week, I've figured out you're port knocking! Oh shit... wait, you still totally have the server properly locked down. FML." Because after each "obscure" layer there is a "real" layer of security and hopefully those all those real layers buy you the time to detect and prevent the threat.
The port knocking itself may actually be the strongest link in the chain, despite it being one of obscurity, if the population of targets in your "value pool" is large enough so that you are always below a sufficient number of others without knocking enabled, since all attackers will bounce to those when they realize they are not knocked.
no, not really. what it means is: every important sytem has attackers trying to exploit it. finding an exploit is a series of hunches while probing the system as a blackbox, and you need just one; meanwhile a defender has to be methodical enough find them all.
given the differences, obscurity removes the defender ability to systematically analyze the system while on the other hand for an attacker it remains as much of a blackbox as it was before.
Although, Kerckhoffs's principle are a good way of describing how a secure cryptosystem should behave. This is what people should have in mind.
Obscuring will just add some delay as you state, but it might be irrelevant in many situations.
Obscurity instead of Security is bad too.
If that was the only security it’d be terrible.
But not having 1000s of bots pounding on the door saves a lot of headaches.
The only thing I would add is that it also needs to be maintainable - the obscurity should not impede the maintainer's understanding of the implementation.
I've seen too many instances where obscurity is used to justify weak primary layers (IE it's fine we're using this single word shared password since we have all these other layers). It can often provide a false sense of security since it looks like a security layer when in reality it often turns out to simply be a minor inconvenience to an experienced attacker.
But SSH is a terrible example, because the cost to the defender of simply not having SSH vulnerabilities is the same, or even less, than the cost of obfuscating it with nonstandard ports, "port knocking", or fail2ban, which are all silly ideas.
Just use SSH keys, and disable passwords.
I think maybe it comes down to this: dialing attacker costs up incrementally can make sense if it's the most cost-effective way for a fully-informed defender to improve security. But incremental cost-increasing countermeasures aren't a substitute for sound engineering; you don't get to count "having to learn stuff" as a valid defender cost.
I know who I am arguing with here but port knocking is not silly. It's fantastic.
When I say fantastic, I don't mean it solves all of our problems and obviates any other protections ... what I mean is, for almost zero cost[1] it adds a non-zero level of actual protection.
As a lifelong UNIX sysadmin, it is one of the few totally unalloyed security improvements that I have been able to add to my systems. I believe there are sshd vulns extant that you and I don't know about and port knocking allows me to worry less about them.
I also recommend SMS alerts on successful knocks - SMS alerts that you should never see in surprise. This is trivial, by the way, as you can put semicolons in the knock command:
/sbin/ipfw add 01021 allow tcp from %IP% to 10.0.0.10 22 setup ; /usr/local/sbin/timestamped_sms 4155551212 "knock from %IP% - "
If you believe there are unknown OpenSSH attacks, you can't coherently believe that port knocking is a real defense, since port knocking doesn't do anything to protect the SSH channel that attacks will be carried out in.
Instead, if you're actually worried about OpenSSH vulnerabilities, you shouldn't be exposing SSH to the public Internet at all. I'm not super worried about OpenSSH server vulnerabilities, but I would never recommend that teams leave SSH exposed; they should just hide that stuff behind WireGuard.
All it takes is me somehow being able to listen in on your traffic - not even decrypt it - and now I know the knock sequence. I know that you have SSH listening on that server. I know you are actively doing something on it.
vs. a VPN where... all I know is you are communicating over a VPN. With DPI I might be able to determine what type of traffic you're sending, but not where it is ultimately going.
If it's your private pet server - sure. In larger networks you have to document the access, manage the allowed ports on the network, configure security groups or equivalent on instances, provide alternative steps for people with unusual clients (for example database UI app proxying over SSH), etc. The cost suddenly becomes very non-trivial.
That's interesting, that's the first time I've heard a justification for port knocking that actually makes sense to me.
I'm curious for others' thoughts here -- are non-public vulnerabilities something you consciously try to mitigate? So that, for example, using 2 different 8-character passwords that are implemented with different technologies, is therefore fundamentally more secure than a single 16-character password? Precisely so that a vulnerability in one is still protected by the other?
To me this feels like it's really only applicable if you need to protect your data from hostile governments targeting you specifically, who might actually have zero-days they have weaponized.
However, if you're just trying to protect yourself from everyday hackers or even targeted corporate espionage, is unknown vulnerabilities really something that's realistically worth protecting oneself from? (Assuming you're always installing all security patches.)
Does it solve anything else?
> I believe there are sshd vulns extant that you and I don't know about and port knocking allows me to worry less about them.
Wouldn't you need to worry about vulnerabilities in knockd?
CVE-2001-0144 - SSH1 CRC-32 compensation attack detector allows remote attackers to execute arbitrary commands on an SSH server or client via an integer overflow
CVE-2008-0166 - OpenSSL 0.9.8c-1 up to versions before 0.9.8g-9 on Debian-based operating systems uses a random number generator that generates predictable numbers, which makes it easier for remote attackers to conduct brute force guessing attacks against cryptographic keys.
I had a machine almost get compromised from the 1st vulnerability ( noexec on /tmp broke their script ). When the 2nd came out I was using non standard ports and or port knocking. Despite having vulnerable keys I was safe until I could upgrade.
If a SSH RCE 0day was released:
* every "Just use SSH keys, and disable passwords" box sitting on the internet with ssh on port 22 will get compromised within hours.
* The boxes using fail2ban will get compromised within hours.
* The majority of boxes on nonstandard ports would likely be ok, at least for some time.
* The boxes using port knocking would be safe.
Having said that: I don't like exposing SSH services either! Which is why I try to keep them behind WireGuard, at least on prod networks that I care about.
In contrast to an actual VPN, port-knocking and (heh) nonstandard SSH ports shield you only from casual attackers; both give a middlebox attacker all the access they need to launch the attack.
Port knocking isn't a terrible idea but I generally prefer locking down the networks (or, these days, using AWS SSM / GCP IAP to avoid listening publicly at all) since having something on the internet means you're just one mistake away from problems and need to staff monitoring accordingly.
The other thing to remember here is that we're talking about one general CVE in two decades. Almost any other running service has been much worse so while SSH is important to protect I don't know that I'd make the argument that further pushing that one service is really the best bang for your buck.
No, safer. It is very well possible to brute-force port knocking or eavesdropping the ports since that information is not encrypted. Is it harder? Of course, a lot, but if you think scanning 65k ports on each host on the internet is reasonable, then evading a port knock is very much, too.
Moving the port to some obscure random one divided the number of requests from several thousands per hour to a few per day. Definitely an improvement by any measure : suddenly you can analyze the attacks if necessary.
I run fail2ban on top of it, because why not? In case someone would attempt to really target my system, any obstacle is good to take. And who knows what ssh vulnerabilities exist; any protection is good to take.
Reducing log clutter alone probably does confer some small indirect benefit, since it's less likely a more sophisticated attempt or successful breach would go unnoticed when inspecting logs. (Assuming there's some SIEM log forwarding or that it's not a situation where an attacker was able to or wise enough to wipe logs.)
Example:
* Use RSA keys instead of passwords -> This will eliminate most risk, except for exploits in sshd itself,
* Change the default port from 22 to something in the 40k+ range, which will keep you from being scanned, and
* Whitelist IP addresses that can connect to port xx on your server -> This will eliminate 95% of remaining risk
* Using a 'clean' bastion server to access other systems via agent-forwarding, preventing malware on admin workstations from being able to propagate over SSH.
So, no you're never going to be 100% secure, that's just unreasonable. But like you said, the cost can be increased to the point that all but the most determinted state sponsored APT groups.
I’m not sure there is any such good example though. Every obscurity control I’ve ever seen has imposed costs upon the users, administrators, engineers... but I’ve never seen one that I would rely on to improve security posture in any meaningful way.
I’ve certainly never seen an obscurity control that was worth its opportunity cost. I can think of dozens of actually useful controls where even a marginal improvement in operational performance would be worth more than every conceivable obscurity control combined.
Exactly! Especially when you can create a high cost asymmetry, low-cost for you to add, high cost for the attacker to bypass.
Agree that the SSH examples aren't the best. I would have picked DRM.
I would like to see a list of suggestions of "low cost" ways to obscure systems that are (relatively) harder to counteract. But I guess as soon as anyone publishes such a list then hackers will start checking for them.
Or even use a good password, if you don't have many untrusted users. It works perfectly.
Changing the port is not silly, it increases the SNR in logs, that's already a worthy goal.
From Wikipedia: "reliance [...] on design or implementation secrecy as _the main method_ of providing security [...]"
So, to use the model mentioned in the article, a single slice of cheese. It's not "an additional layer of defense", it's the main one (so you have other... weaker layers? ¯\_(ツ)_/¯)
Second, "reliance on secrecy of design and implementation" is different from "reliance on secrecy of _whatever-else_", because design and implementation are most often either easily discoverable (sure, occasional skids might not scan port 64323 but what about someone who can observe your traffic?) or pretty much guaranteed to be discovered by adveraries with (not even as much as one might think) time and motivation.
Third, some of the examples mentioned (e.g., the decoy cars) are not even security by obscurity, that's called deception.
So, sure, you can do non-standard stuff to make it harder for _some_ not discover your vulnerabilities (ssh non-standard port is actually a good thing given the massive amounts of bots around), but that should never be your only (or your main) layer of defense.
Security by obscurity is not underrated, by definition it's just bad.
People commonly misunderstand the concept and assume that obscurity is a bad practice in general, even when used as a secondary layer. It's not uncommon for junior engineers to object to any level of obfuscation or security because they can imagine a scenario where a sufficiently skilled attacker can defeat it, but that's missing the point. Slowing down your adversaries and weeding out the low-effort attacks is still valuable.
> So, sure, you can do non-standard stuff to make it harder for _some_ not discover your vulnerabilities (ssh non-standard port is actually a good thing given the massive amounts of bots around), but that should never be your only (or your main) layer of defense
That's exactly what the author says in the article. I don't see where the author is disagreeing with what you said.
I would go one step further and say that engineers commonly underestimate the volume of low-effort attacks that will pour in at scale. Some of these, such as brute-forcing or DDoS, can be disruptive to users unless you have perfect rate limiting (which you won't at first). Adding layers of obscurity before attackers can authenticate with and interact with core services can dramatically reduce the volume of these low-effort attacks. The skilled attackers tend to be more surgical.
I don't think so. It's like when someone confuses encoding and encryption because both "hide the plain text", they're just not the same thing no matter how you choose to view it.
> People commonly misunderstand the concept and assume that obscurity is a bad practice in general, even when used as a secondary layer. It's not uncommon for junior engineers to object to any level of obfuscation or security because they can imagine a scenario where a sufficiently skilled attacker can defeat it, but that's missing the point.
So how about teching these people instead of accomodating the misunderstanding and its unforseen consequences? I say this because the point of spreading "security by obscurity is bad" directly relates indeed to people, who use to think of security as a binary thing (it's either secure or not secure) with the consequent misconception that if there is something in place than it's secure.
> Slowing down your adversaries and weeding out the low-effort attacks is still valuable.
Definitely yes. But that is not security by obscurity. I always liked the safe analogy: it's good if you still need the key to open it even if you have its blueprints, a huge number of models both open and close with their own keys to play with and the time to take all of them apart. I think most people who dealt with math and cryptography get this more among security professionals and engineers.
> That's exactly what the author says in the article. I don't see where the author is disagreeing with what you said.
The part when he based the article ignoring the definition of the subject. If one reads his article with the definition in mind, then the whole article disagrees with this. I don't mean to be pedantic on definitions but I think there are good reasons for this one that are just being ignored.
It's not to never use obscurity to your advantage. It's that you need to be aware (and far too many weren't at one time) that you cannot rely on obscurity as a form of defense.
If I have an old, buggy unpatched version of an admin page sitting on an obscure random URL, but I decide I don't need to bother patching it because eh, it works and it's too much effort to patch and what are the odds someone will guess my super secret random URL, then I need to think about why "security through obscurity" is bad.
And that false sense of security is why they say security through obscurity can be worse than no security at all. They key is to promote vigilance and actual hardening of systems and not expend precious time devising ever more elaborate obscurity hoops that cost you more than they cost an attacker in time and effort to defeat, and are in the end ineffective.
That's not to say you should leave ssh listening on port 22, you really shouldn't. It's like the difference between leaving your front door unlocked and leaving it unlocked and putting up a big neon "Open 24 Hours!" sign in the window.
Except that if you use a port above 1024 (like the author does) you no longer have assurances that it is a privileged user that launched the process. Any non-privileged user on a Linux system can bind to a port higher than 1024, so all it takes is sshd restarting after an update if it's directly listening on a high number port, or iptables rules getting reloaded if they're being used to forward traffic from a high port to 1024 and an attacker can have their own credential collecting service running where you think sshd is, and all it takes is someone ignoring the host key mismatch error to give up your good creds to an attacker, and now they have more access into your infrastructure.
For example, I have no trouble revealing that all our SSHDs at work are ssh-keys only with a strong key policy and periodic reviews, whitelisted accounts, most are firewalled to be VPN only, configs are hardened periodically, some are 2FA secured. All in all, those are good or best practices to follow in order to harden an sshd, so I'm losing little info there.
A pentester under NDA would get more info to be effective, like the whitelists, might get IP whitelisted even. Security audits during pre-sales might some other additional info.
However some details and measures don't need to be known outside our operations team. But they can and have been a royal pain to visitors.
https://en.wikipedia.org/wiki/AACS_encryption_key_controvers...
Even if it was technically a password, it's really obscurity because the password was literally available in billions of devices worldwide - it's just hard to read. Then someone figured it out (specifically in WinDVD).
So, when someone says obscurity is fine, it's fun to remind them that all DVDs are cracked because someone thought so. (Not that I think that's a bad thing)
1) The former is not security by obscurity, the car the president is in is a secret. Any attack on the president is rendered much harder because of the process even if you know what the process is. Just like regular cryptography.
2) This isn't security through obscurity because the attacker learning your system wouldn't help them. Because the attacker is, literally, a bird-brain.
"There's no such thing as security through obscurity" is an example of the second; you can use it to mean "shut up and stop asking questions about the secure system I designed," but you can't use it to design a secure system or explain why your choices are correct.
The useful design principles behind "no security through obscurity" are just a little more complicated -- they're more like "every secure system must have defined entropy sources (such as keys) that provide a lower bound on the security budget against a hypothetical attacker with knowledge of everything except for the entropy sources." And, "because obscurity does not measurably improve the lower bound on the security budget, it is only a good idea if it also does not raise the chance of implementation errors, does not make it harder to obtain third party reviews of the system, and does not make the security of the system harder to prove." An argument about whether something is security-through-obscurity-in-a-bad-way probably actually wants to be an argument about an underlying design principle along those lines.
I don't exactly begrudge people using "shut up and trust me" phrases in situations where that's needed, but I think they're almost always unhelpful in forums like this.
If you get right down to it, passwords are just obscurity. Usernames are just obscurity. In this very thread people are dismissing port knocking while it's functionally equivalent to a password.
I will personally stand by "security through obscurity is not security" forever because that way we can get to the actually interesting question -- what level is needed for this service?
Let's take a simple example from the public Internet -- you want to share something. So you put it on a server with Apache. You add TLS and PFS. You hide it in a folder structure somewhere. You add a single-use token or just htaccess.
Any of those individually would be obscurity, but put together they are most likely more than enough for... well, anyone. So is it still obscurity or actual security? That's a debate for the ages, but I think most people would agree all of those put together are fine-ish, but pick just one method and it's just obscurity.
This whole thread is basically just a philosophical debate where half the people haven't read the article, the other half disagrees with minutiae in the article, the third half disagrees with major points of the article, the 4th half is sharing anecdotes and the 5th half just wants to participate.
The extreme of this strategy is to make a successful guess cost more than anyone can possibly pay, for example by using numbers so obscure that all known algorithms for guessing them will take longer than the heat death of the universe to succeed, or something like that.
But while there seems to be solid math to calculate such numbers, implementations are rarely perfect and can easily leave open the possibility of other guesses that cost a lot less than breaking the theoretical limit. (AKA side channels, vulnerabilities, bugs, etc)
Where "security by obscurity" comes in for criticism, it's usually because the implementers have misjudged the amount of obscurity they are actually creating, or misjudged the amount they need (their threat model), or both.
It's easy to make these mistakes because it is hard to create perfect implementations, and hard to know exactly the current and future capabilities of your attackers.
Isn't this the same as saying something like all astronomy is a matter of looking at the right place? Or all math is solving an equation? Or all surgery is cutting the right thing?
If you reduce anything to it's simplest part, it will sound simple.
Obscurity and passwords fall under "something you know". Biometrics like what you describe would fall under "something you are". A physical key such as a yubikey or the sim card matching an SMS challenge would be "something you have". Multi-factor authentication is more secure but it doesn't negate the discussion here about hardening the "something you know" factor.
For some things, like VPNs, the adversaries are going to be more familiar with the details than the intended users. I often joke that an effective way to crack a VPN would be offer to configure it properly for a user in exchange for ten minutes of unfettered access to the target company; enough users are sufficiently frustrated they would take this bad deal fully knowing what it meant.
Oh cool that’s fine I’ll just click away all the big scary warnings in my browser to access this page. I’m an engineer and know what I’m doing! It’s a super strong key anyway. Oh wait I’ll just send this link to Bob in accounting and tell him to do the very thing we’ve been telling users not to do under pain of ridicule for ages and then he’s now doing that 10 times a day and now all of https is pointless because he knows that ‘it’s probably fine to ignore it because I have to do that at work’...
Security by obscurity refers to a situation where security is dependent on the secrecy of an algorithm (the algorithm not being widely known or peer reviewed) rather than (or in addition to) a secret datum used with that algorithm.
The opposite practice is to use a well-known algorithm and depend only on the secrecy of the inputs to that algorithm.
The layers of security presented in the article do not meet the definition of "security by obscurity".
Even a port number like 64235 is a secret datum, not a secret algorithm. It's not a hard-to-discover secret datum; it is poorly guarded. But that's not what "security through obscurity" means. Using a funny port number is a widely-known system, with an objective benefit: it requires an attacker to take certain steps that are not required with a known port number. The assumption is that the attacker knows that alternative port numbers are being used.
The claim was never that using obscurity is bad and should be avoided. As I first heard it, "Security through obscurity is not security" is saying that if you are relying on obscurity to keep your stuff secure then you aren't doing enough.
I think this is still true and the conclusion of the article agrees
Security by obscurity is not enough by itself. You should always enforce the best practices.Yet. All of these are from HN.
> 3. Since when is obscurity a valid security measure?
> Security through obscurity, not a valid security plan.
> The problem with these "obscurity as a valid security layer" arguments is that there's already obscurity built into these protocols.
> Especially since most people believe "Obscurity" to still be a valid security technique.
> You're just reciting the same tired old rhetoric that security through obscurity is a valid defense mechanism. It's just not.
> I thought the general consensus here is that security by obscurity is bad.
> Obscurity is bad because it makes you _think_ it adds security.
> To maybe give some perspective _why_ security people say that security by obscurity is bad - and especially serving ssh via port 64323: [...]
> I dismissed it as security through (bad) obscurity but is there a valid security reason to do this?
> Compression is not encryption and security by obscurity is bad practice.
> it's understood that security by obscurity is bad.
> Security by obscurity is bad, of course, but in that model it's such a minor factor.
And countless many more. Some of these reference "security by obscurity", which, if you're kind, you can interpret as "security only through obscurity" (though reading in context this mostly doesn't seem to be what is meant), while others dismiss obscurity entirely. You will also regularly find commenters lament this point of view as the "mainstream idiocy".
I agree with the OP, but I also fully agree with this point. I've seen people download the fishiest stuff or open anything because "I have an antivirus installed". Now, I don't claim that no AV would be better in all cases, but it is very much a factor.
From Apache docs: > Also note that disabling the Server: header does nothing at all to make your server more secure. The idea of "security through obscurity" is a myth and leads to a false sense of safety.
However, beware that obscurity is in the eye of the beholder, or more relevantly, in the eye of the attacker. For example, script kiddie attackers may be the ones who in the twitter example only scan the default ports. This is an important element to defend against.
But a seriously skilled attacker isn't going to use script kiddie methods. They will use more complete, likely stealthy attack patterns.
Bear in mind that what you think of obscure may be breakfast for a skilled attacker. If you are serious about defense, then you will be compelled to follow the ninja threat model, which, in part, says The attacker is going to sit on the same network segment as the application. There’s no firewall or filters. There’s a special place in hell reserved for products that require firewalls or filtering to protect themselves against attack.
Focus too much on obscurity and you will fall victim to the fallacy of "defense by presumed motive."
I obviously kept the machine patched and up-to-date, but I think I probably could have left it unpatched, and it still would have been fine.
Zero cost is rarely, rarely true with regards to operations. If you use non-standard ports, you'll have to document that somewhere, or else it becomes tribal knowledge.
If you don't document it, and someone leaves, how do you know how to access your servers? At the very moment you don't know how to SSH in, you've just paid the price. It's no longer zero cost.
If you do document it, you must now take the time to manage the permissions to that document, figure out who needs to know, and then change access as people come and go. All of that requires time, which also has a cost.
Plus all of this also has training costs when you onboard new people.
Zero cost is a real thing with computer science but not operations.
To further your alternate-port example: let's say you have some instances running on Google Cloud. GCP already has a big CLI codebase that they get everybody to use, which has a command `gcloud compute ssh` for connecting to instances, which already has tons of magic built into it. It would therefore be pretty easy for GCP to add additional magic — e.g. randomizing the SSH ports of newly-deployed instances, and then publishing those ports as project secrets in a way that the gcloud CLI tool can discover and use in the `gcloud compute ssh` subcommand.
The incremental cost of an approach like this is effectively zero: the DevOps folks didn’t have to build anything new to get this advantage, because they already built all the infrastructure required (i.e. spent the labor-cost you’d be spending) in the process of getting some other, earlier advantages.
In a sense, setting up a platform or infrastructure that's more complex/flexible than what you require at the time, is the opposite of "technical debt." Rather than saving labor now but needing to be paid down with later labor, it requires more labor now, but potentially saves labor later. It’s a bit like paying a retainer fee: you get less than you pay for (or nothing) up front; but in return, you get things "for free" later on. "Tech equity" might be a good term for this — it's what you get when you invest labor into your tech stack.
Plus, zero incremental costs may only apply if you match the situation being presented. If not, you may have real costs associated with implementing obscurity. This evaluation of whether you will get zero incremental costs or not is a cost in itself.
It's just a misappropriation of the term from zero cost abstractions and it bugs me, especially since it's being ported from compiler theory/engineering to operations, two things which rarely have anything to do with one-another.
They'd be way better off coming up with "cost-effective obscurity" ideas, instead of calling this zero cost.
To the point though, no one should "assume the tanks won't be found", but it's still worthwhile to do things to make it less likely they will be found.
> Using Symmetric Encryption in the Database: When you write data to the database, use a function like encryption_algorithm(data,key). Likewise, when you read data, use a function like decryption_algorithm(data,key). If the attacker can read your backend code, obviously he/she can decrypt your database.
[1] https://news.ycombinator.com/item?id=6948742
[2] https://web.archive.org/web/20181118154823/https://www.alexr...
> "I ran an experiment with a virtual machine exposed to the internet which had sshd listening on port 22. The server stayed online for one week and then I changed the ssh port to 222. The number of attacks dropped by 98%. Even though this is solely empirical evidence, it’s clear that moving off the standard ssh port reduces your server’s profile."[0]
> "In the time that I gathered 7,025 connection attempts to my SSH daemon on port 22 I received 3 on port 24."[1]
Also, great top comment by 16s[2] in this HN thread, "Why putting SSH on another port than 22 is bad idea".[3]
[0] https://major.io/2013/05/14/changing-your-ssh-servers-port-f...
[1] https://danielmiessler.com/blog/security-and-obscurity-does-...
Security by obscurity only matters if you aren't secure in the first place. It can be a good extra layer of protection, but the worst examples of security mishaps I've seen are because people find the security unnecessarily burdensome and so they bypass it entirely. So in that way obscurity in that case has a real cost.
If your corporate IT group regularly asks users to send in their passwords via e-mail in order to perform some remote maintenance, then the users will be habituated to sending their password to a familiar e-mail address. If someone from outside their company asked them for their password, they would immediately say no. But an e-mail with the right "From: " address, they would quickly fall for. So it becomes easy to trick the users into sending their password to an attacker in some circumstances, because of the assumptions they make.
Security by obscurity is just another form of this: a practice which isn't really secure, but people may think is secure, because it seems to avoid the simplest, most stupid attacks. But literally any action you take could prevent the simplest, most stupid attacks. That doesn't mean that any action you take makes you "more secure".
Hiding a key under a door mat or in a sun visor isn't "more secure" than leaving it in plain view. Anyone who's not a total moron will find it, and if that's your whole security posture, you're screwed.
Having a network share on the home network that only your household can access and use 2FA for that? Maybe a bit too much. Do you know your organization will be individually targeted by smart and tenacious actors? Changing the SSH port isn't gonna stop them.
I agree with the article that more discussion about what makes something secure is valuable security work. Disregarding defenses at first sight because they "sound obscure" isn't a good argument. But it also doesn't mean that "small things that might stop someone" is a good layer of defense.
And then there is also the cost of adding security layers...
Yes, I scan them all: 53.2%
No, I use default scan: 46.8%
186 votes
Maybe the author's pentesting pals do that on a few public /24 or some intranet (I would, if I was a pentester). But you're average bad guy scanning /8 blocks looking for an easy catch? Maybe with a botnet...
(TBH, I focused on security/crypto during university, but ended up in an other field - so my practical knowledge is limited).
Obscurity is naturally fragile, vulnerable to social engineering. Social engineering is the real problem. We can filter out brute force easily. It can be fail2ban, or even simplest ip-tables rules like
iptables -A INPUT -j REJECT -p tcp --dport 22 -m state --state NEW -m recent --name TCP_SSH --update --rttl --seconds 600 --hitcount 15 --reject-with icmp-port-unreachable
iptables -A INPUT -j REJECT -p tcp --dport 22 -m state --state NEW -m recent --name TCP_SSH --update --rttl --seconds 60 --hitcount 5 --reject-with icmp-port-unreachable
iptables -A INPUT -j ACCEPT -p tcp --dport 22 -m state --state NEW,ESTABLISHED -m recent --name TCP_SSH --set
You cannot really hide IP address or port number. You'll send this information to your colleagues and partners over SMS, Facebook Messenger, Whatsapp, Viber, Telegram, E-mail, Skype, Zoom, many times, multiple channels. Or you will write it down on a Wiki, like Confluence, which is public to entire organization, and that knowledge is not a secret anymore.
My greatest fear is not a script kiddo with botnet, but an addict employee with debts.
Otherwise, switching ports or making your systems a bit different to the others on the internet means the majority of hackers - 'bots', 'scanners' and 'script kiddies' will move on to easier targets.
On the internet you don't have to outrun the bear, you just need to run faster than some other guy.
Another example might be folks in the security community saying that SMS 2fa is no good because all it takes is someone taking over your phone account to get around. Sure, that happens, but not all that often, and usually happens to people with something that's worth time & focus by talented bad actors.
"Security by obscurity is not enough by itself. You should always enforce the best practices. However, if you can reduce the risk with zero cost, you should do that. Obscurity is a good layer of security."
I rather like the conclusion.
risk = probability * severity
Security controls impact everybody though. Not only does it make the problem obscure to an attacker it also makes the problem obscure to non-attackers. This dramatically increases risks because it impacts the application and distribution of other security controls.
Since it’s barely helpful where intended and harmful where it’s unintended security by obscurity only increases risks.
The analogy to software is the belief that hiding source code makes it safer. Hidden source code is not any safer but the vulnerabilities are a bit harder to find. The benefit of open source is that the vulnerabilities are exposed to anybody who reads the code which allows more vulnerabilities to be exposed and patched.
There's the idea in security that an attacker knowing your algorithm/practices shouldn't mean anything yet you rarely see companies detail the security measures they take on internal systems because we know keeping this secret has no downside.
Security policies at most companies are often generic and not secret. Reporting chains for emergency remediation and asset identification are secret because those identities are potential attack vectors. Information sensitivity of that nature means it must be protected from disclosure and not that it should otherwise be hidden. The key phrase for sensitivity management is: need to know.
Typically you want to know who is connecting to what server via what service and log these connections. If something is off, an alert can be generated. If ssh isn't served on a standardized port, logging and alerting becomes more complicated - albeit not impossible.
There is more housekeeping to do. In case of a handoff, things like this need to be documented. If all services work on their default port, there is no need for documenting them.
In the case of compromise, it becomes very hard to identify how a machine got compromised.
Yes, a lot of people do not do a full port scan. But those are not the people exploiting risky vulnerabilities. Security by obscurity reduces your risk, but only to a certain extent. Having a proper patch management or firewall management in place reduces your risk a lot more.
A lot of owls do get killed by humans, despite their camouflage.
Could you elaborate on that? I serve ssh on a non-standard port precisely in part because it drastically cut down on the noise of failed log-ins, to the point where when I check the logs I'm almost the only one who actually bothers to try to log in via that port. That seems like a win to me.
I changed the default SSH port to a random high number.
I had zero failed login attempts in 2 months.
Of course use strong security methods but I suggest changing the default port numbers just to clean up the log files.
Security by obscurity alone is bad, but as another layer, it can be great.
I beg to differ in your case.
Had you left SSH on its default port, what would your expected time-to-compromise be? Presumably you weren't using a root:password credential, or else your system would not have remained up enough long enough for you to implement any obscurity.
But if an attacker, with full ability to try logins, could not reasonably guess your login credential in the lifetime of the universe (i.e. public key SSH or a strong password), then you've not improved security by moving to a port-knocking model.
You have reduced nuisance, but nuisance isn't part of the standard threat model for SSH security.
To put it another way: you've not seen another unauthorized login attempt, but would you be comfortable relying on that and use root:password as your access credential?
I've seen security through obscurity misused too often as the only line of defence, or as a "temporary" stop-gap that outlives its usefulness. It can lead to a false sense of security.
Such measures also do not tend to keep up with changes as attacks become more sophisticated or cheaper to carry out.
You also need to make sure that there are no unintended consequences - does your non-standard configuration make it harder to apply upgrades? Does your own penetration testing also scan all ports, or is it only going to discover weak servers running on port 22 on your network?
That said, I would do the type of things mentioned in the article as an "added bonus", but try to exclude them from my overall security evaluation (either rough mental model or formal threat model).
Exactly.
> we need for some reason make this development-stage service publicly available on the internet, and it's connected to a lot of our services internally, but we can implement AAA only later and we need it now. No issue publishing it on an obscure route/IP/domain name?
And the setup stays online for 5 years.
It makes sense to change port purely to avoid the low-barrier noise but of course it isn't much better security. Port knocking is on the same lines.
I'm by no means a security expert but these measures would surely help: less opportunists = less opportunities.
Saying that, I'm public key auth only and disabling any public facing service I'm not using.
The "security through obscurity" thing seems like a warning to avoid shortcuts rather than some implementations that help reduce noise. As long as you understand the fundamental problem of security, the obscurity thing is just a sidebar.
You miss 100% of the shots you don't take applies to hackers as well.
"Don't be where the enemy expects to find you."
As TFA and several others have pointed out:
(1) Don't use this as your only method of defense. The further from your LOCK the better the key needs to be. (2) Use your security in the layers that offer the most benefit. (3) Be proactive in your defense.
-Changing your SSH port will stop that largest number of attempts on your service. -A non-default port PLUS port-knocking PLUS key-only PLUS whitelisted IPs PLUS whitelisted login names. Is better then only one of those. -Apply very liberal firewall rules to prevent any unauthorized from IP's that should have access to your service. Country-code level blocklists are a thing.
Being obscure is about NOT being where your opponent expects to find you.
Unlike many approaches to cybercrime defense, obscurity-enhanced bot detection has lead to both prosecution and extradition of accused attackers, https://www.cyberscoop.com/tag/methbot/
White Ops technical talk at PSEC18, https://youtube.com/watch?v=Aqdn09myGlM
"Due to its immense value, detectives were assigned to a steamboat that was rumoured to be carrying the stone, and a parcel was ceremoniously locked in the captain's safe and guarded on the entire journey. It was a diversionary tactic – the stone on that ship was fake, meant to attract those who would be interested in stealing it. Cullinan was sent to the United Kingdom in a plain box via registered post." - https://en.wikipedia.org/wiki/Cullinan_Diamond
All the positive examples in the article mean actively obscuring the view of an attacker. This is an addition of things like camouflage or distraction.
Proper obscurity is obviously bad, because there simply is no security concept behind it. Additive obscurity is obviously smart because it adds to an existing concept.
Security by, say, mathematically-hard problems stays secure even when the problem's design is understood. Security by obscurity breaks any time the secret gets out.
(There is an overlap point where a math problem is too simple to solve and, meanwhile, an obscure secret is "The sixteen digit number the President memorized to launch the nukes" where the security-by-obscurity can even beat out mathematically-secure, but the middle points of those two sets are separate and the reliability heavily tilted in favor of the mathematical cryptography).
The swiss cheese picture is excellent, since that is how stuff happens in the network internals, with lateral movement and other internal activities.
Say an adversary has to jump 5-10 hops from initial point to target system and you can, with very lightweight obfuscation and ”obscurification”, increase the attackers mistake rate dramatically - it makes a ton of sense from a risk and economic perspective.
Consider the alternative (succesful internal hardening and monitoring) which is way out of scope resourcewise for most.
But one thought I have is that this more nuanced picture is much more complicated to tell beginners. Beginners / not as security conscious developers often, wrongly, assume that obfuscation is much more powerful than it is.
The safest digest of the "Apply ≈Kerckhoff's principle, but some obscurity on top of that is not a bad idea if it's cheap to implment", is probably "security by obscurity is bad!1!".
Certificate pinning or sandboxing in mobile apps won't stop people from reverse engineering your API's. But if your personal belief is that it's like almost a state actor level attack to see your API routes or modify requests, it will undoubtedly influence how you implement them.
I've seen some serious problems where companies do really bad things (like sending the ID of the currently logged in user and not checking it server side, allowing for execution as arbitrary user), which I guess at least partly arose from thinking along the lines of "It's only our signed code that will ever make these requests". Even bad developers wouldn't make the same misstakes in ≈2020 on the web, where the understanding that the client is untrustworthy have fully statured the common understanding.
I know they are used primarily for detection, but why not go the extra step and make a honeypot that is a truly believable facsimile of a real corporate environment so the attacker wants to stay around even longer. There are lots of clever ways you can switch network traffic to make it look like you are talking to one host when in reality you are talking to a VM jail under a security administrator's desk. Load these environments up with fake, but believable data. How would an attacker know if they are in production actual, or fake prod? Once you "acquire" an attacker, you could even monitor their approach and string them along with hopes of getting into SVRSQLPROD (which is obviously going to be loaded with fake bullshit, but they wont know until they find the symmetric encryption key which you will probably never give them).
Again, I think we are all clear that the above is not deterministic security and that certain experienced attackers (or insiders) may be able to smell such a honeypot from a mile away.
To your question: absolutely. They are also a very economically effective and (done right) an easy-to-implement solution with very low-to-none risk of jeopardizing any legitimate traffic.
To your why not do this - we are working on this right now. There's a lot of interest to what you described in above average maturity security teams; we have a few customers in this niche helping us design the "attacker playpen." You are right in that it is a challenge to make believeable enough without introducing risk into the environment.
If you are using a password there is a mathematical definition of how hard it is to crack, the number of bits of entropy contained in the password. If you use a password manager like KeePass it will tell you the number of bits in you password.
If it takes me 2^100 guesses for a 50% chance to discover your password then that is not obscurity, that is a valid defense mechanism. That the password itself is obscure is not a reason to call the strategy obscure.
Passwords and keys are used to create an artifact that will unlock access to a whole bunch of information. Instead of protecting each piece of information individually, we can now focus our efforts on protecting the password instead.
With a password we have managed to make the process of protecting information simpler, less obscure.
Sorry to discuss something a bit off-topic from the article, but I figured I had seen the "passwords are obscure" argument so many times here and that this could be a valuable opportunity to teach something about security.
I have a super secret password to my bank account! It's super hard to guess, and there's 12 factor authentication. You have to get my cat's paw print to sign in.
When the truth is: There is no bank account, password, or cat. And you are actually a homeless, broke, dog lover.
If you want to keep something secure, don't brag about how secure it is. Don't talk about it at all.
Somehow in my mind, cryptography, eg. RSA, is also obscurity then. But instead of obscuring the physical coordinates in the set of coordinates of New York, we obscure the location of the private key in the set of prime numbers.
Then it doesn't exist.
https://webcache.googleusercontent.com/search?q=cache:Bgl-ex...
Doesn't that reveal part of the problem of 'security by obscurity'?
Indeed, how many people publicly disavowing 'security by obscurity' do so to secretly benefit from the methodology?
Obscurity means keeping something private that if the attacker knew they could access your service. Traditionally security by obscurity is something like putting your ssh login port on port 61329 rather than port 22.
I'd argue that the above is 16 bits of obscurity, whereas your ssh key you log in with is 1024 bits of obscurity. The attacker needs that 16 bits of port number obscurity and the 1024 bits of ssh key obscurity to log in.
However the attacker-seconds to break the 16 bit port number is a rounding error compared to the attacker-seconds to break the 1024 bit ssh key
Which is where, I guess, the idea that "security through obscurity" is bad came from.
I'd argue that the attacker-seconds is still higher with your ssh on port 61329 though, so why not use that too.
For example: a generic SSH vulnerability means somebody is going to make a botnet to check every port 22, leaving your 1024 bits useless and the 16 bits worth more.
Also it is so easy and cheap to implement is another reason to discard it because in many organizations today people think that security can only be had by spending boatloads of money on people and software. Surely a simple, fast and cheap solution can't really reduce risk now can it?
And then on top of those things people do not think about, nor fully understand risk, hence the whole Covid 19 scare and the many other things in the world people are afraid of.
Rather what seem to be the issue is what security by obscurity actually means and can be missinterpreted as.
Layering lots of obscurity and putting time on that when it can be spent to increase security in the actual weakpoints or/and hiding them for developers/maintainers are problematic to say the least.
- doesn't reduce the security of the safe
- ensure you don't advertise "THERE'S A SAFE HERE" to whoever visit your house, possibly reducing burglar attempts
Now, if you have just the painting over a hole in the wall, you got something wrong...
Did you actually accomplish anything?
But there are times when you just need to discourage people, not truly secure a site. Not many, but they do exist. Pseudo-security in those cases is cheap and meets the business needs. Likewise, there are times when best practices aren't good enough, and you need to go beyond the norm.
Either extreme is driven by thinking through the acceptable risks, evaluating costs, and making a decision.
I attended a security conference a few years ago, cannot think of the speakers name right now, but he said you should assume that professional hackers have better tools and larger budgets than you will ever have access to.
InfoSec has very much gotten a bunch of these statements that can't be argued with, and people won't even take you seriously if you point out the flaws with password managers or PKI.
I've definitely used methods in my own code which "aren't trustworthy" from a security doctrine standpoint, but proven near 100% effective, on their own. Just because a state actor won't be phased by it doesn't mean it isn't a strategy that'll prevent 99% of automated attacks.
s/Red Worm/Code Red/gA lot of comments here are saying "don't do x, do y." or "x and y are useless, you should just do z".
The Swiss cheese model helps you visualise that adding and recognising having many layers of defense carry value and should be recognised as such.
What’s missing here is the discussion of tradeoffs. I fail to see how e.g., requiring port knocking adds enough security to justify the annoyance. Changing the default port, maybe, but given how easily it’s detected anyway, the cons still outweigh the pros IMO.
For example, making ciphertext look like cleartext[1], or hiding text in images[2].
I've noticed the same thing with software developers.
- "Client side encryption in JavaScript is useless!" Until CloudBleed came out and the only company that was safe was a password manager that used it. To thwart client side encryption you need to actually modify the contents of the JS payload, which is detectable. But no matter how much evidence I give that this tactic works and is actually used in production and that it actually stops attacks, programmers just don't care.
- "Don't do security by obscurity!" But then we all implement passwords (which is just security by obscurity) and the best people in intelligence don't have LinkedIn accounts. Anyone can join an OSINT forum and see the actual tools that get used. Security by obscurity works for many, many actors.
There are many, many little bits of stuff like this. Think to yourself: How many times has code that you've written lead to an RCE vuln that was exploited. Personally, I can only give a lower bound, and that lower bound is zero because I'm extremely careful, but I don't pretend that it's never happened. Anyone that is familiar with data science or economics or political economy understands that when a signal is dampened the response is dampened.
No it isn't. Security by obscurity is explicitly keeping things other than passwords and keys secret.
Thank you for being someone else who recognizes this. If having a secret piece of knowledge grants you access to the system then it's obscurity. Once we admit that then we can start talking about the difficulty of guessing that knowledge as the actual important factor.
Changing your SSH port is the former.
Using NETRJS instead of SSH is the later.
Hiding things is just a good security practice in general (just understand hackers have access to port scanners) so that kind of "security through obscurity" isn't a bad idea. Using obscure protocols is something quite different, and really shouldn't be in the same category.
Regarding data obfuscation, for example:
- Can an average person differentiate between encrypted data and well-obfuscated data just by looking at it?
- Would it be reasonable for the average person to assume that obfuscated data is equally as "secure" as encrypted data?
- Might someone store and transmit "secure" data differently than normal data?
Maybe a Bloom filter approach? Besides the salted slow hash you store of each password, also put the password in a Bloom filter. Check new passwords against the Bloom filter. You'll get some false positives that way, but maybe that is acceptable.
I'm seriously tempted, if I ever have to implement a password system again, to allow up to 256 characters, just store an unsalted SHA256 hash, and tell people on signup that they should be using a password manager with a long random password if they care about security of their account.
Security by obscurity is simply a completely different class, comparable with dollars and cents. So if you care about security would you rather focus on the dollars or on the cents?
Contrasting to games of the 2000s the barrier has been raised significantly for hackers
Some protection methods do last a long time. StarForce 3.0 protected SplinterCell took 422 days to crack. Not long ago cracking Denuevo protected games took around 75 days [1,2]. I'm not aware what the current best protections are or how long such protected games take to crack.
[1] https://news.ycombinator.com/item?id=21953764
[2] http://web.archive.org/web/20200104093734/https://iscracked....
Most security experts will argue in adding layers of defence where the proper solution is not possible.
There are other considerations for obfuscation as well. A risks assessment might consider the skill of the attacker and the resources required (eg: computational power) in order to break in.
A big tech company will have tens of thousands of current and former employees. Those employees may try to break in, and all the easily accessible internal wikis or other common resources are going to end up on some hacking forum somewhere eventually.
If I change the admin page of a Wordpress corporate site URL to something other than the standard wp-login.php the number of scripts that try to crack it each day goes from a thousand to zero.
It's _very_ effective, along with other precautions for locking these things down.
For example, changing your public server ssh port from 22, to say, 2942, is a great way to limit the amount of bot autoattempts from trying to log into your server. Having a password-less ssh port 2942 open is clearly bad, but not when combined with all the standard good practice ssh security.
Instead when you think about layers of obscurity, you go much deeper affecting the probability at each layer (host, port, etc.)
In reality, at a different conceptual level, things like TLS are also bundles of obscurities.
Suppose that you encrypt your message using "my own crypto". The result is ciphertext that looks like a random bit sring. Then encrypt the ciphertext using a standard algorithm such as AES.
An attacker will have difficulty since a successful decryption of AES is hard to recognize as such.
The aphorism is unfortunately too short to be enlightening except to someone who already understands it.
Let's say you're a bank. You implement port knocking as your security measure of choice to keep SSH secure.
I know from your job postings that your developers and IT department work at X location in Y city. I know the IP range of your public facing servers. I go to the closest coffee shops to that office, and drop off some wifi sniffers that record and send me all the communication to that IP range. All it takes is one of your employees doing some work on one of those servers from the coffee shop, and now I know your port knock sequence. Layer defeated.
Or, you use a VPN. I do the same thing. All I see is VPN traffic. Maybe I can identify what type of traffic with DPI (unlikely to have the horsepower on the type of device you'd be leaving unattended at/near coffee shops for extended periods of time), but no real details on where that traffic is ultimately headed, and I have no ingress point given up to me. The VPN can also be used to secure other types of traffic beyond SSH.
There's just not really any reason to use port knocking over a VPN when the difference in overhead and complexity is minimal and the benefits you get with a VPN vs. port knocking are so massive.
Blocking all icmp traffic breaks tcp - so true "invisibility" isn't that grät either.
Decades of running without a single intrusion. We moved to SPA port knocking and now we rely less on the VPN for certain assets.
I would imagine that this is open for a man in the middle attack- if this traffic were intercepted- you'd be able to see port numbers, right?
I've always wanted to set up something like this - but it seems like a pain to remember everytime i want to connect..
In detection, honeypots are very useful, like a machine named gitlab.yourcompany.com in your internal network, but which just alerts SOC about login attempts. That's pretty much obscurity.
You can technically compute the private key for someone's Bitcoin wallet for example. It's just you'd hit the end of the heat death of the universe by then.
e.g. I move my SSH ports to a high port. But I also ed25519 keys. I think the port helps though. Plus keeps the logs clean.
You have any idea what kind of RAM and computing power an average user have access now days. Think of better obscurity abstractions than that.
Try bcrypt/scrypt hash your shadow password on linux.
I don't think anyone assumes when people say "security by obscurity" they mean "only" it is a great layer to add in addition to.
In my home for instance, the entire back of my house is hidden with 10 foot trees so when people drive by the road, they don't see my house. Now I've got a deadbolt, alarm, cameras, a dog, and a gun to add to my layers but having those trees there is a nice feature.
Security-by-obscurity doesn't replace real security of course, but it removes a lot of noise.
Exactly. I came here to say much the same thing, except with a non-digital analogy.
I live in a (relatively) small apartment building with five floors and four apartments on each floor.
I live on a floor that isn't the top or the bottom floor. That reduces the likelihood that someone who opportunistically gains access to the building entrance or the roof will attempt to access my apartment.
What's more, unless I'm being specifically targeted (which obviates any sort of obscurity argument, given that specific focus is given to a target rather than a service exposed by many), it's pretty unlikely that my apartment will be robbed since there are other, much more accessible apartments than mine.
That's the "security through obscurity" bit, which has a measurable, positive impact on the security of my home and belongings.
However, that doesn't mean locking my door is inappropriate or overkill.
In fact, if I am being specifically targeted, locking my door is likely not sufficient either, as an intruder could bash down my door or drill out the locks to gain entry.
I suppose I could install surveillance cameras focused on my front door (as well as inside my apartment), allowing me to identify intruders after the fact. And I could install safes to hold my valuables as well.
Each of those security precautions have some positive value, and absolutely contribute to the idea of "defense-in-depth".
That said, there is a real trade-off between increased security, cost and usability.
While the relative "obscurity" of my apartment confers some security value, it's not nearly enough to stop someone from trying all the doors in the building, so I lock my door. I don't, however, have safes in my home or surveillance cameras outside the door and in every room, as that (unless I'm being specifically targeted) doesn't add enough value to justify the cost of such measures.
Which brings us to the point of security -- which is to protect assets. However, if the cost expended (in resources and usability) is greater than the value of the asset(s) being protected, it doesn't make sense to do so.
Security through obscurity can (but doesn't always) provide a modicum of value, but isn't a complete solution itself. Used in conjunction with other, reasonable (in the context of cost vs. value being protected) measures, it can be a valuable tool.
A defense mechanism that only partially mitigates an attack vector could be considered 'security through obscurity' if deployed on its own, but that same mechanism could be considered 'defense in depth' if deployed alongside other defense layers as part of a more comprehensive security model.
If it's sheap (initial dev + maintenance + usability) then why not do it?
Using existing best security practices AND adding in a few low risk plot twists: genius.
No password -> simple password -> complex password
Plaintext -> Caesar cypher -> Vernier cypher -> modern cyphers
40-bit crypto -> 56-bit crypto -> 128-bit crypto -> 256-bit crypto
0.0.0.0 network allow-list -> /24 network allow-list -> /32 (per host) network allow-list
allow by default -> deny by default
standard port -> non-standard port
We just add layers of obscurity until they add up to "enough" and don't grow into "beyond tedious".
My algorithm is reorganized caesar with block encryption
And if it is open . . .
Every crypto system is based on obscurity of one kind or another. That private key, password, or token is just an obscure form of information that may yield, eventually, to a brute force attack. Or not. It's really hard to know for sure.
But food for thought: in the general case you can't reliability predict the efficacy of an obscurity mechanism, so you never know if it's an actual layer of defense or a placebo.
It was “do not rely on security by obscurity”
Obscurity also clouds maintainability, often making things difficult to diagnose and debug.
I think this article's fundamental flaw is that it conflates the concepts of obscurity and a secret.
To start with, a definition: a system is secure if an attacker has no reasonable chance of unauthorized access over a relevant period unless they are in possession of necessary secrets.
SSH with public-key authentication is secure by this definition, since the (remote) attacker has no realistic chance of guessing the proper secret key within a human lifetime and there is no better-than-chance way to obtain the secret key. Likewise, a strong, high-entropy password is impractical to guess.
Running on nonstandard ports, however? It doesn't add practical security because guessing is so trivial. The author's twitter reach had a 50/50 split on whether they scanned all ports for pen-testing, so that implies that using a nonstandard port increases the time-to-compromise from either (lifetime of the universe) or (about an hour) to twice that, depending on whether the second (real) layer of security is vulnerable. In neither case does the obscure port provide meaningful protection.
Some activities like port-knocking can add security, but only if the practitioner thinks of the knocking as a secret from the start. That requires:
* Limiting who has knowledge of the secret (i.e.: a port knocking routine known only to you is secret; one distributed in a public client for access to a production service is not), * Having plans in place to change the secret if it is ever compromised (DeCSS) or found to be flawed, and * Ideally ensuring that the secret cannot be guessed / confirmed independently of other secrets.
Other suggestions in the article ignore this difference:
* Database encryption requires an attacker to possess two secrets for extraction (internal access to the database plus the key) rather than just one. It's not obscurity. * Randomizing variable names or obfuscating code is not a secret because an interested attacker can reverse the obfuscation with ordinary human levels of effort. The confidence here is strictly false, since it "secures" against low-effort attackers and not high-effort ones. The "secret" is distributed publicly, so it is no secret at all. * The convoy example is again a secret; the point is that a would-be attacker does not know which car contains the target and has no reasonable ability to guess with better-than-chance success.
Obscurity goes from marginally effective (or outright ineffective) to counterproductive when its implementation makes it harder for the designer to reason about their own system. Someone who rolls their totally unique cryptosystem is relying in part on algorithmic obscurity for their security, but in doing so they give up on established (and battle-tested) best practices in favour of their own limited analysis.
Ultimately, the "Swiss cheese" model of security is a poor analogy because a big number for a human is a small number for a computer. To take the convoy analogy again, a would-be attacker is only going to get one shot, but a computer can try billions.
I find it somewhat interesting that the article uses an example which falls right into another pitfall that "security vs obscurity" is trying to prevent.
> SSH runs in port 64323 and my credentials are utku:123456. What is the likelihood of being compromised? > > Now we changed the default port number. Does it help? Firstly, we’ve eliminated the global brute forcers again since they scan only the common ports. ... So, if you switch your port from 22 to 64323, you will eliminate some of them. You will reduce the likelihood and risk.
This is technically correct. However, the author has identified a security concern that he wants to mitigate: brute force attacks. Now, you could try and reduce that risk by using a different port which might reduce it by 50%, or* you could fix this issue by deploying fail2ban (or using ssh keys, or VPNs and bastion boxes, etc), and thus negating that attack vector entirely. There isn't even a usability argument here: making people remember the right port for ssh is less usable than setting up fail2ban. Of course there are tonnes of other attack vectors to consider, but in general where possible its better to "properly" (fsvo.) mitigate those concerns and only rely on obscurity where that isn't possible. If a concern is mitigated than adding obscurity does almost nothing, while likely proving to be more annoying to the end user (like in the case of specifying a port in the above example).
Now of course that's not to say that you should never use obscurity, but if you do then I think its entirely reasonable that you are prepared to give a good justification why its appropriate. For example, sharing via secret URLs is a good example where it can be easy to justify in some settings, but it equally may not be OK for documents that are really really sensitive as its relatively easy for links to be shared in error with the wrong people.
RE some comments about using obscurity to signal that your deployments would be harder to get into and thus for attackers to not bother: I'd genuinely love to know if that is true or not, I wouldn't be surprised if attackers assumed obfuscation mean that the more advance security measures hadn't been deployed (otherwise why bother with obfuscation?).
* Based on the twitter poll in TFA, though if you have a targeted attack it seems sensible to assume that if port 22 doesn't work they'd try again with other methods
The reality is security by obscurity CAN work, but only if three critical elements are met:
The first is to know when the obscurity has failed
The second is to be able to quickly change the obscured component (e.g. a password)
The third element is the hardest, security by obscurity only really works if you can survive exposure of the obscured data/system
Which leads to the fourth element: security through obscurity IS NOT security through secrecy (so either I'm a liar or bad at counting, leave your vote in the comments below)
Let's start with the 4th element, obscurity vs secrecy. Passwords. Passwords generally only work if they are secret. Some password systems like Kerberos take great pains to ensure passwords remain secret, for example by NOT sending the password itself to a remote system, but by sending proof that the user has the password (grossly simplified, but generally correct, now you understand Kerberos!). Secrecy involves hiding things that if exposed will be a problem that can't be solved, like your password, the formula to Coca-Cola and so on.
Obscurity won't work for things that need to be secret. Obscurity won't work for things that once exposed result in the game ending.
Even when an item can be obscured, it is still important to know when it is no longer obscured, otherwise you now have an element of your security system that has effectively been breached. For example if you are using randomized port numbers to prevent SSH scanners from constantly trying default username/password combinations and someone (like shodan.io) port scans you and publishes your SSH server ports you either need to change that, or not be relying on that obscurity for your security (e.g. I used to change my SSH port #'s just to reduce logging activity and make it easier to filter/read logs for actually malicious activity).
The second element is that once your obscurity becomes known you need to be able to change it, if you can't change your SSH port # (because you don't have a way to tell clients where it is) then you have a security control that cannot be recovered and you lose it. Security elements should always strive for long term survivability because the simple fact is attackers get to try more than once.
The third and final element (because we started counting at 4!) is your system cannot simply fail because the obscure element was discovered. Using a no standard port for SSH works if you also use strong passwords or (ideally) key based login. Obscuring SSH ports and leaving a default admin:1234 login is brittle, and as evidenced by scanners like shodan.io easily exploited.
I think, honestly, the best use case for "security by obscurity" is to cut down on the noise of logs and casual scanning/scripted hacking, which can be valuable, having less chaff to sort through for actual attacks can both save time and money, but also give you a better chance of finding the real attacks.
https://app.voice.com/post/@kurtseifried/making-security-by-...
We'll look at the SSH port example.
What does changing the port get you? You no longer get hit by the automated sweeping that hits basically all internet accessible IPs. Cool! So you had root/password or root/apple or whatever, you were going to get owned by the automated scans, good, you're now more secure. But you shouldn't have been using a weak password to begin with, and now there is a very real risk that you think you are more secure than you were previously.
He compares this to animals that have natural camouflage, or the President switching cars in his convoy. But there's no guarantee that you will see an owl in a tree, or be able to determine which car the President is in. But you can scan every port on an IP and find sshd listening with fingerprinting. The cost there is basically zero for someone that wants to attack you. If all I had to do was wait a few seconds longer to make sure I saw an owl or know what car the President is in, then they would not be effective either. You cannot compare situations where there are specific limitations and use them as proof positive for a situation where those limitations don't exist.
And this is important: His recommendation to run sshd on 64323 is also just actively making you LESS secure. Ports under 1024 are privileged on Linux - you must have superuser privileges or otherwise be granted access to bind to these ports. No such protections exist for 64323. Now, let's say you have a user level compromise on that server - they start a process monitoring to see if sshd ever restarts/crashes/otherwise stops listening on the port it was listening on, and as soon as it does, they start their own malicious sshd replacement. Now all it takes is someone ignoring the host key mismatch to give away their credentials, which the attack can then likely use to penetrate further into your environment.
The author doesn't fully understand the add on effects of his suggestion here, and as a result one of his security by obscurity tips makes you less secure to a focused attacker. Meanwhile, if you REALLY wanted to secure SSH you do not make it listen on internet accessible IPs, and only have it available when you VPN in and access it via a jumphost while using key based auth with 2FA on top of it.
When you start obfuscating your code, using random variable names, and generally making it harder to read, how much more likely are you to introduce bugs than you would with a clean code base? Are human introduced bugs more likely to be a security risk than variable names being random? Than code being obfuscated?
I don't disagree with encrypting the database, but I also don't consider encryption or password/key protecting something security by obscurity.
Basically: Obscuring things helps prevent you from low effort attackers that should not be scary to you to begin with. They do nothing to minimal amounts to protect you from dedicated attackers, and potentially introduce new risks that allow easier access from dedicated attackers. The sort of security measures you should be implementing to stop dedicated attackers will already eliminate the risk from the low effort attackers.
NONE of the arguments in this article are new, and they have all been argued against quite extensively in the past.
The phrase is used to suggest developers shouldn’t think that obscuring something provides security. We don’t say not to obscure stuff. In fact all the examples in the articles are from what’s already used in products. So the security community uses the best available method to secure the given task/stack already.
Changing the RDP port is a slightly better example of actually using security through obscurity as a defensive layer because Microsoft doesn’t give you any good ways to lock down RDP (best practice is of course keeping it behind a VPN or using a Remote Desktop solution with a more modern authentication system), but from a practical point of view I know several companies that were hit with ransomware this year via RDP on a non-standard port. I think they would rate the risk reduction from that approach pretty low.
Finally, symmetric database encryption is not an obscurity measure, as the author himself points out it specifically protects data against an attacker who can query the database but not find the key. Whether the attacker can get the key is a matter of capability not determination or luck.