> This is actually the misunderstanding that the author is talking about I don't think so. It's like when someone confuses encoding and encryption because both

> This is actually the misunderstanding that the author is talking about I don't think so. It's like when someone confuses encoding and encryption because both "hide the plain text", they're just not the same thing no matter how you choose to view it. > People commonly misunderstand the concept and assume that obscurity is a bad practice in general, even when used as a secondary layer. It's not uncommon for junior engineers to object to any level of obfuscation or security because they can imagine a scenario where a sufficiently skilled attacker can defeat it, but that's missing the point. So how about teching these people instead of accomodating the misunderstanding and its unforseen consequences? I say this because the point of spreading "security by obscurity is bad" directly relates indeed to people, who use to think of security as a binary thing (it's either secure or not secure) with the consequent misconception that if there is something in place than it's secure. > Slowing down your adversaries and weeding out the low-effort attacks is still valuable. Definitely yes. But that is not security by obscurity. I always liked the safe analogy: it's good if you still need the key to open it even if you have its blueprints, a huge number of models both open and close with their own keys to play with and the time to take all of them apart. I think most people who dealt with math and cryptography get this more among security professionals and engineers. > That's exactly what the author says in the article. I don't see where the author is disagreeing with what you said. The part when he based the article ignoring the definition of the subject. If one reads his article with the definition in mind, then the whole article disagrees with this. I don't mean to be pedantic on definitions but I think there are good reasons for this one that are just being ignored.