[dspillett]

Obscurity is not security.

But it can add a bit of delay to someone breaking actual security, so maybe they'll hit the next target first as that is a touch easier. Though with the increasing automation of hole detection and exploitation, even that might stop being the case if it hasn't already.

The biggest problem with obscurity measures IMO is psychological: people tend to assume that the measures⁰ are far more effective than they actually are, so they might make less effort to verify that the proper security is done properly.

----

[0] like moving SSHd to a non-standard port¹

[1] a solution that can inconvenience your users more than attackers, and historically (in combination with exploiting a couple of bugs) actually made certain local non-root credential scanning attacks possible if you chose a high port

[titularcomment]

Obscurity can be combined with security for much better results. Machines as well as AI in extension thrives off patterns and making illogical off-pattern decisions is usually to the benefit of the defender, not the attacker. As you said, the attacker has a wide attack surface to cover while the defender only has to fortify his home NAT. E.g. port knocking may very well throw off the hoard of scanners on the wide net simply because its not standart and the combination is known only to you. Similarly, fail2ban may not work as well on a standart SSH port, because every attacker is going to hammer that and one may get your misconfigured password root login right.

Now, in both instances, the obscurity provided does not necessarily cure your infrastructure's vulnerabilities, a dedicated attacker wouldn't have a single problem with either of these. But for someone who hammers the whole internet in a dim hope of finding another Wordpress server from 2017, or the latest flawed online security cam, your disguise is as good as perfect.

[kbrkbr]

> Obscurity is not security.

So ASLR [1] is not a security control? I guess you are pretty alone with this opinion.

[1] https://en.wikipedia.org/wiki/Address_space_layout_randomiza...

[msm_]

No this is not what GP said, and I don't get how you reached this conclusion. This is like saying that AES is security through obscurity because it relies on key being secret. See [1] (linked in the OP) to understand the difference better.

I am pretty sure everyone who works in security agrees that obscurity is not security.

[1] https://en.wikipedia.org/wiki/Kerckhoffs%27s_principle

[minitech]

ASLR is (still[1]) not security by obscurity.

[1] https://news.ycombinator.com/item?id=43408079

[bigstrat2003]

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.

[imtringued]

The point of ASLR is that even if you fully understand how it works, this won't make it easier to bypass the protections of ASLR, since the primary way ASLR works is through dynamic adaptation. This turns it into a probabilistic security technique where there is always a chance that an attack goes through.

Security through obscurity in this case would be to roll your own ASLR implementation with a different randomization strategy.

[sixtiethutopia]

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.

[grayhatter]

no because it's still possible to find the data using standard techniques, it doesn't count as obsecurity it's still possible.

I.e. just because you* don't know where something is, doesn't mean it's using obsecurity to hide.

The reason is important, because words mean things: If you say, knowledge of some secret is security though obsecurity. That means passwords are security though obsecurity.

*: that may or may not be available to the attacker.

it other words, just because a secret exists, doesn't put that secret into the 'obsecurity' category.

[staticassertion]

No, because ASLR uses a secret.

[andix]

> But it can add a bit of delay

The delay can also be infinite in practice. If a really bad zero day is discovered, it might protect you from becoming a victim. No guarantees, but it can improve your chances.

[NewsaHackO]

The other thing though is that there are situations where you only have a limited amount of tries for a password, and incorrect tries can have dire consequences. If you are being asked for a password by an armed guard, and you hack the system completely and get the password, but didn't know about the last obscured step that you were supposed to type it with your left hand, not your right, you will still face whatever consequences even though that step didn't add any security.

[diarrhea]

As a fan and believer of obscurity in support of security, I do not understand why

> that step didn't add any security.

It is a decision that’s part of the entire process. A branch of many in the decision tree. Other branches are deciding which characters to type for the password; ASCII characters can be as little as 1 bit apart. Deciding between left and right is also 1 bit apart.

I think it boils down to what people commonly understand to be publicly knowable information versus understood-to-be-secret information.

One example: I self-host my password manager at pw.example.com/some-secret-path/. That extra path adds as much to security as a randomly picked username in HTTP Basic Auth: arguably none. Yet, it is as impossible for attackers to enumerate and find that path as it is with passwords.

The difference is that the path leaks easier. It’s not generally understood to be a secret. Yet I argue it helps security. (Example: leaking the domain name through certificate transparency logs AND even, say, user credentials means an attack is still unsuccessful; a strictly necessary piece of the puzzle is missing).