Live data from Hacker News

Security through obscurity is not bad

mobeigi.com

91–100 of 228 posts

Re: Security through obscurity is not bad

#91

Earlier quoted context omitted.

Kerkhoff's principle is not about security in general, it is about the design of cryptography. Assume your opponent knows everything about how your crypto system works. Your security then lies in the keys and not knowledge of the method. More broadly, anything that raises the cost of an attack helps security. Whether it is worth investing your defensive effort in that vs on more actual security is a different matter.

If it does not obscure your own view of the security or reasoning about the security stance. For instance, with respect to url parameters, I have seen people being told they have an Insecure Direct Object Reference, then apply base64 encoding to it to obscure what is going on. To QA they don't notice it looks like junk, it is obscure, but base64 encoded parameters are catnip to hackers. So in this case, the obscurity…

A nice point!

Re: Security through obscurity is not bad

#93
post #65

Earlier quoted context omitted.

You're pushing back on something YOU said, not me. I never called it a "free" layer of security, I said it was ONE layer of security. Emphasizing the one, because security comes in as many layers as one is able to manage.

Well, my issue is that "one layer" implies you can just stack it on others, especially if you say "as many layers as one is able to manage", it implies the best option is to add obscurity on top. As my comment made the case: it's not a simple addition, it's a trade-off, and I'm saying it should be thought about in those terms. I didn't find that was evident from what you said, I guess the "push back" framing was more…

Which of your security layers isn't a trade-off?

Re: Security through obscurity is not bad

#94

Earlier quoted context omitted.

I don't think that really works because obscurity isn't harder to see or find. I don't know the analogy, it's like standing out in the open and being like "yeah but who would think to look here lol".

I think you're misinterpreting "obscurity" for "lack of obscurity". If you have a vulnerability in an API interface that is completely undocumented that is a vulnerability that is obscured. It's hiding in the woods, not standing in a field. To keep with the analogy: no one is going to stand in a field when people are shooting at you. So then why do a small subset of vocal people online suggest that you just put your…

This isn't about what's a good idea or bad idea. Perhaps it's best to simply leave analogies behind, otherwise we'll just focus on the wrong thing.

Security through obscurity merely means that your system is atypical. It's not hidden, it's not secret, it's not hard to find, it's not hard to examine, it's not less visible, etc - there is nothing inherently different about the systems at all other than that one is more common than the other. It's just less typical.

Re: Security through obscurity is not bad

#95
post #31

Wordpress is a great example. He cites > There is a long-standing security recommendation to change WordPress's default database table prefix to a random one. For example, wp_users becomes wp_8df7b8_users. This is often dismissed as "worthless" because it is security through obscurity. I found that just changing the default URL for the wordpress login from the usual wp-admin to anything reduces by several orders of m…

Security through obscurity isn't security. It could be a method to reduce noise, but by doing so, you also have less eyes to watch over. If you'd pay for a blackbox pentest, and the pentester doesn't find your OpenSSH server running on a different port, then that doesn't tell you anything about the security of your OpenSSH server. In a whitebox pentest, they'd know about it beforehand. So, do you want to test the sec…

> Security through obscurity isn't security. It could be a method to reduce noise, but by doing so, you also have less eyes to watch over. If you'd pay for a blackbox pentest, and the pentester doesn't find your OpenSSH server running on a different port, then that doesn't tell you anything about the security of your OpenSSH server. In a whitebox pentest, they'd know about it beforehand. So, do you want to test the security of your OpenSSH server, yes or no?

If your pentester can't find your sshd on a different port: 1) that is prima facie evidence that it works for a similar (low) skill level of attacker, and 2) you should fire that pentester. I'll leave the reasoning as an exercise for the reader.

> I don't allow traffic from any IPs allocated to China or Russia, among a couple of other countries, and I don't feel like I am missing out.

Now yer talkin'! As a blanket policy, if you have no valid users outside of your own nation and no expectation that will change, why not block everybody who isn't local?

(Of course, that just means any Russians and Chinese who do manage to attack you may be actual spooks, so if that happens you're pwned anyway. ;-) But you'll have cut down on your security logs considerably.)

> Another one is port knocking. Anyone who has read access over the network between client and server can figure out the port knocking process, including a hostile actor who does a MITM (with for example a rogue WiFi AP).

