16 ms·

Agree with the article. People have been misinterpreting "security by obscurity is bad" to mean any obscurity and obfuscation is bad. Instead it was originally

Agree with the article. People have been misinterpreting "security by obscurity is bad" to mean any obscurity and obfuscation is bad. Instead it was originally meant as "if your only security is obscurity, it's bad". Many serious real-world scenarios do use obscurity as an additional layer. If only because sometimes, you know that a dedicated attacker will be able to breach, what you are looking for is to delay them as much as possible, and make a successful attack take enough time that it's not relevant anymore when it's broken.

KarlKode 6y ago
An argument against obscurity is that it adds additional pains for your "regular" users (as in developers/3rd party developers/app developers) while being a small deterrent against unauthorised users (as they will be able to circumvent the "obscurity layer" and replicate their method to other bad actors). edit: In the first sentence "against" is not what I wanted to say: what I wanted to say is that it "downgrades it's effectiveness". I agree that obscurity can and sometimes should be a layer of security.
- PragmaticPulp 6y ago
  > An argument against obscurity is that it adds additional pains for your "regular" users (as in developers/3rd party developers/app developers) No one should be applying obscurity to public-facing APIs or anything for which documentation is widely distributed outside the company. A better example would be Snapchat's intense and always evolving obfuscation strategies: https://hot3eed.github.io/snap_part1_obfuscations.html https://hot3eed.github.io/snap_part1_obfuscations.html Even though someone took the challenge to de-obfuscate most (but not all) of the protections, just look at how much effort is required for anyone else to even follow that work. More importantly, consider how much effort is required relative to other platforms. It's enough of a pain that spammers and abusers are likely to choose other platforms to attack.
  - gowld 6y ago
    When security is totally impossible because there is no way to distinguish a trusted party from an adversary, obscurity is the only hope.
    - austincheney 6y ago
      If you cannot distinguish a trusted party from a malicious party everything is then potentially malicious. This is why we have certificates, certificate revocation, and trust authorities.
      - blackflame7000 6y ago
        And that works great until a trust authority gets compromised. It's for this reason why the US DoD has it's own root certificate authorities and thus many military websites actually look like they have invalid https certs. Browsers don't ship with DoD root certs installed as trusted.
        austincheney 6y ago
        Yeah, I am on a DODIN as I write this. In the civilian world a CA falls back on a decentralized scheme called Web of Trust which allows CAs to recipricate certs from other CAs and invalidate other CAs as necessary. The DOD chose to create their own CA scheme originally for financial reasons in that over a long enough time line new infrastructure pays for itself with expanded capabilities while minimizing operation costs dependent upon an outside service provider. This was before CACs were in use. https://en.wikipedia.org/wiki/Web_of_trust https://en.wikipedia.org/wiki/Web_of_trust
        blackflame7000 6y ago
        Thanks for the additional info, I didnt know (but probably should have assumed) that finance was the primary motivator. I just had to implement CAC authentication for a webapp and they still use their own CAs for client-side certs aka cac’s so it seems like it was a pretty savy investment at the time that’s not going away anytime soon
tetha 6y ago
Internally, we phrase it as "Make the system objectively hard, then don't tell all the details". Wasting an attackers time is a fine goal.
- draugadrotten 6y ago
  > Wasting an attackers time is a fine goal. reply This. Putting a tarpit on port 22 isn't going to stop an attacker, but it will slow the ssh scans down for everyone. https://github.com/skeeto/endlessh https://github.com/skeeto/endlessh
  - PowerBar 6y ago
    Honeypots are fun, but be VERY careful how you deploy them. Ideally they are on a completely separate network on the WAN side of a second firewall. The last thing you want is for someone to find an exploit in your honeypot and use that to gain access to your network.
- cogman10 6y ago
  It's a lot like bike locks. Yes, most people can grab some bolt cutters, snip, and bike off. Yet, so many bikes remain unstolen with extremely week locks. The vast majority of attacks are crimes of opportunity. Hackers aren't generally trying to target a single company or computer for a bot net, they are looking to get as many as possible. Almost any amount of effort above and beyond the typical will cause them to jump past you as a target. Back to the bike lock analogy. Again, most locks can be bypassed, getting one that requires an edge grinder will almost certainly ensure that your bike won't be stolen (Why steal that bike when there are 20 with simple wire locks?). Add 2 locks and you've got a bike that will almost never be knicked. https://www.youtube.com/watch?v=oPDHPpnXPv8 https://www.youtube.com/watch?v=oPDHPpnXPv8 This video can teach you a LOT about software security.
