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

111–120 of 530 posts

Re: Security by obscurity is underrated

#111

Post by Verdex »

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…

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

Most of the usages of "security through obscurity" that I've seen dissected and decried haven't been in the sense that something was being hidden, but rather that something was being confused. For example, using base 64 encoding instead of encrypting something. Or running a code obfuscator on source code instead of making the code actually secure.

Either way the economic costs that I'm talking about are valid. If an attacker sees that your SSH port isn't where it's supposed to be OR if an attacker sees that your SSH port ignores all packets sent to it (unless you first send a packet thats 25 0xFF bytes), then either way they're being signaled that you are more trouble than the computer that has an open telnet port.

There are slightly different usages of the same word, but the effect looks to me to be the same. More investigation or automation can make the obscurity go away, but it does make things a bit harder.

Re: Security by obscurity is underrated

#112

Post by czzr »

thaumasiotes wrote: post #86
jerf wrote: 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…

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

(All real examples)

Re: Security by obscurity is underrated

#113

Post by saagarjha »

Verdex wrote: post #65
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…

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…

Using obfuscation is often a signal that you are a weak target, because there are a lot of places that use obfuscation but nothing else. A better indicator that you are a hard target is to enable common mitigations like NX, stack cookies, or ASLR.

Re: Security by obscurity is underrated

#114

Post by weare138 »

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…

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 and the randomized variable were just a nuisance. Honestly his best obfuscation technique was his horrible code that made no sense.

Even OP's advice about running services on non-standard ports isn't sound. Who doesn't run a service scan? Even sites like Shodan do service discovery for you. I'm going to find whatever port your running ssh on if your running it.

Re: Security by obscurity is underrated

#115

Post by outworlder »

jonfw wrote: post #60
dec0dedab0de wrote: post #7

I'm surprised port knocking never really caught on. Does anyone know of it being used in production anywhere?

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.

Re: Security by obscurity is underrated

#116

Post by Spivak »

floe wrote: post #95
Spivak wrote: post #83

Earlier quoted context omitted.

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…

They're verifiably hard to guess. That is fundamentally different. (At least when passwords are generated with enough entropy.)

But does that make them different or are they just things that are easy to verify? If you could calculate the entropy of another authentication scheme would it be included?

The danger of security by obscurity is that your system might not have as much entropy as you initially estimate and can be easily defeated. Sounds a lot like the vulnerabilities in normal crypo applications, right?

Re: Security by obscurity is underrated

#118

Post by saagarjha »

aeternum wrote: post #108
umvi wrote: post #72

Earlier quoted context omitted.

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

It might make sense in some contexts, but code obfuscation is a great example of where software engineers think it provides security where it provides none. Developers often have some idealized notion that an attacker is going to need to piece their program logic back together and try to decode the purpose of each obfuscated variable in order to find a hardcoded password/value. In reality an attacker is just going to…

Exactly. If you're running crypto and think getting rid of variable names is going to stop people; it's not. Any off-the-shelf algorithm is usually easy to recognize to an accomplished reverse engineer with a basic background of what kind of things they're looking for.

Re: Security by obscurity is underrated

#119

Post by lynndotpy »

Naac wrote: post #105

Agree with most people here that security by obscurity is bad "by itself". For example, changing your public server ssh port from 22, to say, 2942, is a great way to limit the amount of bot autoattempts from trying to log into your server. Having a password-less ssh port 2942 open is clearly bad, but not when combined with all the standard good practice ssh security.

My understanding is that it's important to keep SSH (and other services) on a privileged port. (I think the default is <1024.) Otherwise, unprivileged malware that could cause the SSH server to crash and take over the (unprivileged) port. No idea if this actually happens in practice though.

Re: Security by obscurity is underrated

#120

Post by bleepblorp »

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…

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 trivial for anyone who knows the port sequence to defeat, but it's also very effective as anyone who doesn't know the port sequence has no indication of how to start probing for a solution.

Post reply on HN