Live data from Hacker News

Security by obscurity is underrated

utkusen.com

91–100 of 530 posts

Re: Security by obscurity is underrated

#91
post #43

This came up in the stackoverflow podcast where Reddit founders were the guest. They mentioned that they stored plain text passwords initially which is fundamentally a bad design but at the same time it helps to block spam. If a user starts to create a lot of accounts programmatically they generally use the same password thus much easier to filter. Security via Obscurity, if you can do it, can be very very effective.

You could do that without a plain-text password, though with a salt it would be harder (though you could still do it proactively by checking the password when the account is made).

To check the new account's password at creation time against existing salted hashes, you'd have to hash the new password with each existing password's salt. If you are using something like bcrypt or scrypt which is designed to be slow at this, that might take a while if you have a lot of existing accounts.

Maybe a Bloom filter approach? Besides the salted slow hash you store of each password, also put the password in a Bloom filter. Check new passwords against the Bloom filter. You'll get some false positives that way, but maybe that is acceptable.

I'm seriously tempted, if I ever have to implement a password system again, to allow up to 256 characters, just store an unsalted SHA256 hash, and tell people on signup that they should be using a password manager with a long random password if they care about security of their account.

Re: Security by obscurity is underrated

#92
The article is correct but they miss the true value add of security through obscurity: signaling lower ROI to attackers. Security through obscurity generally forces attackers to perform more actions and do more recon. Every additional action taken increases the risk of detection by defenders, costs the attackers valuable time (meaning lower ROI), and makes the target less appealing relative to other targets. Security through obscurity tactics are absolutely useful tools in a defender's toolbox (in conjunction with other security countermeasures).

Re: Security by obscurity is underrated

#93
My beard is not grey enough to know about how the Security by Obscurity meme/mantra have evolved in the tech community.

But one thought I have is that this more nuanced picture is much more complicated to tell beginners. Beginners / not as security conscious developers often, wrongly, assume that obfuscation is much more powerful than it is.

The safest digest of the "Apply ≈Kerckhoff's principle, but some obscurity on top of that is not a bad idea if it's cheap to implment", is probably "security by obscurity is bad!1!".

Certificate pinning or sandboxing in mobile apps won't stop people from reverse engineering your API's. But if your personal belief is that it's like almost a state actor level attack to see your API routes or modify requests, it will undoubtedly influence how you implement them.

I've seen some serious problems where companies do really bad things (like sending the ID of the currently logged in user and not checking it server side, allowing for execution as arbitrary user), which I guess at least partly arose from thinking along the lines of "It's only our signed code that will ever make these requests". Even bad developers wouldn't make the same misstakes in ≈2020 on the web, where the understanding that the client is untrustworthy have fully statured the common understanding.

Re: Security by obscurity is underrated

#94
To me all these slogans around security is to ensure people really, truly, actually think about things before they go against the grain. Is using obscurity as part of your defence always wrong? No, but equally it often adds a false sense of security. Popularising these easy to remember slogans helps change peoples defaults. Nowadays, if someone sees an attempt at security by obscurity it (hopefully) rings alarm bells and causes them to interrogate it to ensure that there is also other security measures in place, or that it is otherwise OK. It's the same with "never roll your own crypto"

I find it somewhat interesting that the article uses an example which falls right into another pitfall that "security vs obscurity" is trying to prevent.

> SSH runs in port 64323 and my credentials are utku:123456. What is the likelihood of being compromised? > > Now we changed the default port number. Does it help? Firstly, we’ve eliminated the global brute forcers again since they scan only the common ports. ... So, if you switch your port from 22 to 64323, you will eliminate some of them. You will reduce the likelihood and risk.

This is technically correct. However, the author has identified a security concern that he wants to mitigate: brute force attacks. Now, you could try and reduce that risk by using a different port which might reduce it by 50%, or* you could fix this issue by deploying fail2ban (or using ssh keys, or VPNs and bastion boxes, etc), and thus negating that attack vector entirely. There isn't even a usability argument here: making people remember the right port for ssh is less usable than setting up fail2ban. Of course there are tonnes of other attack vectors to consider, but in general where possible its better to "properly" (fsvo.) mitigate those concerns and only rely on obscurity where that isn't possible. If a concern is mitigated than adding obscurity does almost nothing, while likely proving to be more annoying to the end user (like in the case of specifying a port in the above example).

