Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Security by obscurity is underrated

utkusen.com

Post reply on HN
Print view View original

191–200 of 530 posts

Re: Security by obscurity is underrated

#191

Post by gowld »

PragmaticPulp wrote: post #122
KarlKode wrote: post #38

Earlier quoted context omitted.

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…

When security is totally impossible because there is no way to distinguish a trusted party from an adversary, obscurity is the only hope.

Re: Security by obscurity is underrated

#192

Post by cat199 »

iso1631 wrote: post #162
bhauer wrote: post #143

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

> Except that can lead to operational problems down the road.

in the example you mention the 'security' is working by design, but the operational parameters changed which in turn made that security model unsuitable - so it is the parameter change, rather than the 'security' is what led to the problems.

The original system could have been just as 'obscure' but also included an appropriately secured mechanism that allowed for this kind of remote access / disaster scenario.

Re: Security by obscurity is underrated

#193

Post by gowld »

jfk13 wrote: post #131
czzr wrote: post #112

Earlier quoted context omitted.

But it’s easier to find Arab women. Or an Irish girlfriend of an Arab man. Or two old Korean people. (All real examples)

I'm pretty sure the potential recruitment pool of young Arab men is still many times greater than the pool of Irish girlfriends of Arab men. It's about improving the odds/reducing the exposure, not achieving some theoretical absolute perfection.

It's bad math. It doesn't matter if you have 1 arab man and 1 korean woman, or 1000 arab men and 1 korean woman. You only need 1.

If you calculate the probabilities correctly, you get very different results.

Re: Security by obscurity is underrated

#194

Post by Sebb767 »

justinsaccount wrote: post #69
tptacek wrote: 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…

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

> * The boxes using port knocking would be safe.

No, safer. It is very well possible to brute-force port knocking or eavesdropping the ports since that information is not encrypted. Is it harder? Of course, a lot, but if you think scanning 65k ports on each host on the internet is reasonable, then evading a port knock is very much, too.

Re: Security by obscurity is underrated

#195

Post by scarmig »

yabones wrote: post #165
tptacek wrote: 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…

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.

Re: Security by obscurity is underrated

#196

Post by thinkharderdev »

mercer wrote: post #64
_tk_ wrote: post #45

To maybe give some perspective _why_ security people say that security by obscurity is bad - and especially serving ssh via port 64323: Typically you want to know who is connecting to what server via what service and log these connections. If something is off, an alert can be generated. If ssh isn't served on a standardized port, logging and alerting becomes more complicated - albeit not impossible. There is more hou…

> Typically you want to know who is connecting to what server via what service and log these connections. If something is off, an alert can be generated. If ssh isn't served on a standardized port, logging and alerting becomes more complicated - albeit not impossible. Could you elaborate on that? I serve ssh on a non-standard port precisely in part because it drastically cut down on the noise of failed log-ins, to th…

Not the OP but I assume what they mean is that if you have network-wide monitoring across a network with lots of servers then it won't be able to easily make sense of what is happening if servers are all using non-standard ports for things.

Re: Security by obscurity is underrated

#197

Post by anonu »

I seem to recall a story about how a remote server would open a port only after a few unsuccessful calls in sequence to a pre-determined set of ports right before.

I've always wanted to set up something like this - but it seems like a pain to remember everytime i want to connect..

Re: Security by obscurity is underrated

#198

Post by nordsieck »

thinkharderdev wrote: post #149
bleepblorp wrote: post #120

Earlier quoted context omitted.

Using a non-standard SSH port is a bad example because nmap can see through that deception in a few seconds. Any attacker who is looking for more than just the lowest of low-hanging fruit will not be even slightly deterred. A better example would be a port-knocking arrangement that hides sshd except from systems that probe a sequence of ports in a specific way. This is very much security by obscurity, because it's tr…

Maybe a bit nitpicky but I think port-knocking is in kind of a grey area. You can think of it as a kind of password where you have to know the correct series of ports. Since the number of ports is quite large, there is also a correspondingly large number of possible port sequences so you can't, in principle, brute force it without a lot of effort.

> Maybe a bit nitpicky but I think port-knocking is in kind of a grey area. You can think of it as a kind of password where you have to know the correct series of ports.

Yes.

But you also have to know that port knocking is enabled at all. That's the obscurity part.

Re: Security by obscurity is underrated

#199

Post by gowld »

umvi wrote: post #133
weare138 wrote: post #114

Earlier quoted context omitted.

Let me give you an example. At a previous job as a devops, of my predecessors frequently used these "techniques, minus the encrypted database but I sure he would have done it if he knew how. So there was some buggy internal app they needed some new features added to and the person who wrote it thought he was clever and obfuscated the code. It took me a whopping 30 minutes churn through his 'clever' obfuscation scheme…

> I'm going to find whatever port your running ssh on if your running it. Not if you have to port knock before the ssh port is open to new connections.

Why not? I'll run my automated port knocker

Re: Security by obscurity is underrated

#200

Post by joelthelion »

tptacek wrote: 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…

> Just use SSH keys, and disable passwords

Or even use a good password, if you don't have many untrusted users. It works perfectly.

Post reply on HN