alt Hacker NewsIf 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.
Replies
MattPalmer1086 • yesterday at 8:42 PM
A nice point!
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.