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

381–390 of 530 posts

Re: Security by obscurity is underrated

#381

Post by leeoniya »

bleepblorp wrote: post #120
acoard wrote: post #101

Earlier quoted context omitted.

>I think we can kind of view obscurity in the same way. It's a way to signal to a predator that we're a hard target and that they should give up. This has it completely backwards. Security through obscurity's goal is not to signal predators, it's the opposite. The goal is to obscure, to hide. The "signal" is there is nothing here (or nothing here worth your time). One of the best examples (it's in the article!) is ch…

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…

> [port-knocking] is very much security by obscurity, because it's trivial for anyone who knows the port sequence to defeat

in what way is this different than a passphrase you don't know? i can trivially defeat any password which i already know, too :D

while discovering a non-standard ssh port is easy, discovering a port-knock sequence out of a possible ~65k per knock is impractically difficult (assuming the server has any kind of minimal rate limiting). a sequence of eight knocks will need 65k^8 attempts - and that's assuming you already know which port will be opened, which of course you won't.

you can even rely on just port-knocking of 8 ports and already get ~2^48 bits of entropy, which is about the same strength as a random 8 char alpha-numeric latin-charset password.

(someone plz check my math)

Re: Security by obscurity is underrated

#382

Post by kstrauser »

weare138 wrote: post #371
kstrauser wrote: post #166

Earlier quoted context omitted.

> I'm going to find whatever port your running ssh on if your running it. I still think it's a good idea. With SSH on port 22, ten thousand bots plus an attacker try to hammer it (so says fail2ban). With SSH on port 9278, zero bots plus an attacker try to hammer it. By throwing away the 99.99% of the chaff, you can see the remaining wheat you care about. Changing SSH ports isn't about saying "yep, we fixed it!" and c…

But new people in the industry shouldn't think that the things recommended in the article should be used as a primary defense and are accepted industry practices. Moving SSH to a new port to reduce false security alerts is one thing, having people read that article and walk away thinking this is how we do things is another. We don't.

I didn't take that away from the article at all. It said:

> So let’s talk about security by obscurity. It’s a bad idea to use it as a single layer of defense. If the attacker passes it, there is nothing else to protect you. But it’s actually would be good to use it as an “additional” layer of defense. Because it has a low implementation cost and it usually works well.

I think it's good to do those things in addition to the other stuff. Obscurity isn't sufficient by itself, but is another layer of defense.

Re: Security by obscurity is underrated

#383

Post by Symbiote »

kaydub wrote: post #362
cthalupa wrote: post #230

Earlier quoted context omitted.

I know we've spoken in another thread, but I think it's important for people to understand that this sshd thing is a perfect example of why it isn't this easy: You reduce log spam moving to a non-privileged port, but also reduce overall security - a non-privileged user can bind to a port above 10k, but can't bind to 22. sshd restarts for an upgrade, or your iptables rules remapping a high port to 22 get flushed, that…

Yeah, I'm seeing a lot of nonsense in here. Why is SSH publicly accessible in the first place??? Security through obscurity is just some feel good bullshit.

Why shouldn't SSH be public? It is useful and simple to secure.

Re: Security by obscurity is underrated

#384

Post by wglb »

e40 wrote: post #207
cataflam wrote: post #13

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…

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/

we've not had a single case of hackers trying to break into sshd. that you are aware of.

Re: Security by obscurity is underrated

#385

Post by dang »

ThA0x2 wrote: post #247
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…

>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. This just shows how ignorant you (and most) are on the topic of port knocking. SPA port knocking is cryptographically secure and does not suffer from replay attacks. Similarl…

No personal attacks in HN comments, please.

https://news.ycombinator.com/newsguidelines.html

Re: Security by obscurity is underrated

#387

Post by Spooky23 »

acoard wrote: post #101
Verdex wrote: post #65

Earlier quoted context omitted.

In nature, prey animals will sometimes jump when they spot a predator[1]. One of the explanations is that this is the animal communicating to the predator that it is a healthy prey animal that would be hard to catch and therefore the predator should choose to chase someone else. I think we can kind of view obscurity in the same way. It's a way to signal to a predator that we're a hard target and that they should give…

>I think we can kind of view obscurity in the same way. It's a way to signal to a predator that we're a hard target and that they should give up. This has it completely backwards. Security through obscurity's goal is not to signal predators, it's the opposite. The goal is to obscure, to hide. The "signal" is there is nothing here (or nothing here worth your time). One of the best examples (it's in the article!) is ch…

You can’t compromise what you can’t see.

Calling an administrator account “9834753” obscures it’s purpose and may reduce the likelihood of a compromise attempt as opposed to “databasesuperadmin”. But that doesn’t mean that you don’t need a good security token.

Re: Security by obscurity is underrated

#388

Post by wglb »

jerf wrote: post #68
weare138 wrote: post #44

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…

> but it raises their costs.

I would ask by how much.

Having to perform source audits on code with obfuscated variable names added almost no time to the task.

Again, these methods work against not-so-determined attackers. If you as a defender have limited resources, where would you choose to spend it--on defending against unskilled attackers, or attackers that are more likely to cause you damage?

>but when the costs to those actors exceed the loss you may experience.

There are several problems with this logic. First, it kind of presumes that there is a symmetry in the costs for the attacker and defender. Wise defenders will use methods that have high leverage. Also, the attacker doesn't care at all about your costs. They care about what they can get from you--whether it is access to something that you aren't thinking of, or your crown jewels.

Encrypting databases is sometimes required by compliance, but is no defense against a good attack.

Re: Security by obscurity is underrated

#389

Post by adrr »

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.

Less secure than a password because anyone sitting in the middle can observe the sequence.

Re: Security by obscurity is underrated

#390

Post by wglb »

umvi wrote: post #72
weare138 wrote: post #44

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…

> Assume for every code obfuscator there's a deobfuscator or at least someone as clever as you out there. There is still some information lost in the process: - "let eigenvector_coefficient = 23" => "let x = 23" A de-obfuscator isn't going to be able to recover the valuable information contained in the original name. Will it stop a determined attacker? Maybe not, but it would surely slow them down as they now need to…

>Believe it or not, nuisances are enough to stop some people. A lot of would be attackers are just cruising for low hanging fruit.

It is not "some people" that I worry about. I worry about attackers with a level of skill.

As I noted elsewhere in the thread, I have audited obfuscated code and the obfuscation is only a speed bump. I can only presume that attackers are smarter than I am, and obfuscation is effectively not an issue. And it is not an order of magnitude. This is another example of developer thinking that this form of obscurity is of any real value. Reviewing code will tell you if eigenvector_coefficient is really what it claims to be or something that morphed into something that the developer didn't originally intend.

Also keep in mind that code reviews approach code from a totally different angle than a developer would either developing or during a code walkthrough.

Post reply on HN