Live data from Hacker News

Security through obscurity is not bad

mobeigi.com

151–160 of 228 posts

Re: Security through obscurity is not bad

#151
post #149
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.

Well off-topic, but did you recently listen to Andy Stumpf on a podcast? Asking because of the Baader–Meinhof phenomenon :)

> Asking because of the Baader–Meinhof phenomenon :)

I recently learned about that and now I see it everywhere, weird.

Re: Security through obscurity is not bad

#152

Earlier quoted context omitted.

ASLR is (still[1]) not security by obscurity. [1] https://news.ycombinator.com/item?id=43408079

ASLR is, by definition, security by obscurity. The entire purpose of it is to make it so that it's hard to find the memory which is in use.

[deleted]

Re: Security through obscurity is not bad

#153
post #132
post #126

Earlier quoted context omitted.

Lucketone likely knows this and was pointing out that "obscurity" is a misleading word to use when talking about systems which all rely on obscurity, in the plain English sense of the word.

We're in a technical forum, discussing a term of art that refers to a very specific bad practice. Lucketone's argument is essentially saying that the bad practice itself isn't actually a bad practice by equivocating the term of art and the plain language definition.

The problem is that the term of art is confusing to technical people. See TFA. Technical people make logical leaps from "avoid security through obscurity [in the specific context of security systems which depend on obscurity and for which there are better alternatives than obscurity]" to "you should never obfuscate JavaScript" because the word is imprecise.

Re: Security through obscurity is not bad

#154
> For example, wp_users becomes wp_8df7b8_users. This is often dismissed as "worthless" because it is security through obscurity.

In some ways this is not security through obscurity. If you don't have a way to enumerate tables, this is in effect another short password being added to the data. In the same way you could say that the "obscurity" of users' passwords is security through obscurity... except we still use passwords.

The idea of security through obscurity being bad stemmed from the idea that a cryptosystem should still be secure when you know how it works. That's all.

In that way, you know how WordPress works, and yet you don't have access. You know how passwords work, and yet don't have access.

Obfuscating code is interesting because it sort of sits between the two. You could execute the code, and you may know how the obfuscation scheme works, but you can't de-obfuscate easily and see the original intent, and that way it's useful. The fact that you can still execute the code does however limit the impact.

Re: Security through obscurity is not bad

#155

> Security ONLY through obscurity is bad (Kerckhoffs's Principle). This is the crux of the article. (1) Kerckhoffs's Principle doesn’t say that. It says to design the system AS IF the adversary has all of the info about it except the secrets (encryption key, certificates, etc). (2) this rule is okay if you are a solo maintainer of a WordPress installation. It’s a problem if you work at a large company and part of the…

"Security through obscurity" can help in the reverse (for a time) — if they have your keys but haven’t found the locks. Might give you enough time to change the locks. But not provably — which can matter to a lot of people.

The example in the article is more likely. Changing the name of a DB table from the default helps because any low quality probe script will break as soon as this assumption of default errors. It means that low effort, low tech, low talent attacks will fail. This is not a bad thing because these are likely to be the most common kinds of attacks.

Again, I'm not opposed to simple tricks like this to “buy some time” so long as they don’t PREVENT the deeper layers of security from being performed. But if a company has scarce resources and a choice between patching unpatched software or changing DB names from the defaults the former actually improves security and the latter should only be performed if the staff has solved all of the higher risk items.

Re: Security through obscurity is not bad

#156
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.

Agreed with your sentiment, and that was a great example.

Just like any security control, if it's your only means of security, it will not offer much risk reduction. Just like all security controls, the if you want risk reduction use more security controls together. Like all security controls, there is no way to eliminate risk, just reduce it as much as possible while still being able to effectively achieve your mission.

Because of this I believe security through obscurity to be important component in a healthy and mature risk posture.

It irks me when it's dismissed because obscurity is not security. No single security control is security on its own.

Re: Security through obscurity is not bad

#157

Earlier quoted context omitted.

I'm having a hard time understanding what you mean here. If something is obscured, by definition it is less visible. Being 'less typical' is a form of security because most attacks rely on some form of pattern recognition, and obscurity literally dissolves patterns into noise.

You're overly focusing on the term and not the meaning. The term comes about from people choosing tools like "foxit" or "Opera" and saying that those products are safer than their cohorts Adobe/ Firefox because they are attacked less often. This notion was termed "security through obscurity" ie: "you use the less popular option, therefor that option is safer". It has nothing to do with "obscuring" in the sense of "hi…

> The term comes about from people choosing tools like "foxit" or "Opera" and saying that those products are safer than their cohorts Adobe/ Firefox because they are attacked less often.

That is not where the term comes from.

Re: Security through obscurity is not bad

#158

Earlier quoted context omitted.

You're overly focusing on the term and not the meaning. The term comes about from people choosing tools like "foxit" or "Opera" and saying that those products are safer than their cohorts Adobe/ Firefox because they are attacked less often. This notion was termed "security through obscurity" ie: "you use the less popular option, therefor that option is safer". It has nothing to do with "obscuring" in the sense of "hi…

> The term comes about from people choosing tools like "foxit" or "Opera" and saying that those products are safer than their cohorts Adobe/ Firefox because they are attacked less often. That is not where the term comes from.

In the infosec world, it pretty much is where the popular discourse has always been. It's just a bunch of nonsense terminology.

Re: Security through obscurity is not bad

#159
post #150

I don't think "obscurity" really buys you much (especially these days, with LLMs). However "Not Having Stuff to Steal" works like a charm. It's thousands of years old, and has never gone out of style. I know that it's considered blasphemy, hereabouts, but I've found that not collecting information that I don't absolutely need is pretty effective. Even if someone knocks down all my gates and fences, they'll find the f…

Totally agreed, to me data is just like code: extremely valuable for the functionality it provides, but in most other ways a serious liability. That said: > I don't think "obscurity" really buys you much (especially these days, with LLMs). Actually I think it does so even more with LLMs. As has been posited before (particularly on the threads about open source projects going closed source) security comes down to who…

Very good point.

Re: Security through obscurity is not bad

#160
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.

The problem with that statement is that a lot of people who yield it fail to see the advantages that come with these extra shenanigans ; and let's just take pure concealment so I don't pushing weird arguments ; in the age of AI - each time we are able make an attacking AI misaligned we are essentially buying time ; an on-going attack is never a on-shot event ; it's an ongoing process where the attacker has to understand where it is located and what it can do ; since each element will be a resource ; do not let it have it in the first place.

It's a bit of an elitist view of security that romanticize concepts without thinking about what they can actually be used for. My personal bad experience with that was a manager who was stating me that having a different subdomain for the admin panel was a concealment and not a security practice.

I mean - it's very easy to see how this kind of argument actually prevents from doing something that can help just on the basis of philosophical purity - which often just miss the point - security is not a mechanism that will solve all your problems ; heck in fact I have to layer at least 4 mechanisms just on the http interface to feel safe ; it's more of a lot of layers that together form a barrier ;

We sit too much on TLS thinking "That's it, security job is done" - then we get some crazy stuff like French ANTS that get pawned with some IDOR ; as IF f* using some hash or something ; ANYTHING PLEASE F* HELL ; would have not helped

Post reply on HN