[thephyber]

> 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 company knows the full intent of this, while the rest of the company doesn’t know the other layers of security BECAUSE of the obscurity layer. In this way, it’s important to communicate that this is only a layer and shouldn’t replace any other security decisions.

[MattPalmer1086]

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.

[rileymat2]

If it does not obscure your own view of the security or reasoning about the security stance.

For instance, with respect to url parameters, I have seen people being told they have an Insecure Direct Object Reference, then apply base64 encoding to it to obscure what is going on. To QA they don't notice it looks like junk, it is obscure, but base64 encoded parameters are catnip to hackers.

So in this case, the obscurity made the system worse over time.

Heck, the most cringeworthy phrase "Base64 Encryption" which I have heard many many times.

[TZubiri]

I love this nuance!

But I think it's covered by your immediate parent comment

> Whether it is worth investing your defensive effort in that vs on more actual security is a different matter.

So the base64 introduces a marginal security gain, but in addition to expending effort in implementation, it increases the cost of other efforts (which is the case for almost all features), in the case of a fixed cost QA (which is again, always the case), the quality of the QA (pardon the redundancy) will be the parameter that suffers.

So yes, if the security gain is very minimal, then it's likely that the cost of the feature will be so great comparatively, that it will not only affect all other parameters like ease of use, but the negative indirect impact on security will be greater than the marginal positive direct impact on security.

Many such cases.

[MattPalmer1086]

A nice point!

[catlifeonmars]

I agree, that anything that raises the cost of an attack may be worth doing. Most “obscurity” related practices do not meaningfully raise the cost of an attack beyond a certain threshold. Physical locks are not a great analogy.

[sroussey]

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

[thephyber]

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.