Now of course that's not to say that you should never use obscurity, but if you do then I think its entirely reasonable that you are prepared to give a good justification why its appropriate. For example, sharing via secret URLs is a good example where it can be easy to justify in some settings, but it equally may not be OK for documents that are really really sensitive as its relatively easy for links to be shared in error with the wrong people.

RE some comments about using obscurity to signal that your deployments would be harder to get into and thus for attackers to not bother: I'd genuinely love to know if that is true or not, I wouldn't be surprised if attackers assumed obfuscation mean that the more advance security measures hadn't been deployed (otherwise why bother with obfuscation?).

* Based on the twitter poll in TFA, though if you have a targeted attack it seems sensible to assume that if port 22 doesn't work they'd try again with other methods

Re: Security by obscurity is underrated

#95
post #83

Earlier quoted context omitted.

> But then we all implement passwords (which is just security by obscurity) No it isn't. Security by obscurity is explicitly keeping things other than passwords and keys secret.

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

Re: Security by obscurity is underrated

#96

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…

Maybe the test should be: "is my system considered to be secure even without any obscurity?" If the answer is yes, then add obscurity.

For instance, the port 22 example. Suppose you have a bastion host. SSHD running on port 22, root password disabled, passwords disabled (only SSH keys), no other services running, all other ports filtered/closed. It should be fairly secure, even if exposed to the internet, right?

Now you can change the port. Change the SSH banner and hide the version. Add some port knocking. And so on. None of these measures would work by itself, but they will discourage non-targeted attackers.

Re: Security by obscurity is underrated

#97
post #27

There's something to the idea of rehabilitating "obscurity", or at least recognizing that "cost" is part of threat models, and you can raise costs for particular attack vectors by degrees instead of "to infinity". But SSH is a terrible example, because the cost to the defender of simply not having SSH vulnerabilities is the same, or even less, than the cost of obfuscating it with nonstandard ports, "port knocking", o…

> There's something to the idea of rehabilitating "obscurity", or at least recognizing that "cost" is part of threat models, and you can raise costs for particular attack vectors by degrees instead of "to infinity".

Exactly! Especially when you can create a high cost asymmetry, low-cost for you to add, high cost for the attacker to bypass.

Agree that the SSH examples aren't the best. I would have picked DRM.

Re: Security by obscurity is underrated

#98
Changing SSH port is far more efficacious at reducing nonsense than the Twitter poll in the article suggests:

> "I ran an experiment with a virtual machine exposed to the internet which had sshd listening on port 22. The server stayed online for one week and then I changed the ssh port to 222. The number of attacks dropped by 98%. Even though this is solely empirical evidence, it’s clear that moving off the standard ssh port reduces your server’s profile."[0]

> "In the time that I gathered 7,025 connection attempts to my SSH daemon on port 22 I received 3 on port 24."[1]

Also, great top comment by 16s[2] in this HN thread, "Why putting SSH on another port than 22 is bad idea".[3]

[0] https://major.io/2013/05/14/changing-your-ssh-servers-port-f...

[1] https://danielmiessler.com/blog/security-and-obscurity-does-...

[2] https://news.ycombinator.com/item?id=6615994

[3] https://news.ycombinator.com/item?id=6615734

Re: Security by obscurity is underrated

#99
post #27

There's something to the idea of rehabilitating "obscurity", or at least recognizing that "cost" is part of threat models, and you can raise costs for particular attack vectors by degrees instead of "to infinity". But SSH is a terrible example, because the cost to the defender of simply not having SSH vulnerabilities is the same, or even less, than the cost of obfuscating it with nonstandard ports, "port knocking", o…

Though it would be a tragicomic shame if you got caught by a nasty 0-day while the clown up at port 34015 narrowly escaped and earned enough time to patch before pre-mapped host scans begun.

Re: Security by obscurity is underrated

#100

Earlier quoted context omitted.

This is the whole "shadow IT" that actually results in a lot of security breaches. Look at the recent twitter hack for a great example. Staff were storing login credentials in a slack pinned message because using the right tools were a headache.

One thing I despise is internal systems with self signed certs because setting it up properly is a faff or no one can agree on the latest and greatest way to do it. Oh cool that’s fine I’ll just click away all the big scary warnings in my browser to access this page. I’m an engineer and know what I’m doing! It’s a super strong key anyway. Oh wait I’ll just send this link to Bob in accounting and tell him to do the ve…

I have tried (unsuccessfully) to argue this point at a previous employer.

Email server certificate expired and IT sent messages teaching people to ignore cert validation errors.

Post reply on HN