Kerchkoff would beg to disagree. Please do not refuse a beggar: https://en.wikipedia.org/wiki/Kerckhoffs%27s_principle
Security through obscurity is not bad
141–150 of 228 posts
Re: Security through obscurity is not bad
#142Earlier quoted context omitted.
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…
What you're describing is a thing that is not obscured. Don't refer to things as obscured if they are not obscured. When others talk about about things that are obscured they are talking about things that are obscured, not things that are not obscured.
You can see my other comment on this. The word "obscure" is not very relevant to the phrase "security through obscurity".
Re: Security through obscurity is not bad
#143Earlier quoted context omitted.
No, "Security through obscurity" is a valid and useful layer. A lot of weight hangs on your word “depends” though, in which case if it is the only layer then you will eventually have, uh, problems. I’ve used it for a long long time. Like in 1999 I’d have a knock on certain ports in a certain order to unlock the ssh port. And lots of weird stuff to stop forum spam. Which could work for weeks or months or even a year.
Port knocking isn't security through obscurity. Given the knowledge that you have a port knocking system in place doesn't tell me what specific sequence of knocks will open up the service I want to target. Even just a two knock sequence gives you a key with 32 bits of entropy, which makes it trivial to block attempts at bruteforcing the key.
I don't see how your argument makes sense. It's all just bits of entropy in the end, be it knowing a port to connect to or a character in your key.
Re: Security through obscurity is not bad
#144Security which has layers of obscurity can be incredibly powerful especially if you believe in counter intelligence. You want attackers to find the wrong key sometimes because it will lead to you collecting intelligence on them. But this increases the cost in time and infrastructure.
That isn't what the article is talking about. He is literally talking about running the JS code through an obfuscator and changing the default DB schema name. That isn't security and you know it.
Re: Security through obscurity is not bad
#145Earlier 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…
I understand it now, thanks
Re: Security through obscurity is not bad
#146Earlier quoted context omitted.
Port knocking isn't security through obscurity. Given the knowledge that you have a port knocking system in place doesn't tell me what specific sequence of knocks will open up the service I want to target. Even just a two knock sequence gives you a key with 32 bits of entropy, which makes it trivial to block attempts at bruteforcing the key.
I don't see how your argument makes sense. It's all just bits of entropy in the end, be it knowing a port to connect to or a character in your key.
Yeah absolutely. That was precisely my point — Requiring a secret (be it a password or the private part of an asymmetric key) isn't security through obscurity, and finding the sequence of knocks is equivalent to finding a password of equivalent complexity.
Re: Security through obscurity is not bad
#147It is bad!
The way how human brain works, anything that gives you the slightly sense of "security", will make you to leave as it is without implementing an actual solution.
That security by obscurity is now a security issue.
Re: Security through obscurity is not bad
#148Earlier 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.
That's not what security through obscurity means. Security through obscurity has a specific meaning, it doesn't just mean to gain security by hiding anything it means to attempt to gain security by hiding how a system works.
ASLR is a well understood system that exploit writers know to expect and thus ASLR is not security through obscurity.
Re: Security through obscurity is not bad
#149Obscurity 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 :)
Re: Security through obscurity is not bad
#150I 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 has paid more attention to the code, the attacker or the defender. And of course, these days attention is measured in tokens.
We know that LLM's are pretty capable of reversing-engineering to figure out an application's logic, but I would bet it takes many more tokens than reading the code or other public information directly. As such, obscurity adds an important layer to security: increasing the costs on the attacker.
Security has always been a numbers game, but now the numbers will overwhemingly be tokens and scale. If the defenders can cheaply raise the costs on the attackers by adding simple layers of obscurity, it can act as a significant deterrent at scale. I wonder if we'll even see new obfuscation techniques that are cheap to implement but targeted specifically at LLMs...