4 ms·
Agreed. The maxim warning against "security from obscurity" is often reduced to an irrational comprehensive avoidance of obscurity. It's similar to the irrati
by bhauer 6y ago
Agreed. The maxim warning against "security from obscurity" is often reduced to an irrational comprehensive avoidance of obscurity. It's similar to the irrational avoidance of all performance optimization because Knuth warned of premature optimization.
Both reductions lose practical utility by omitting nuance.
* Avoid wasting your time doing performance optimization until tuning is necessary. But definitely take obvious and easy measures to ensure your software is fast, such as choosing a high-performance language or framework with which you can be productive.
* Don't exclusively rely on obscurity. But definitely take obvious and easy measures that leverage obscurity to add another layer of defense, such as changing default ports, port-knocking, or whatever.
To use the same art of reduction to counter the common interpretation: A complex password is, in a manner of thinking, security from obscurity. Your highly complex password is very obscure, hence it's better than a common (low obscurity) password from a dictionary.
- iso1631 6y ago> But definitely take obvious and easy measures that leverage obscurity to add another layer of defense, such as changing default ports, port-knocking, or whatever. Except that can lead to operational problems down the road. For example "oh yes, we're nice and secure, not only do you need a 512bit private key to get into this device, you also need to connect from a secure network" Then along comes covid, and you can't get into the building. "Oh dear, you're not on the secure network, you can't come in" So you spend 2 hours (while your network isn't working right and you're losing customers) finding and getting in through a back door.
- 0xFluegel 6y agoI would call that system secure. It does not just rely on an obscure password but is actually restricted by a list of whitelisted networks. The failure in that case is only that the admin didn't consider that normal work might be done from home at some point or that the middle or upper manager thinks that he should be able to freely administrate his critical infrastructure from anywhere...
- jjoonathan 6y agoIP whitelists break so often for "unanticipated reasons" that I've lost all sympathy for not anticipating it. Doubly so for using a whitelist to lock yourself out of the whitelist admin. It's so common the security community should make it a meme to spread awareness: Don't get pwned by DHCP while running from SSH 0-day RCEs.
- gowld 6y agoOf course security can lead to operational problems. Security is a trade-off against convenience.
- dane-pgp 6y ago> Of course security can lead to operational problems. So can lack of security.
- cat199 6y ago> Except that can lead to operational problems down the road. in the example you mention the 'security' is working by design, but the operational parameters changed which in turn made that security model unsuitable - so it is the parameter change, rather than the 'security' is what led to the problems. The original system could have been just as 'obscure' but also included an appropriately secured mechanism that allowed for this kind of remote access / disaster scenario.
- ziml77 6y agoThat isn't obscurity. And in your scenario, there was a security hole if the requirement was that you had to be on the intranet, but someone was able to gain access from the outside.
- deleted 6y ago[deleted]