weare138 6y ago
But the examples given won't help and is just bad advice in general. - Assume for every code obfuscator there's a deobfuscator or at least someone as clever as you out there. - Randomizing variable names it just a nuisance, it won't stop any competent pen tester or attacker. - Encrypting the database is an odd one. Your program will also have to decrypt the data to use it. Where do you store the encryption keys? In your code? Don't assume obfuscating your code and/or randomizing variables will protect your encryption keys.
- jerf 6y ago
  You seem to be thinking in terms of security mechanisms either perfectly blocking attacks or being useless. That's the wrong model. It's about costs. Obfuscating otherwise-open code doesn't mean that nobody can ever figure out what it does, but it raises their costs. Randomizing variables raises costs. Encrypting the DB raises costs on an amortized basis (some cracks may get the key and then it may not raise the cost much, but other cracks may only get the data in which case cost is raised a lot). Things are "secure" not when it's impossible for any actor in the world you don't want to get access to get access, but when the costs to those actors exceed the loss you may experience. (Preferably by a solid margin, for various reasons.) As to whether this is good or bad advice, that depends on how expensive these things are (e.g., encrypting database fields may be very expensive if you write raw SQL calls as your primary DB interface but may be dirt cheap if you're using an ORM that has it as a built-in feature) and your local threat model (e.g., "dedicated, personalized attackers reading your source" is very different from "does it defeat automated scanners?"). You can't know whether these are good or bad ideas without that additional context.
  - thaumasiotes 6y ago
    > You seem to be thinking in terms of security mechanisms either perfectly blocking attacks or being useless. That's the wrong model. It's about costs. This is something that bothered me quite a bit in Bruce Schneier's various comments on airline security. He repeatedly wrote that profiling young Arab men as likely terrorists was pointless, because if it became harder for young Arab men to get through security, terrorist organizations would simply start sending Japanese grandmothers. But of course where it's relatively easy to find young men willing to die for a cause, it's much more difficult to find grandmothers who will do the same. And where it's relatively easy for an Islamic group based in the Middle East to connect to Arabic social networks, it's much harder for that group to connect to Japanese networks.
