Live data from Hacker News

Security by obscurity is underrated

utkusen.com

211–220 of 530 posts

Re: Security by obscurity is underrated

#211
post #60

Earlier quoted context omitted.

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?

Well, yes. But where would the attacker be if they are in a position to intercept the traffic? The answer to that may dictate if the technique would have value for you.

I'm just saying that port knocking just results in another secret you have to manage. It's just adding another locked door. Why use a locked door that's a pain in the ass and insecure in transit?

If you want two layers of secret-based auth- why would you make your second layer one that's objectively less secure and more unwieldy than other layers?

Re: Security by obscurity is underrated

#212
I run a cyber software company with a product basically structured on this principle (deception.)

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.

Re: Security by obscurity is underrated

#213
post #186
post #155

Earlier quoted context omitted.

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.

How so? Stack cookies and ASLR are a form of encryption, where an attacker had to guess a random number to succeed in an attack. Obscurity really just boils down to a secret that doesn't have mathematical guarantees. It's doing something that you think the attacker won't guess, just like an encryption key, but without the mathematically certified threat model, so you just hole that the attacker is using a favorable p…

The attacker who had already compromised the integrity of the system in question has to guess or probe for a random number with relatively low entropy in order to do something useful and straightforward with that already compromised system.

Re: Security by obscurity is underrated

#214
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…

This is actually the misunderstanding that the author is talking about: 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. Slowi…

> This is actually the misunderstanding that the author is talking about

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.

Re: Security by obscurity is underrated

#215
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…

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

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% - "
[1] knockd on FreeBSD, 10+ years, not one hang or crash.

Re: Security by obscurity is underrated

#216

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…

I agree.

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.

Re: Security by obscurity is underrated

#217

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…

It is obviously a misinterpretation of the original idea behind "security by obscurity is bad". Same goes for "goto considered harmful", which is not always true.

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.

Re: Security by obscurity is underrated

#218

Do we feel that honeypots might actually be one form of this? I.e. something that isn't deterministically going to prevent an attack like a OTP cryptographic scheme, but that may trick a large majority of attackers into thinking they are actually in a secure production system for a long time. I know they are used primarily for detection, but why not go the extra step and make a honeypot that is a truly believable fac…

Preface: May be biased, as I run a honeypot company.

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.

Re: Security by obscurity is underrated

#219

Earlier quoted context omitted.

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

I don't believe it's an easily changeable tunable with a config flag or sysctl setting, no. You could of course modify the kernel source code, but there's probably lots of unintended side effects to this - your setting is alright for most Linux distros, but what if someone picked one that overlapped with ephemeral port ranges? Or if you're running software that the commonly used port binds to something under 16382 but above 1024 - now you have to reconfigure it, or set up temporary privilege escalation so it can bind to it before going back down, a la httpd.

It's also a bit of a contract with the client - on Linux something below 1024 is ALWAYS privileged so you know you're not connecting to a fake sshd and giving away your password or current 2FA token unless that system has been totally owned. If you modify the kernel you're modifying that contract - are you sure that this system has modified kernel?

That's really my issue with this whole idea (and one of my top level comments goes into this in more depth) - but there's a lot of unintended side effects from these obscurity changes that people don't know about or think about.

Meanwhile there's lots of well understood practices that provide real security that solve both the issue of noisy low effort attacks while also providing real security against determined attackers. VPNs and jumphosts - why should SSH be internet accessible in the first place? Use key based auth, as well as 2FA.

Port knocking is... interesting... in theory, but it increases complexity for the users at a similar level of requiring them to use a VPN or jumphost (or both), but has additional flaws that they don't have - if they have access to sniff your traffic via some means, they can figure out the sequence and now they have completely removed it as a layer of security. They don't even need to be able to decrypt the traffic - just see the destination ports.

Is this level of attack something most of us have to worry about? No. But if for similar levels of effort we can get better security, why would we go for the weaker form, even if it's unlikely we need more? If for some reason you do have a dedicated attacker, you're better prepared. You can also extend it to provide even more security - lock down SSH to all of your production hosts to only the jumpbox(es). Alarm on any attempt production host to production host SSH attempts. Easily audit ingress SSH access on a subset of hosts. etc.

Re: Security by obscurity is underrated

#220
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…

> The claim was never that using obscurity is bad and should be avoided. 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 vali…

> Obscurity is bad because it makes you _think_ it adds security.

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.

Post reply on HN