The bad rep is probably due to too many people having used Obscurity as an excuse to hide the fact the actual security was, at best, an after though for their product.
Security by obscurity is underrated
171–180 of 530 posts
Re: Security by obscurity is underrated
#172Earlier quoted context omitted.
Agreed. The maxim warning against "security from obscurity" is often reduced to an irrational comprehensive avoidance of obscurity. It's similar to the irrational avoidance of all performance optimization because Knuth warned of premature optimization. Both reductions lose practical utility by omitting nuance. * Avoid wasting your time doing performance optimization until tuning is necessary. But definitely take obvi…
> 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. 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'…
I would call that system secure. It does not just rely on an obscure password but is actually restricted by a list of whitelisted networks.
The failure in that case is only that the admin didn't consider that normal work might be done from home at some point or that the middle or upper manager thinks that he should be able to freely administrate his critical infrastructure from anywhere...
Re: Security by obscurity is underrated
#173I agree. If I run my SSH and my VPN on non-standard ports, the number of probes I get a day goes from hundreds to one or two.
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.
Re: Security by obscurity is underrated
#174It seems to me that the article is missing a few of points on what "security by obscurity" means. 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…
Indeed, the "real-world" examples suffer from two problems:
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.
Re: Security by obscurity is underrated
#175Earlier quoted context omitted.
Using obfuscation is often a signal that you are a weak target, because there are a lot of places that use obfuscation but nothing else. A better indicator that you are a hard target is to enable common mitigations like NX, stack cookies, or ASLR.
There is one giant hole in your argument: both stack cookies and ASLR are mitigations that are nothing more than automated security through obscurity in the first place.
I assume you're equating picking a random SSH port with scanning for an ASLR slide or guessing a stack cookie, but they are different situations: processes that die are generally treated quite seriously, and they leave "loud" core dumps and stack traces as to what is going on–usually this gets noticed and quickly blocked. With SSH you can generally port scan people quickly and efficiently in a fairly small space (and to be fair, 16-bit bruteforces are sometimes done for applications as well, when possible)–and the "solution" here where you ban people that seem to hit you too often is literally what you are supposed to be running in the first place.
And in general, the sentiment was "if you are using those things, you are likely to have invested time into other tools as well such as static analysis or sanitizer use" which are not "security through obscurity" in any sense, whereas the "obscurity" that gets security people riled up is the kind where people say things like "nobody can ever hack us because we changed variable names or used something nostandard" because it is usually followed with "…and because we had security we didn't hash any passwords".
Re: Security by obscurity is underrated
#176Earlier quoted context omitted.
But the examples given won't help and is just bad advice in general. - 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 y…
You seem to be thinking in terms of security mechanisms either perfectly blocking attacks or being useless. That's the wrong model. It's about costs. Obfuscating otherwise-open code doesn't mean that nobody can ever figure out what it does, but it raises their costs. Randomizing variables raises costs. Encrypting the DB raises costs on an amortized basis (some cracks may get the key and then it may not raise the cost…
It's still bad security.
Sure, it increases costs for a certain subset of attackers. Instead of sending easily found and trained young Arab men, they have to put more effort into recruitment. However, in return for that, they get far reduced scrutiny.
Therein lies the problem. It is the real-world equivalent of dropping all packets from a country instead of properly analyzing the packets. You'll stop the low-cost automated garbage attacks, but you won't stop a dedicated attacker, even if the attacker is in that country.
Re: Security by obscurity is underrated
#177Agree with the article. 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…
Hell yes, couldn't agree more.
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.
Re: Security by obscurity is underrated
#178It seems to me that the article is missing a few of points on what "security by obscurity" means. 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…
I agree with your understanding of security by obscurity. But I think the popular understanding has started to be more along the lines that the author counters. That if any security measure is "obscurity" then don't do it, it's bad.
This is the problem with "sound bite" bits of conventional wisdom. The more it's used and misused, the less it's actually understood. People hear "Security through obscurity is bad" and just interpret those words however they want without listening to the rest of the actual advice being given.
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.
Re: Security by obscurity is underrated
#179It seems to me that the article is missing a few of points on what "security by obscurity" means. 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…
>ssh non-standard port is actually a good thing given the massive amounts of bots around 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, o…
Never thought about this before, but is this a tunable thing in the kernel config? Some way to signal to the OS "only use port ranges above 16382 for unpriv" and move the boundary up?
Re: Security by obscurity is underrated
#180I'm surprised port knocking never really caught on. Does anyone know of it being used in production anywhere?
port knocking is just, another way of doing a password, right? It's pretty much just a PIN code with a slightly obscure method of inputting the digits. 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?
if this traffic were intercepted- you'd be able to see port numbers, right?
Sure but I hope the service you're opening up with the knock is actually secure like ssh.
The idea is just that you cant portscan to find something to attack. Its basically the same reasoning behind using non standard ports, but takes it a bit further.