Earlier quoted context omitted.
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…
> 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. This is something that bothered me quite a bit in Bruce Schneier's various comments on airline security. He repeatedly wrote that profiling young Arab men as likely terrorists was pointless, because if it became harder for young Arab men to get through security, terro…
Security by obscurity is underrated
121–130 of 530 posts
Re: Security by obscurity is underrated
#122Agree 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…
An argument against obscurity is that it adds additional pains for your "regular" users (as in developers/3rd party developers/app developers) while being a small deterrent against unauthorised users (as they will be able to circumvent the "obscurity layer" and replicate their method to other bad actors). edit: In the first sentence "against" is not what I wanted to say: what I wanted to say is that it "downgrades it…
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.
Re: Security by obscurity is underrated
#123I've used some very tight-arsed VPS providers at the low range (128MB/1IPV4/$12 a year) and some of them mention a high load, and it's mainly due to brute force on port 22. 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 o…
You miss 100% of the shots you don't take applies to hackers as well.
Re: Security by obscurity is underrated
#124Earlier quoted context omitted.
> Just use SSH keys, and disable passwords. 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 con…
Only the 4th point is really true: if you run SSH on a non-standard port but it's otherwise accessible, you'll still see scans on a regular basis. 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 monit…
Possibly.. It does depend on the port. 222 and 2222 often are scanned with 22. 2200-2299 is probably common now. I was using 2221 for a bit but after a few years that started seeing some auth attempts.
I mostly watched entire /16s, not single hosts.. the scan patterns for a large netblock are very interesting. It takes as much effort to scan the entire internet on port 22 as it does to scan all ports on a /16.. attackers simply do not do that.
The benefit of some of the port knocking systems is that the attack surface is almost nothing and they are easy to audit. I used it a few jobs ago on my management system/bastion host. I couldn't rely on the VPN since I was the one that managed the VPN, so I needed a way to securely login remotely that did not go through the VPN, and did not end up having sshd exposed to the world.
These days I run sshd at home behind https://www.tarsnap.com/spiped.html
Ubiquitous wireguard may change things.. we'll see.
Re: Security by obscurity is underrated
#125Re: Security by obscurity is underrated
#126Earlier quoted context omitted.
> But then we all implement passwords (which is just security by obscurity) No it isn't. Security by obscurity is explicitly keeping things other than passwords and keys secret.
I feel like it's a pretty weak point to say that passwords and keys would be security by obscurity if we didn't carve out a special exception for them. Why do they get a special exception? Because they're really really hard to guess, not because they're fundamentally different. Let me give a real-life example of a good non-password, non-key piece of secret information that's used for authentication. If you need to re…
Hiding your password isn't security through obscurity. Hiding the fact that you need to say a password to get into a building is.
Protecting your encryption keys isn't security through obscurity. Hiding which encryption algorithm you are using is.
Re: Security by obscurity is underrated
#127Earlier quoted context omitted.
> But then we all implement passwords (which is just security by obscurity) No it isn't. Security by obscurity is explicitly keeping things other than passwords and keys secret.
I feel like it's a pretty weak point to say that passwords and keys would be security by obscurity if we didn't carve out a special exception for them. Why do they get a special exception? Because they're really really hard to guess, not because they're fundamentally different. Let me give a real-life example of a good non-password, non-key piece of secret information that's used for authentication. If you need to re…
Re: Security by obscurity is underrated
#128Agree 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…
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…
Re: Security by obscurity is underrated
#129In 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.
Re: Security by obscurity is underrated
#130There's something to the idea of rehabilitating "obscurity", or at least recognizing that "cost" is part of threat models, and you can raise costs for particular attack vectors by degrees instead of "to infinity". 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", o…
> There's something to the idea of rehabilitating "obscurity", or at least recognizing that "cost" is part of threat models, and you can raise costs for particular attack vectors by degrees instead of "to infinity". 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.