Security through Obscurity used to work, with AI it absolutely does not.
Security through obscurity is not bad
61–70 of 228 posts
Re: Security through obscurity is not bad
#62I could see AI massively changing the calculus here. Its ability to hack and reverse-engineer (even obfuscated) artifacts may leave obscurity (read: not sharing code or binaries at all) as the primary security mechanism in the industry.
Yeah everything is open source if you’re good at reversing. Models are increasingly capable of converting binaries into source, and excellent at implementing systems when there’s a finite and constrained end state to validate against, which is exactly the profile reversing falls into.
Re: Security through obscurity is not bad
#63I 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…
> It quiets down the logs nicely, people aren't always knocking on the door.
Q: If you've still done the right things - "disable[d] password auth, disable[d] root login, and only use ssh keys for access" - why do you care about how 'quiet' your logs are?
Re: Security through obscurity is not bad
#64I 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…
I would argue moving SSH to a non-standard port is security, but it's a different kind. By reducing the noise in logs, it reduces the workload on the human or agent reviewing the logs. So, you can detect an attack in progress or respond to an attack before it gets out of hand. With SSH on a standard port, the harmful malicious logs can blend in with the annoying malicious logs much better.
> By reducing the noise in logs, it reduces the workload on the human or agent reviewing the logs.
Q: Why would you "review the logs" by (human/agent) hand for a service exposed to the Internet? What are you actually looking for?
[I say this as someone who has tens of thousands of failed auth attempts against services I expose to the Internet. Per day.]
Re: Security through obscurity is not bad
#65Earlier quoted context omitted.
I'll push back on this: obscurity isn't a "free" layer of security, it has both security benefits and security costs. By having obscurity you lose anther layer of security: public scrutiny. It's harder for security issues to remain if people can see them and point them out, more eyes mean more chances to catch problems. There is also a cultural component: having to lay out what you are doing publicly means you can't…
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 negative than I intended.
Re: Security through obscurity is not bad
#66Earlier 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…
I think you're overthinking this. You're probably imagining some context to this that I'm not understanding fully.
Re: Security through obscurity is not bad
#67Obscurity 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.
Re: Security through obscurity is not bad
#68> 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…
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.
Re: Security through obscurity is not bad
#69Obscurity should always be part of security
Re: Security through obscurity is not bad
#70Mo Beigi unfortunately misses the point.
Yes, echo chambers are annoying - I remember this when I challenged them by explaining to me why being superuser is problematic (hint: I countered their arguments easily, then they got very angry about this; I did this on several IRC channels back in the day, just to prove a point. I managed to get banned on one too in the process.)
But ... obscurity is NOT a security technique. It just has a catchy slogan.
The primary reason why javascript is sometimes - or often - obfuscated is to make it harder to copy/paste and re-use stuff. That's it. Even with sanitizers, de-obfuscating it tends to increase the amount of time one has to spend to uncripple the code. This is the primary function; anything else is just decoy for the most part here.
> Security through obscurity is the practice of reducing exposure by keeping an application's inner workings or implementation details less visible to attackers
Very clearly his attempt to explain it, is already biased. Is obfuscating JavaScript security through obscurity? I mean if we can not agree to the terms, we can't agree or disagree on anything that follows.
Showing fancy images does not add any real argument to the discussion.
> For example, wp_users becomes wp_8df7b8_users. This is often dismissed as "worthless" because it is security through obscurity.
Note that this example does not even follow his own (!!!) definition.
This has nothing to do with obscurity. It simply is another name than the default login name. What would he expect of people to do? Retain the name? And if they change it, are ALL changes in his opinion valid to "security through obscurity"? He picked wp_8df7b8_users here. Is the name "foobar" instead a better name? Or is it "not obscure enough"?