Live data from Hacker News

Security by obscurity is underrated

utkusen.com

121–130 of 530 posts

Re: Security by obscurity is underrated

#121
post #68

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…

The point is that if you try to be a selfish bigotted dick and create profiling to shift the inconvenience of security delays onto the other you create a gaping hole for that shortcut - don't look the part and then do damage. It is a bad policy morally and practically meaning the only rational reason to support it is being an asshole who sees the harm as a good.

Re: Security by obscurity is underrated

#122

Agree 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…

> An argument against obscurity is that it adds additional pains for your "regular" users (as in developers/3rd party developers/app developers)

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

#123

I'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…

> less opportunists = less opportunities.

You miss 100% of the shots you don't take applies to hackers as well.

Re: Security by obscurity is underrated

#124
post #87

Earlier 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…

> 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.

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

#126
post #83

Earlier 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…

Security by obscurity refers to obscuring the design of a system, not obscuring credentials.

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

#127
post #83

Earlier 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…

Except this is the kind of thing that you can get around if you know the person and/or the account.

Re: Security by obscurity is underrated

#128

Agree 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…

Isn't there some model where the keys that you use to decrypt the database are acting something like one time codes, and you have to use particular credentials to access the key server? So the attacker would need to be able to stay in the network to be able to actually access the data -- they couldn't just download the entire database and crack it offline. I don't know how that actually is implemented, but just curious on that.. I also wonder how many people put things in their various systems that are obvious attacker trip-mines -- like having some fake button that says like "copy image of database to disk" or something that the actual internal employees are told to never click that button -- but maybe they have even some confluence page that talks about "how to download the database", but is actually a fake entry meant to trip up an attacker in case they get access to your confluence pages as well as your database.. so they click that button and the admins get alerted...

Re: Security by obscurity is underrated

#129
Security is not just about preventing attacks, but also about detection and response.

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.

Re: Security by obscurity is underrated

#130
post #27

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". 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.

DRM has the problem that it is illegal to bypass, even if your intent is not malicious.
Post reply on HN