Live data from Hacker News

Security by obscurity is underrated

utkusen.com

321–330 of 530 posts

Re: Security by obscurity is underrated

#321
post #68

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

You’re only considering one side of the costs. Obfuscation mechanisms also impose a cost on your legitimate users. There’s lots of reasons why you want your users to actually buy in to using your security controls, and annoying controls with highly questionable effectiveness is the best way to kill that buy in. Users will only tolerate so much burden from user facing controls, so you want to make sure all of the controls you impose upon them are actually useful.

The other thing that’s harmful is relying on something to provide security, when it actually can’t. That’s actually going to have a negative impact on your threat model. People will say (they’re even saying it in this thread) that their port knocking or non-standard port usage has cut out the port scanning noise in their logs. But who cares? A properly secured ssh port isn’t going to be cracked by an automated scanning tool. But a poorly secured hidden one will be easily found and cracked by any motivated attacker. You have to implement the proper control anyway, and the obfuscation one ends up providing no benefit while simply annoying your users.

Security by obscurity is dumb, it doesn’t provide any benefit. Security in depth doesn’t mean multiple layers of controls that don’t work add up to one that does. Obscurity is just a way of spending your scarce resources on controls that don’t work, and wastes your scarce command of your users attention on controls that don’t work. So in reality, they’re also always coming at the opportunity cost of controls that actually do.

Re: Security by obscurity is underrated

#322
Security by obscurity naturally transform security into a probability. When you use given hard opaque rules (e.g. TLS + X Y Z) you stop thinking in depth.

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.

Re: Security by obscurity is underrated

#323
post #29

To me this seems like a bit of a strawman argument. 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 al…

There is a bit of a debate here. Apache docs state ServerTokens should not be set to anything less than minimal(https://httpd.apache.org/docs/2.4/mod/core.html#servertokens) which contradicts the OWasp recommendation (https://wiki.owasp.org/index.php/SCG_WS_Apache#Server_Token_...).

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.

Re: Security by obscurity is underrated

#324
post #207

Earlier quoted context omitted.

The number of times I've seen people shitting all over port knocking is truly confusing. Since we added it several years ago, we've not had a single case of hackers trying to break into sshd. Before port knocking, 100's a day, even though it was on a very unusual port. I try to tell people this, when they poo poo port knocking, but they just don't get it. EDIT: s/the/they/

But serious question -- what exactly is the benefit? Before, it's not like they were getting in anyways if you were using keys. 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…

There have been bugs found in SSH server implementations that allowed limited remote code execution or even authentication bypasses. Missing an update or two isn't bad when nobody can figure out how to connect to your server.

Of course you have to update at some point. However, if someone drops a zero day on your SSH server while you're asleep you're probably glad that you've got a secret sauce to protect your server, letting the vulnerability bots focus on other servers.

Re: Security by obscurity is underrated

#325
In my opinion the SSH example with a non default port, random username and easy password is a perfect example of a bad kind of security through obscurity: instead of a user friendly and foolproof approach (disabling password authentication and using keys), we introduce multiple layers of obscurity that make life harder for the sysadmin and users, which collapse as soon as someone creates an account on the box without a sufficiently obscure name. When it inevitably fails (either because of the aforementioned reason or because a global scanner has the clever idea of trying some more obscure usernames) everyone looking back on it will wonder why you built this Rube Goldberg machine instead of just using SSH keys.

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.

Re: Security by obscurity is underrated

#326
In Applied Cryptography, Schneier says obscurity is "take a letter, lock it in a safe, hide the safe somewhere in New York".

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.

Re: Security by obscurity is underrated

#327

Earlier quoted context omitted.

I think a lot of the people in this comment thread are missing the point when using the `sshd` example. There is no single infallible way to secure ssh, but there are a lot of things that can be done together to make it pretty darn hard to hack, and most of those countermeasures have some degree of 'obscurity' to them. Example: * Use RSA keys instead of passwords -> This will eliminate most risk, except for exploits…

Each security measure has a value and a cost. Keys over passwords provide by far the best value/cost ratio. Using obscure ports or port knocking or whitelisted IPs are relatively clunky mechanisms that are more expensive and obscure your security posture as much to yourself as to adversaries.

>obscure your security posture as much to yourself as to adversaries

Almost barfed from sheer intensity of tech corpobabble. Its for blocking 0-days dummy!

Re: Security by obscurity is underrated

#328

Earlier quoted context omitted.

The same with "GnuPG is bad" mantra on hackernews. There is nothing better that GPG currently for all its functionality and the only answer you get when asking for substitute is don't use this function or use some obscure application. Yeah right.

I agree that there is nothing better than GPG for the narrow scope of encrypting email. But I think there are very few cases where encrypted email is the most secure way to communicate, in lieu of other forms of encryption.

Encrypted email is almost a marginal usage scenario for GPG compared to other uses. It does everything. It is everywhere.Yes it is big, nobody has to use all of it. Just like C++... oh wait it is unpopular on hacker news bubble too despite being a juggernaut of a language. It will still be relevant long after hacker news will be no more.

Re: Security by obscurity is underrated

#329
These days you have to assume hackers have read the engineering new hire guide that you wrote up. The SSH port will probably be in there.

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.

Re: Security by obscurity is underrated

#330
post #58

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

This is the reason the 'portreserve' application exists.
Post reply on HN