While I appreciate the fact that you're thinking outside of the typical box with regard to threat modelling, such an MITM attack is quite a few orders of magnitude more intentional of an attack than the rest of the crap the average systems/security admin has to deal with. In the case of a non-targeted (ie. not against a specific user or org) you're looking at a malicious network operator, which is far more sophisticated than 99.x% of the bulk scanning and attacks most admins see. In the case of a targeted attack we're talking about funded and probably successful organized crime at the very least, and possibly even nation-state intel orgs. Only motivated, professional attackers tend to get off their butts and travel to a different location to conduct an operation like that.

Kudos for recognizing such a problem, but using that as an excuse not to employ a powerful security technology such as port knocking is rather throwing the baby out with the bathwater. If you're going to be that defeatist, just airgap the system and be done.

Now, if you are willing to go through the effort of whitelisting IPs (which, I suspect, you haven't done yet, or you'd already loathe doing it and not recommend it), the sane way of going about that is to set up a VPN and whitelist the IP of the gateway. Otherwise you've opened up an administrative can of worms that is bad indeed. Nobody wants to have to keep track of Joe Blow's home IP address, which changes weekly at least, for some whitelist.

Re: Security through obscurity is not bad

#96

Couldn't one argue that a password is also obscurity? It's only secure until someone figures it out, just like a secret URL on a website.

Secret storage isn't considered "security through obscurity". Everyone knows that when you find the key to the door, you've won. Security through obscurity is more like hiding the keyhole: it isn't going to stop anyone determined, but it can be effective against someone who isn't all that motivated (well, all that motivated to target you , anyway).

Which is a poor choice of words by the industry, as this is a semantically specious argument. You are still, in the strictest sense, relying on obscurity - the key being obscure from public knowledge.

The industry should instead say: relying on an obscure process is bad when it comes to security. Better to rely on obscured data. As this is what is meant.

But technically speaking, all of information security is done through obscurity. It is all done via hiding something from being known. To state otherwise, is a misuse of semantics.

Re: Security through obscurity is not bad

#97
obscurity is a form of concealment, but not cover.

concealment will make specific targeting -less than straightforward,but a scorched earth obliteration will get you along with all else.

cover, is a condition that is resistant to attack when you are visible.

you should have both, resistance to sequential action when you are specificly targeted, a obfusification of presence, minimizing the frequency of targeting.

Re: Security through obscurity is not bad

#98
post #67

Obscurity can be fine but it's not security. I think of it like cover and concealment in the military. Security is cover. Something you can get behind so the bullets don't hit you. Obscurity is concealment. Harder to see, harder to find, so the enemy doesn't know where to shoot, but it's not stopping any bullets. Both have advantages and disadvantages and can complement each other depending on how they're used.

All modes of cyber security depend on some obscurity (e.g. password)

Ideally we want a viable plan B, for when it’s leaked/figured out. (E.g. generate new passwords)

(For convenience let’s label air-gap as kind of physical security)

Re: Security through obscurity is not bad

#99

I get what this post is saying, but I'm going to push back that "security through obscurity" isn't just something that people parrot without understanding. Obscurity provides, effectively, no security. There may be other benefits to the obscurity, but considering the obscurity a layer of your security is bad . I hope we all agree that moving telnet to another port provides no security (it's easily sniffable, easily f…

If port numbers were 64bit or 128bit, actually it would provide a meaningful amount of security through obscurity. Port numbers are easy to dunk on because it’s such a trivially small search space.

But at this point, that's like saying my password is merely 'obscure.'

Re: Security through obscurity is not bad

#100
post #67

Obscurity can be fine but it's not security. I think of it like cover and concealment in the military. Security is cover. Something you can get behind so the bullets don't hit you. Obscurity is concealment. Harder to see, harder to find, so the enemy doesn't know where to shoot, but it's not stopping any bullets. Both have advantages and disadvantages and can complement each other depending on how they're used.

All modes of cyber security depend on some obscurity (e.g. password) Ideally we want a viable plan B, for when it’s leaked/figured out. (E.g. generate new passwords) (For convenience let’s label air-gap as kind of physical security)

i don't know a lot about the subject, but the little i know tells me this is not the way to look at this

your password (plain text) is secret because only you are supposed to a have it. in the digital realm, sharing the contents of the password (plain-text) is be akin to making a copy of it — undesirable

now, the algorithm that hashes the plain-text for comparison with the stored hash, that can be know by anyone, and typically is

so password ≠ hashing algorithm

Post reply on HN