Verdex 6y ago
In nature, prey animals will sometimes jump when they spot a predator[1]. One of the explanations is that this is the animal communicating to the predator that it is a healthy prey animal that would be hard to catch and therefore the predator should choose to chase someone else. I think we can kind of view obscurity in the same way. It's a way to signal to a predator that we're a hard target and that they should give up. Of course in the age of automation, relying on obscurity alone is foolish because once someone has automated an attack that defeats the obscurity, then it is little or no effort for an attacker to bypass it. Of course, sprinkling a little bit of obscurity on top of a good security solution might provide an incentive for attackers to go someplace else. And I can't help but think of the guy who was trying to think of ways to perform psychological attacks against reverse engineerers [2]. [1] - https://en.wikipedia.org/wiki/Stotting https://en.wikipedia.org/wiki/Stotting [2] - https://www.youtube.com/watch?v=HlUe0TUHOIc https://www.youtube.com/watch?v=HlUe0TUHOIc
- acoard 6y ago
  >I think we can kind of view obscurity in the same way. It's a way to signal to a predator that we're a hard target and that they should give up. This has it completely backwards. Security through obscurity's goal is not to signal predators, it's the opposite. The goal is to obscure, to hide. The "signal" is there is nothing here (or nothing here worth your time). One of the best examples (it's in the article!) is changing the default SSH port. Just by obscuring your port you can usually filter out the majority of break-in attempts. The only way security through obscurity signals to "predators" is if they've seen past your defence, and thus defeated the obscurity. Obscurity (once revealed) is not a deterrent. Likewise an authentication method (once exploited) is not a deterrent. >Of course in the age of automation, relying on obscurity alone is foolish because once someone has automated an attack that defeats the obscurity, then it is little or no effort for an attacker to bypass it. This is true of any exploit basically. Look no further than metasploit. Another example: a worm is a self-automating exploit.
  - Verdex 6y ago
    > This has it completely backwards. Security through obscurity's goal is not to signal predators, it's the opposite. The goal is to obscure, to hide. The "signal" is there is nothing here (or nothing here worth your time). Most of the usages of "security through obscurity" that I've seen dissected and decried haven't been in the sense that something was being hidden, but rather that something was being confused. For example, using base 64 encoding instead of encrypting something. Or running a code obfuscator on source code instead of making the code actually secure. Either way the economic costs that I'm talking about are valid. If an attacker sees that your SSH port isn't where it's supposed to be OR if an attacker sees that your SSH port ignores all packets sent to it (unless you first send a packet thats 25 0xFF bytes), then either way they're being signaled that you are more trouble than the computer that has an open telnet port. There are slightly different usages of the same word, but the effect looks to me to be the same. More investigation or automation can make the obscurity go away, but it does make things a bit harder.
aeternum 6y ago
It's fine as an additional layer only when the primary layers do not rely on obscurity. I've seen too many instances where obscurity is used to justify weak primary layers (IE it's fine we're using this single word shared password since we have all these other layers). It can often provide a false sense of security since it looks like a security layer when in reality it often turns out to simply be a minor inconvenience to an experienced attacker.
outworlder 6y ago
Maybe the test should be: "is my system considered to be secure even without any obscurity?" If the answer is yes, then add obscurity. For instance, the port 22 example. Suppose you have a bastion host. SSHD running on port 22, root password disabled, passwords disabled (only SSH keys), no other services running, all other ports filtered/closed. It should be fairly secure, even if exposed to the internet, right? Now you can change the port. Change the SSH banner and hide the version. Add some port knocking. And so on. None of these measures would work by itself, but they will discourage non-targeted attackers.
- jopsen 6y ago
  They are also non-trivial amounts of work, both to build and to maintain.. Someday, someone will have problems connecting and waste half a day debugging it before they realize what is up.
reaperducer 6y ago
Many serious real-world scenarios do use obscurity as an additional layer It works for the military, for spy agencies, and governments. If obscurity didn't have any benefit, then the military's latest weapons wouldn't be tested in the Nevada desert, or some remote island; they'd be tested in Illinois, or off the coast of Long Island.
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 ago
    I 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...
    - 6y ago
c0nsumer 6y ago
For a very specific example, look at the classified ciphers used by the US Gov't TLAs. Why are they classified? Because if they are harder to get info about -- literally obscured -- then it's an additional layer of defense. Or troop movements during war... Sure, the locations can be figured out, but by not broadcasting locations that's more work for the enemy and thus a bit more secure. Obscurity is absolutely a key piece of security, because it adds the complexity of discovery.
- thinkharderdev 6y ago
  This is true but I think that its not really a binary classification and there is a spectrum from useless and trivial obscurity (base64 encoding some "secret") to actually useful obscurity. After all, you can call password authentication "security through obscurity" since you only need to know the correct sequence of characters and your security relies on that sequence remaining obscure.
Florin_Andrei 6y ago
All encryption is "security through obscurity". The parameter space is very large. The key is somewhere in it. You have access to the whole space, but no clue as to where the key is. Good luck finding the key. > Instead it was originally meant as "if your only security is obscurity, it's bad". Since all security is essentially "through obscurity" somehow, I would simply reframe that into the onion model. Good security is like an onion, it has many layers. When you only have one layer, that's bad security.
rubyn00bie 6y ago
Hell yes, couldn't agree more. This last year, I found out about knockd and if that isn't some awesome shit, I dunno what is. Yet, there are plenty of articles saying, incorrectly, how it's awful. It is simply another layer of security on top of everything else you have. Like you said, security by obscurity is more about making it fucking slow, irritating, tedious, and without any sense of reward. "Aha! After only a week, I've figured out you're port knocking! Oh shit... wait, you still totally have the server properly locked down. FML." Because after each "obscure" layer there is a "real" layer of security and hopefully those all those real layers buy you the time to detect and prevent the threat.
- gfodor 6y ago
  Also don't forget that relative effort matters too. Consider "The Club" protection for cars - in a lot, the one with The Club is chosen last to break into just due to its relative difficulty. (Weighted against the potential upside, obviously.) The port knocking itself may actually be the strongest link in the chain, despite it being one of obscurity, if the population of targets in your "value pool" is large enough so that you are always below a sufficient number of others without knocking enabled, since all attackers will bounce to those when they realize they are not knocked.
EthanHeilman 6y ago
Security by obscurity is bad. Obscurity alone does not provide much security especially in a cryptographic setting. It can not be relied on as your sole protection. Security and obscurity: if you make something secure and then obscure information about that system from an attacker that can increase the security. However obscurity is often organizationally expensive and very fragile. A key can be rotated, but changing how something functions is very hard to rotate.
dheera 6y ago
I agree with the principle, but I disagree with the article's example of changing the SSH port as an example of obscurity. Lots of people set up SSH servers on multiple ports, especially in the case of relay servers that provide access to multiple machines through one IPv4 address. A better example of security by obscurity would be to, for example: * Flip all the SSH bits or XOR it with some long key. * Encapsulate SSH inside another protocol, such as websockets over HTTP port 80, or embedded inside what look to an outsider as cat pictures being sent over HTTP. * SSH over TCP over Skype video. Incidentally, any of these methods work well for confusing China's firewall and keeping the SSH connection alive, and would probably confuse hackers as well for a little while. They could all be implemented in a router box that doesn't affect your actual deployment.
e40 6y ago
The number of times I've seen people shitting all over port knocking is truly confusing. Since we added it several years ago, we've not had a single case of hackers trying to break into sshd. Before port knocking, 100's a day, even though it was on a very unusual port. I try to tell people this, when they poo poo port knocking, but they just don't get it. EDIT: s/the/they/
- somedude11 6y ago
  The same with "GnuPG is bad" mantra on hackernews. There is nothing better that GPG currently for all its functionality and the only answer you get when asking for substitute is don't use this function or use some obscure application. Yeah right.
  - fractionalhare 6y ago
    I agree that there is nothing better than GPG for the narrow scope of encrypting email. But I think there are very few cases where encrypted email is the most secure way to communicate, in lieu of other forms of encryption.
    - somedude11 6y ago
      Encrypted email is almost a marginal usage scenario for GPG compared to other uses. It does everything. It is everywhere.Yes it is big, nobody has to use all of it. Just like C++... oh wait it is unpopular on hacker news bubble too despite being a juggernaut of a language. It will still be relevant long after hacker news will be no more.
    - samatman 6y ago
      I basically use GPG for one thing, at this point: signing git commits. As far as I know, there isn't another GitHub/GitLab compatible way to do this. So I'll keep using GPG until there is.
  - wglb 6y ago
    Age is demonstrably better: https://github.com/FiloSottile/age https://github.com/FiloSottile/age Also, an informed analysis of PGP: https://latacora.micro.blog/2019/07/16/the-pgp-problem.html https://latacora.micro.blog/2019/07/16/the-pgp-problem.html
giantg2 6y ago
I agree. The only thing I would add is that it also needs to be maintainable - the obscurity should not impede the maintainer's understanding of the implementation.
_notreallyme_ 6y ago
It is obviously a misinterpretation of the original idea behind "security by obscurity is bad". Same goes for "goto considered harmful", which is not always true. Although, Kerckhoffs's principle are a good way of describing how a secure cryptosystem should behave. This is what people should have in mind. Obscuring will just add some delay as you state, but it might be irrelevant in many situations.
xenocyon 6y ago
That's not the only problem with obscurity. It not only obscures flaws from attackers, it also obscures them from you and makes a system hard to maintain. In any complex system, ultimately there will develop chinks in your armor that owe their existence to obscurity hacks that were thought clever at the time.
cjsawyer 6y ago
A lock that keeps an experienced lock-picker out for a few minutes will keep the layperson out indefinitely... Until they grab the bolt cutters. Everything is relative to context.
api 6y ago
Most programming and IT sayings are grossly misinterpreted. My personal favorite is "premature optimization is the root of all evil," which originally came with a ton of context but today is often misinterpreted as "never worry about performance" resulting in a lot of slow bloated software.
dastx 6y ago
Sure, security by obscurity slows down bad actors, but in reality it's not by a significant amount. Often the obscurity that you add aren't even where they're looking. You have to go through a certain level of effort to add it the obscurity. That effort is not enough to warrant the insignificant slowdown of the bad actor. You're better off using that effort to improve your real security in other areas. In addition, you're adding complexity that you have to maintain.
cmroanirgo 6y ago
Changing a port adds one bit of entropy. Not being forced to use "admin" as a username adds a whole bunch, but at least one bit. Not being forced to use https://url/admin https://url/admin also adds another bunch, but at least 1 bit. Of course, if any of these things are known the entropy drops to zero... Just like a private ssh key that gets pwnd. All too often I see tickets on open source projects asking for changes to allow better obfuscation, which are then denied using the mantra "obscurity is not security". They all add bits of entropy to a security and/or threat model that maintainers ignore.
samayylmao 6y ago
I know someone who would rather store passwords/api keys in the database encoded in a way that is not clear text but is not encrypted or hashed arguing that its overkill to encrypt. Obscurity instead of Security is bad too.
jakobmartz3 6y ago
Well put. Using it as an additional layer isn't bad.
lr4444lr 6y ago
Also, related, the kind of traffic needed to probe in a reasonable amount of time can easily be spot.
rukuu001 6y ago
Sure, like giving a login page an unexpected URL to foil bots (eg hiding WordPress admin). If that was the only security it’d be terrible. But not having 1000s of bots pounding on the door saves a lot of headaches.
mikorym 6y ago
A simple example would be separating usernames and passwords, having an outer and inner password (think Truecrypt/Veracrypt) or even personal quirks. Again, it depends how much the attacker knows, but even today you can still do the classic "hash my master key with site name" for a password that you wouldn't store anywhere.
LoSboccacc 6y ago
> Instead it was originally meant as "if your only security is obscurity, it's bad". no, not really. what it means is: every important sytem has attackers trying to exploit it. finding an exploit is a series of hunches while probing the system as a blackbox, and you need just one; meanwhile a defender has to be methodical enough find them all. given the differences, obscurity removes the defender ability to systematically analyze the system while on the other hand for an attacker it remains as much of a blackbox as it was before.
kristianpaul 6y ago
Agree, Its a good/cheap first step !

KarlKode 6y ago

An argument against obscurity is that it adds additional pains for your "regular" users (as in developers/3rd party developers/app developers) while being a small deterrent against unauthorised users (as they will be able to circumvent the "obscurity layer" and replicate their method to other bad actors). edit: In the first sentence "against" is not what I wanted to say: what I wanted to say is that it "downgrades it's effectiveness". I agree that obscurity can and sometimes should be a layer of security.

PragmaticPulp 6y ago
> An argument against obscurity is that it adds additional pains for your "regular" users (as in developers/3rd party developers/app developers) No one should be applying obscurity to public-facing APIs or anything for which documentation is widely distributed outside the company. A better example would be Snapchat's intense and always evolving obfuscation strategies: https://hot3eed.github.io/snap_part1_obfuscations.html https://hot3eed.github.io/snap_part1_obfuscations.html Even though someone took the challenge to de-obfuscate most (but not all) of the protections, just look at how much effort is required for anyone else to even follow that work. More importantly, consider how much effort is required relative to other platforms. It's enough of a pain that spammers and abusers are likely to choose other platforms to attack.
- gowld 6y ago
  When security is totally impossible because there is no way to distinguish a trusted party from an adversary, obscurity is the only hope.
  - austincheney 6y ago
    If you cannot distinguish a trusted party from a malicious party everything is then potentially malicious. This is why we have certificates, certificate revocation, and trust authorities.
    - blackflame7000 6y ago
      And that works great until a trust authority gets compromised. It's for this reason why the US DoD has it's own root certificate authorities and thus many military websites actually look like they have invalid https certs. Browsers don't ship with DoD root certs installed as trusted.
      - austincheney 6y ago
        Yeah, I am on a DODIN as I write this. In the civilian world a CA falls back on a decentralized scheme called Web of Trust which allows CAs to recipricate certs from other CAs and invalidate other CAs as necessary. The DOD chose to create their own CA scheme originally for financial reasons in that over a long enough time line new infrastructure pays for itself with expanded capabilities while minimizing operation costs dependent upon an outside service provider. This was before CACs were in use. https://en.wikipedia.org/wiki/Web_of_trust https://en.wikipedia.org/wiki/Web_of_trust
        blackflame7000 6y ago
        Thanks for the additional info, I didnt know (but probably should have assumed) that finance was the primary motivator. I just had to implement CAC authentication for a webapp and they still use their own CAs for client-side certs aka cac’s so it seems like it was a pretty savy investment at the time that’s not going away anytime soon

tetha 6y ago

Internally, we phrase it as "Make the system objectively hard, then don't tell all the details". Wasting an attackers time is a fine goal.

draugadrotten 6y ago
> Wasting an attackers time is a fine goal. reply This. Putting a tarpit on port 22 isn't going to stop an attacker, but it will slow the ssh scans down for everyone. https://github.com/skeeto/endlessh https://github.com/skeeto/endlessh
- PowerBar 6y ago
  Honeypots are fun, but be VERY careful how you deploy them. Ideally they are on a completely separate network on the WAN side of a second firewall. The last thing you want is for someone to find an exploit in your honeypot and use that to gain access to your network.
cogman10 6y ago
It's a lot like bike locks. Yes, most people can grab some bolt cutters, snip, and bike off. Yet, so many bikes remain unstolen with extremely week locks. The vast majority of attacks are crimes of opportunity. Hackers aren't generally trying to target a single company or computer for a bot net, they are looking to get as many as possible. Almost any amount of effort above and beyond the typical will cause them to jump past you as a target. Back to the bike lock analogy. Again, most locks can be bypassed, getting one that requires an edge grinder will almost certainly ensure that your bike won't be stolen (Why steal that bike when there are 20 with simple wire locks?). Add 2 locks and you've got a bike that will almost never be knicked. https://www.youtube.com/watch?v=oPDHPpnXPv8 https://www.youtube.com/watch?v=oPDHPpnXPv8 This video can teach you a LOT about software security.

weare138 6y ago

But the examples given won't help and is just bad advice in general. - Assume for every code obfuscator there's a deobfuscator or at least someone as clever as you out there. - Randomizing variable names it just a nuisance, it won't stop any competent pen tester or attacker. - Encrypting the database is an odd one. Your program will also have to decrypt the data to use it. Where do you store the encryption keys? In your code? Don't assume obfuscating your code and/or randomizing variables will protect your encryption keys.

jerf 6y ago
You seem to be thinking in terms of security mechanisms either perfectly blocking attacks or being useless. That's the wrong model. It's about costs. Obfuscating otherwise-open code doesn't mean that nobody can ever figure out what it does, but it raises their costs. Randomizing variables raises costs. Encrypting the DB raises costs on an amortized basis (some cracks may get the key and then it may not raise the cost much, but other cracks may only get the data in which case cost is raised a lot). Things are "secure" not when it's impossible for any actor in the world you don't want to get access to get access, but when the costs to those actors exceed the loss you may experience. (Preferably by a solid margin, for various reasons.) As to whether this is good or bad advice, that depends on how expensive these things are (e.g., encrypting database fields may be very expensive if you write raw SQL calls as your primary DB interface but may be dirt cheap if you're using an ORM that has it as a built-in feature) and your local threat model (e.g., "dedicated, personalized attackers reading your source" is very different from "does it defeat automated scanners?"). You can't know whether these are good or bad ideas without that additional context.
- thaumasiotes 6y ago
  > You seem to be thinking in terms of security mechanisms either perfectly blocking attacks or being useless. That's the wrong model. It's about costs. This is something that bothered me quite a bit in Bruce Schneier's various comments on airline security. He repeatedly wrote that profiling young Arab men as likely terrorists was pointless, because if it became harder for young Arab men to get through security, terrorist organizations would simply start sending Japanese grandmothers. But of course where it's relatively easy to find young men willing to die for a cause, it's much more difficult to find grandmothers who will do the same. And where it's relatively easy for an Islamic group based in the Middle East to connect to Arabic social networks, it's much harder for that group to connect to Japanese networks.

Verdex 6y ago

In nature, prey animals will sometimes jump when they spot a predator[1]. One of the explanations is that this is the animal communicating to the predator that it is a healthy prey animal that would be hard to catch and therefore the predator should choose to chase someone else. I think we can kind of view obscurity in the same way. It's a way to signal to a predator that we're a hard target and that they should give up. Of course in the age of automation, relying on obscurity alone is foolish because once someone has automated an attack that defeats the obscurity, then it is little or no effort for an attacker to bypass it. Of course, sprinkling a little bit of obscurity on top of a good security solution might provide an incentive for attackers to go someplace else. And I can't help but think of the guy who was trying to think of ways to perform psychological attacks against reverse engineerers [2]. [1] - https://en.wikipedia.org/wiki/Stotting https://en.wikipedia.org/wiki/Stotting [2] - https://www.youtube.com/watch?v=HlUe0TUHOIc https://www.youtube.com/watch?v=HlUe0TUHOIc

acoard 6y ago
>I think we can kind of view obscurity in the same way. It's a way to signal to a predator that we're a hard target and that they should give up. This has it completely backwards. Security through obscurity's goal is not to signal predators, it's the opposite. The goal is to obscure, to hide. The "signal" is there is nothing here (or nothing here worth your time). One of the best examples (it's in the article!) is changing the default SSH port. Just by obscuring your port you can usually filter out the majority of break-in attempts. The only way security through obscurity signals to "predators" is if they've seen past your defence, and thus defeated the obscurity. Obscurity (once revealed) is not a deterrent. Likewise an authentication method (once exploited) is not a deterrent. >Of course in the age of automation, relying on obscurity alone is foolish because once someone has automated an attack that defeats the obscurity, then it is little or no effort for an attacker to bypass it. This is true of any exploit basically. Look no further than metasploit. Another example: a worm is a self-automating exploit.
- Verdex 6y ago
  > This has it completely backwards. Security through obscurity's goal is not to signal predators, it's the opposite. The goal is to obscure, to hide. The "signal" is there is nothing here (or nothing here worth your time). Most of the usages of "security through obscurity" that I've seen dissected and decried haven't been in the sense that something was being hidden, but rather that something was being confused. For example, using base 64 encoding instead of encrypting something. Or running a code obfuscator on source code instead of making the code actually secure. Either way the economic costs that I'm talking about are valid. If an attacker sees that your SSH port isn't where it's supposed to be OR if an attacker sees that your SSH port ignores all packets sent to it (unless you first send a packet thats 25 0xFF bytes), then either way they're being signaled that you are more trouble than the computer that has an open telnet port. There are slightly different usages of the same word, but the effect looks to me to be the same. More investigation or automation can make the obscurity go away, but it does make things a bit harder.

aeternum 6y ago

It's fine as an additional layer only when the primary layers do not rely on obscurity. I've seen too many instances where obscurity is used to justify weak primary layers (IE it's fine we're using this single word shared password since we have all these other layers). It can often provide a false sense of security since it looks like a security layer when in reality it often turns out to simply be a minor inconvenience to an experienced attacker.

outworlder 6y ago

Maybe the test should be: "is my system considered to be secure even without any obscurity?" If the answer is yes, then add obscurity. For instance, the port 22 example. Suppose you have a bastion host. SSHD running on port 22, root password disabled, passwords disabled (only SSH keys), no other services running, all other ports filtered/closed. It should be fairly secure, even if exposed to the internet, right? Now you can change the port. Change the SSH banner and hide the version. Add some port knocking. And so on. None of these measures would work by itself, but they will discourage non-targeted attackers.

jopsen 6y ago
They are also non-trivial amounts of work, both to build and to maintain.. Someday, someone will have problems connecting and waste half a day debugging it before they realize what is up.

reaperducer 6y ago

Many serious real-world scenarios do use obscurity as an additional layer It works for the military, for spy agencies, and governments. If obscurity didn't have any benefit, then the military's latest weapons wouldn't be tested in the Nevada desert, or some remote island; they'd be tested in Illinois, or off the coast of Long Island.

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 ago
  I 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...
  - 6y ago

c0nsumer 6y ago

For a very specific example, look at the classified ciphers used by the US Gov't TLAs. Why are they classified? Because if they are harder to get info about -- literally obscured -- then it's an additional layer of defense. Or troop movements during war... Sure, the locations can be figured out, but by not broadcasting locations that's more work for the enemy and thus a bit more secure. Obscurity is absolutely a key piece of security, because it adds the complexity of discovery.

thinkharderdev 6y ago
This is true but I think that its not really a binary classification and there is a spectrum from useless and trivial obscurity (base64 encoding some "secret") to actually useful obscurity. After all, you can call password authentication "security through obscurity" since you only need to know the correct sequence of characters and your security relies on that sequence remaining obscure.

Florin_Andrei 6y ago

All encryption is "security through obscurity". The parameter space is very large. The key is somewhere in it. You have access to the whole space, but no clue as to where the key is. Good luck finding the key. > Instead it was originally meant as "if your only security is obscurity, it's bad". Since all security is essentially "through obscurity" somehow, I would simply reframe that into the onion model. Good security is like an onion, it has many layers. When you only have one layer, that's bad security.

rubyn00bie 6y ago

Hell yes, couldn't agree more. This last year, I found out about knockd and if that isn't some awesome shit, I dunno what is. Yet, there are plenty of articles saying, incorrectly, how it's awful. It is simply another layer of security on top of everything else you have. Like you said, security by obscurity is more about making it fucking slow, irritating, tedious, and without any sense of reward. "Aha! After only a week, I've figured out you're port knocking! Oh shit... wait, you still totally have the server properly locked down. FML." Because after each "obscure" layer there is a "real" layer of security and hopefully those all those real layers buy you the time to detect and prevent the threat.

gfodor 6y ago
Also don't forget that relative effort matters too. Consider "The Club" protection for cars - in a lot, the one with The Club is chosen last to break into just due to its relative difficulty. (Weighted against the potential upside, obviously.) The port knocking itself may actually be the strongest link in the chain, despite it being one of obscurity, if the population of targets in your "value pool" is large enough so that you are always below a sufficient number of others without knocking enabled, since all attackers will bounce to those when they realize they are not knocked.

EthanHeilman 6y ago

Security by obscurity is bad. Obscurity alone does not provide much security especially in a cryptographic setting. It can not be relied on as your sole protection. Security and obscurity: if you make something secure and then obscure information about that system from an attacker that can increase the security. However obscurity is often organizationally expensive and very fragile. A key can be rotated, but changing how something functions is very hard to rotate.

dheera 6y ago

I agree with the principle, but I disagree with the article's example of changing the SSH port as an example of obscurity. Lots of people set up SSH servers on multiple ports, especially in the case of relay servers that provide access to multiple machines through one IPv4 address. A better example of security by obscurity would be to, for example: * Flip all the SSH bits or XOR it with some long key. * Encapsulate SSH inside another protocol, such as websockets over HTTP port 80, or embedded inside what look to an outsider as cat pictures being sent over HTTP. * SSH over TCP over Skype video. Incidentally, any of these methods work well for confusing China's firewall and keeping the SSH connection alive, and would probably confuse hackers as well for a little while. They could all be implemented in a router box that doesn't affect your actual deployment.

e40 6y ago

The number of times I've seen people shitting all over port knocking is truly confusing. Since we added it several years ago, we've not had a single case of hackers trying to break into sshd. Before port knocking, 100's a day, even though it was on a very unusual port. I try to tell people this, when they poo poo port knocking, but they just don't get it. EDIT: s/the/they/

somedude11 6y ago
The same with "GnuPG is bad" mantra on hackernews. There is nothing better that GPG currently for all its functionality and the only answer you get when asking for substitute is don't use this function or use some obscure application. Yeah right.
- fractionalhare 6y ago
  I agree that there is nothing better than GPG for the narrow scope of encrypting email. But I think there are very few cases where encrypted email is the most secure way to communicate, in lieu of other forms of encryption.
  - somedude11 6y ago
    Encrypted email is almost a marginal usage scenario for GPG compared to other uses. It does everything. It is everywhere.Yes it is big, nobody has to use all of it. Just like C++... oh wait it is unpopular on hacker news bubble too despite being a juggernaut of a language. It will still be relevant long after hacker news will be no more.
  - samatman 6y ago
    I basically use GPG for one thing, at this point: signing git commits. As far as I know, there isn't another GitHub/GitLab compatible way to do this. So I'll keep using GPG until there is.
- wglb 6y ago
  Age is demonstrably better: https://github.com/FiloSottile/age https://github.com/FiloSottile/age Also, an informed analysis of PGP: https://latacora.micro.blog/2019/07/16/the-pgp-problem.html https://latacora.micro.blog/2019/07/16/the-pgp-problem.html

giantg2 6y ago

I agree. The only thing I would add is that it also needs to be maintainable - the obscurity should not impede the maintainer's understanding of the implementation.

_notreallyme_ 6y ago

It is obviously a misinterpretation of the original idea behind "security by obscurity is bad". Same goes for "goto considered harmful", which is not always true. Although, Kerckhoffs's principle are a good way of describing how a secure cryptosystem should behave. This is what people should have in mind. Obscuring will just add some delay as you state, but it might be irrelevant in many situations.

xenocyon 6y ago

That's not the only problem with obscurity. It not only obscures flaws from attackers, it also obscures them from you and makes a system hard to maintain. In any complex system, ultimately there will develop chinks in your armor that owe their existence to obscurity hacks that were thought clever at the time.

cjsawyer 6y ago

A lock that keeps an experienced lock-picker out for a few minutes will keep the layperson out indefinitely... Until they grab the bolt cutters. Everything is relative to context.

api 6y ago

Most programming and IT sayings are grossly misinterpreted. My personal favorite is "premature optimization is the root of all evil," which originally came with a ton of context but today is often misinterpreted as "never worry about performance" resulting in a lot of slow bloated software.

dastx 6y ago

Sure, security by obscurity slows down bad actors, but in reality it's not by a significant amount. Often the obscurity that you add aren't even where they're looking. You have to go through a certain level of effort to add it the obscurity. That effort is not enough to warrant the insignificant slowdown of the bad actor. You're better off using that effort to improve your real security in other areas. In addition, you're adding complexity that you have to maintain.

cmroanirgo 6y ago

Changing a port adds one bit of entropy. Not being forced to use "admin" as a username adds a whole bunch, but at least one bit. Not being forced to use https://url/admin https://url/admin also adds another bunch, but at least 1 bit. Of course, if any of these things are known the entropy drops to zero... Just like a private ssh key that gets pwnd. All too often I see tickets on open source projects asking for changes to allow better obfuscation, which are then denied using the mantra "obscurity is not security". They all add bits of entropy to a security and/or threat model that maintainers ignore.

samayylmao 6y ago

I know someone who would rather store passwords/api keys in the database encoded in a way that is not clear text but is not encrypted or hashed arguing that its overkill to encrypt. Obscurity instead of Security is bad too.

jakobmartz3 6y ago

Well put. Using it as an additional layer isn't bad.

lr4444lr 6y ago

Also, related, the kind of traffic needed to probe in a reasonable amount of time can easily be spot.

rukuu001 6y ago

Sure, like giving a login page an unexpected URL to foil bots (eg hiding WordPress admin). If that was the only security it’d be terrible. But not having 1000s of bots pounding on the door saves a lot of headaches.

mikorym 6y ago

A simple example would be separating usernames and passwords, having an outer and inner password (think Truecrypt/Veracrypt) or even personal quirks. Again, it depends how much the attacker knows, but even today you can still do the classic "hash my master key with site name" for a password that you wouldn't store anywhere.

LoSboccacc 6y ago

> Instead it was originally meant as "if your only security is obscurity, it's bad". no, not really. what it means is: every important sytem has attackers trying to exploit it. finding an exploit is a series of hunches while probing the system as a blackbox, and you need just one; meanwhile a defender has to be methodical enough find them all. given the differences, obscurity removes the defender ability to systematically analyze the system while on the other hand for an attacker it remains as much of a blackbox as it was before.

kristianpaul 6y ago

Agree, Its a good/cheap first step !