9 ms·

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

by 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.
  - acoard 6y ago
    Fair point! Obscurity as confusion is not what I had in mind, but your points on confusion are totally valid. Your analogy with predators works better here. Using base64 encoding, or encrypting your database, are both examples in the article. While I agree base64 is super trivial, the point about either of these is defence in depth. In the language of the article, it's reducing likelihood of being compromised. >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. This is semantics. Personally I'd say if an attacker cannot sense anything to connect to, there is no "signal" you're sending. You're rather not sending a signal that you're a threat, as you're not sending a signal at all due to being functionally invisible. Otherwise, we could say literal nothingness is sending the same signal that your server is. We agree on the substance here, i.e. the obscurity increases the economic cost of hacking and works as a disincentive, so we may just agree to disagree on the semantics.
    - Retric 6y ago
- bleepblorp 6y ago
  Using a non-standard SSH port is a bad example because nmap can see through that deception in a few seconds. Any attacker who is looking for more than just the lowest of low-hanging fruit will not be even slightly deterred. A better example would be a port-knocking arrangement that hides sshd except from systems that probe a sequence of ports in a specific way. This is very much security by obscurity, because it's trivial for anyone who knows the port sequence to defeat, but it's also very effective as anyone who doesn't know the port sequence has no indication of how to start probing for a solution.
  - thinkharderdev 6y ago
    Maybe a bit nitpicky but I think port-knocking is in kind of a grey area. You can think of it as a kind of password where you have to know the correct series of ports. Since the number of ports is quite large, there is also a correspondingly large number of possible port sequences so you can't, in principle, brute force it without a lot of effort.
    - nordsieck 6y ago
      > Maybe a bit nitpicky but I think port-knocking is in kind of a grey area. You can think of it as a kind of password where you have to know the correct series of ports. Yes. But you also have to know that port knocking is enabled at all. That's the obscurity part.
      - thinkharderdev 6y ago
        Gotcha. Fair point.
      - smaudet 6y ago
        Eh, I think its how others have expressed in this thread. Security by obscurity is bad, not because it is bad to have well secured countermeasures, but because it encourages poor thinking with regards to methods you have in place, and additionally because it usually introduces extra, unintended attack vectors. You suffer from your own 'obscurity' - whether its because you forgot you had to port knock, use a different port, or because you somehow managed to leave a new exploit in some obscured code due a bug in the obscured code, or because you managed to open yourself up to an RCE with the port knocking, or some other obscure scenario you did not intend to create from whatever obscurity you created. I think this is different from Defense in Depth, which just says have more than one countermeasure in place, and to keep the counter measures 'separate', but well defined. Port knocking, but on a different box than your vpn box, on a different box than your ssh box. We aren't told to use 'well-defined' passwords, like 1234, obviously. If the point of 'obscurity' is 'secrets', that's all well and good, but that's not security, that's a password. Have a password, by all means, but tunnel it over TLS and use well defined security paths versus creating unnecessary risks.
- dylan604 6y ago
  In other words, changing the default SSH port number is similar to using camouflage. It just helps hide that something is there, but it does nothing to improve the defense once spotted. However, if the majority of predators don't see you, then the rest of your defenses are needed at that time.
  - ballenf 6y ago
    It's also an indication that there are no default passwords in use. So even if you know what port SSH lives on, there's a lower ROI to attacking it than a default port.
- Spooky23 6y ago
  You can’t compromise what you can’t see. Calling an administrator account “9834753” obscures it’s purpose and may reduce the likelihood of a compromise attempt as opposed to “databasesuperadmin”. But that doesn’t mean that you don’t need a good security token.
- voltagex_ 6y ago
  I just turn off password authentication on SSH and moved to keys, then moved to IPv6. The automated scans haven't made it to v6 yet. The only better thing I could do is have an external v4 SSH honeypot that moves as slowly as possible to tie up a (tiny) resource.
  - efreak 6y ago
    Endlessh and tarbit do this
  - BlueTemplar 6y ago
    IPv6 seems to be a good example of security by obscurity, with up to 64 bits of random IP adresses per machine, making scanning impossible in practice ?
- alexchamberlain 6y ago
  I find the SSH example slightly odd, when all you need to do is disable password authentication and root access. Moving away from port 22 just seems a little excessive?
saagarjha 6y ago
Using obfuscation is often a signal that you are a weak target, because there are a lot of places that use obfuscation but nothing else. A better indicator that you are a hard target is to enable common mitigations like NX, stack cookies, or ASLR.
- Verdex 6y ago
  Yeah, that's what I was trying to get at with my "in the age of automation" comment. If you go to a period in history without automation, then obscurity is going to be a lot more effective. And that's why I think people still want to go back to it. Obscurity is much easier to wrap your mind around than RSA, et al. However, the psychological warfare video does make me think that there's still a place for obscurity after you've already used actual security measures. If you can find any technique that makes your attacker work harder vs some other target, then it feels like there's an economic value to doing it as long as the cost to you is relatively low.
- dfox 6y ago
  There is one giant hole in your argument: both stack cookies and ASLR are mitigations that are nothing more than automated security through obscurity in the first place.
  - saagarjha 6y ago
    I assume you're equating picking a random SSH port with scanning for an ASLR slide or guessing a stack cookie, but they are different situations: processes that die are generally treated quite seriously, and they leave "loud" core dumps and stack traces as to what is going on–usually this gets noticed and quickly blocked. With SSH you can generally port scan people quickly and efficiently in a fairly small space (and to be fair, 16-bit bruteforces are sometimes done for applications as well, when possible)–and the "solution" here where you ban people that seem to hit you too often is literally what you are supposed to be running in the first place. And in general, the sentiment was "if you are using those things, you are likely to have invested time into other tools as well such as static analysis or sanitizer use" which are not "security through obscurity" in any sense, whereas the "obscurity" that gets security people riled up is the kind where people say things like "nobody can ever hack us because we changed variable names or used something nostandard" because it is usually followed with "…and because we had security we didn't hash any passwords".
deleted 6y ago
[deleted]
mcqueenjordan 6y ago
I think the predator/prey real world analog to "security through obscurity" would be camouflage.
shadowgovt 6y ago
The only downside I see immediately is that there's a counterweighted risk to obscurity in your security layer: you can confuse your own users (or yourself). Many security tools I've used are downright user hostile in how little information they provide the end-user (or the admin!) regarding why an auth process failed. It incentivizes people to simplify or bypass the system entirely when they can't understand the system.
- Gibbon1 6y ago
  Semirelated. Anytime I have written a protocol with a checksum I implement a 'magic checksum' that just passes. And a debug mode that enables it and diagnostics. The reason is usually if somethings wrong with a packet of data the best thing to do is ignore it completely. But that makes development insane. So having two modes gives you the best of both worlds.
robocat 6y ago
Your example is advertising which is the opposite of security through obscurity. Obscurity is another layer of hiding or indirection: like the owl has camouflage and it has a hole in a tree. Advertising your fitness (your stotting metaphor) is effective when: you are part of a herd, and the attacker will only attack the weakest in that herd and then be satisfied. Like double locking your bike next to a similar bike that has a weaker lock. Computer security is different because usually either: a) everyone in the herd is being attacked at once (scattergun/IP address range scanning), or b) you are being spear targeted individually (stotting won’t work against a human hunter with a gun, and advertising yourself won’t help against a directed attack). An example of advertising your security might be Google project zero, or bug bounties.
- Enginerrrd 6y ago
  >An example of advertising your security might be Google project zero, or bug bounties. That's more akin to a gecko sacrificing it's tail IMO. You're taking a predator that's capable of a successful attack and rewarding them for not doing it at some cost to yourself. It provides an easy and less risky way of getting paid.
angry_octet 6y ago
I think it is the opposite -- systems with rigourous security tend to be more open, because the designers are confident they understand their system. In contrast, systems that practice security through obscurity are often owned/managed by people afraid of what will go wrong. We should distinguish obscurity from intentionally hiding the configuration, which makes attackers undertake discovery, and hence can lead to detection. But your internal red team / security review should have all the details available. If loss of obscurity leads directly to compromise then you don't have security. Cf insider threat.
b0rsuk 6y ago
I've heard a better analogy - security by obscurity is like camouflage on a tank. A tank has massive armor and a terrifying gun to defend itself with. But even a half-assed camouflage can delay enemy reaction by a few seconds. Sometimes it's all it takes, because it lets you shoot first. In addition, the cost of camouflage paint or a net is laughably low and can be replaced in the field. It's simply an extra layer of protection and a very inexpensive one.
- deleted 6y ago
  [deleted]
- est 6y ago
  https://www.reddit.com/r/netsec/comments/ioxux2/security_by_obscurity_is_underrated/ https://www.reddit.com/r/netsec/comments/ioxux2/security_by_... (security by obscurity ) is camouflage, not armor.
- smaudet 6y ago
  Its also a terrible thing to say to your pointy haired boss, which is in part where I think the heresy of talking about it comes from. If you say "security" that's the last thing your boss heard you say "oh yeah obscurity, great, that's cheap!" and you end up in camouflage in the field, with no tank. I don't like the article the more I think about it, it speaks of inexperience and perhaps not understanding the concept well, and that it is important to accurately articulate and distinguish concepts. No one is going to argue that camo isn't an advantage to a soldier, but it is not security in any meaningful sense, no more than camouflage is a bunker, or a trench, or a tank. And Camo comes with a real downside too, just like in the field, if you're camo'ed too well, you're apt to take friendly fire or be missed by artillery lobbing a shell.
will4274 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 this analogy perfectly explains my hostility to security by obscurity. When I see a system that uses standard ports and demonstrates best practices, I think "oh well, they probably know what they are doing." When I see a system using strange ports and / or has extra extraneous crypto, I think "well, maybe this guy is an idiot" and take a deeper look.
erie 6y ago
When moving to some scary streets in my travel,I would shout to my companion in the local language, trying to signal to potential thugs to choose chasing someone else. I did it once in Russia while in a dodgy neighborhood to buy vodka, and back in the 1990 when westerners were under some threats in the middl east.
eru 6y ago
The security example of stotting would be the exact opposite: Remove all obscurity and expose all your techniques and algorithms and setting up bounties for people to break your defences. See eg https://cloud.google.com/beyondcorp https://cloud.google.com/beyondcorp and https://cloud.google.com/security/beyondprod https://cloud.google.com/security/beyondprod where Google gives up on VPNs.

by Verdex 6y ago

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.
- acoard 6y ago
  Fair point! Obscurity as confusion is not what I had in mind, but your points on confusion are totally valid. Your analogy with predators works better here. Using base64 encoding, or encrypting your database, are both examples in the article. While I agree base64 is super trivial, the point about either of these is defence in depth. In the language of the article, it's reducing likelihood of being compromised. >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. This is semantics. Personally I'd say if an attacker cannot sense anything to connect to, there is no "signal" you're sending. You're rather not sending a signal that you're a threat, as you're not sending a signal at all due to being functionally invisible. Otherwise, we could say literal nothingness is sending the same signal that your server is. We agree on the substance here, i.e. the obscurity increases the economic cost of hacking and works as a disincentive, so we may just agree to disagree on the semantics.
  - Retric 6y ago
bleepblorp 6y ago
Using a non-standard SSH port is a bad example because nmap can see through that deception in a few seconds. Any attacker who is looking for more than just the lowest of low-hanging fruit will not be even slightly deterred. A better example would be a port-knocking arrangement that hides sshd except from systems that probe a sequence of ports in a specific way. This is very much security by obscurity, because it's trivial for anyone who knows the port sequence to defeat, but it's also very effective as anyone who doesn't know the port sequence has no indication of how to start probing for a solution.
- thinkharderdev 6y ago
  Maybe a bit nitpicky but I think port-knocking is in kind of a grey area. You can think of it as a kind of password where you have to know the correct series of ports. Since the number of ports is quite large, there is also a correspondingly large number of possible port sequences so you can't, in principle, brute force it without a lot of effort.
  - nordsieck 6y ago
    > Maybe a bit nitpicky but I think port-knocking is in kind of a grey area. You can think of it as a kind of password where you have to know the correct series of ports. Yes. But you also have to know that port knocking is enabled at all. That's the obscurity part.
    - thinkharderdev 6y ago
      Gotcha. Fair point.
    - smaudet 6y ago
      Eh, I think its how others have expressed in this thread. Security by obscurity is bad, not because it is bad to have well secured countermeasures, but because it encourages poor thinking with regards to methods you have in place, and additionally because it usually introduces extra, unintended attack vectors. You suffer from your own 'obscurity' - whether its because you forgot you had to port knock, use a different port, or because you somehow managed to leave a new exploit in some obscured code due a bug in the obscured code, or because you managed to open yourself up to an RCE with the port knocking, or some other obscure scenario you did not intend to create from whatever obscurity you created. I think this is different from Defense in Depth, which just says have more than one countermeasure in place, and to keep the counter measures 'separate', but well defined. Port knocking, but on a different box than your vpn box, on a different box than your ssh box. We aren't told to use 'well-defined' passwords, like 1234, obviously. If the point of 'obscurity' is 'secrets', that's all well and good, but that's not security, that's a password. Have a password, by all means, but tunnel it over TLS and use well defined security paths versus creating unnecessary risks.
dylan604 6y ago
In other words, changing the default SSH port number is similar to using camouflage. It just helps hide that something is there, but it does nothing to improve the defense once spotted. However, if the majority of predators don't see you, then the rest of your defenses are needed at that time.
- ballenf 6y ago
  It's also an indication that there are no default passwords in use. So even if you know what port SSH lives on, there's a lower ROI to attacking it than a default port.
Spooky23 6y ago
You can’t compromise what you can’t see. Calling an administrator account “9834753” obscures it’s purpose and may reduce the likelihood of a compromise attempt as opposed to “databasesuperadmin”. But that doesn’t mean that you don’t need a good security token.
voltagex_ 6y ago
I just turn off password authentication on SSH and moved to keys, then moved to IPv6. The automated scans haven't made it to v6 yet. The only better thing I could do is have an external v4 SSH honeypot that moves as slowly as possible to tie up a (tiny) resource.
- efreak 6y ago
  Endlessh and tarbit do this
- BlueTemplar 6y ago
  IPv6 seems to be a good example of security by obscurity, with up to 64 bits of random IP adresses per machine, making scanning impossible in practice ?
alexchamberlain 6y ago
I find the SSH example slightly odd, when all you need to do is disable password authentication and root access. Moving away from port 22 just seems a little excessive?

saagarjha 6y ago

Using obfuscation is often a signal that you are a weak target, because there are a lot of places that use obfuscation but nothing else. A better indicator that you are a hard target is to enable common mitigations like NX, stack cookies, or ASLR.

Verdex 6y ago
Yeah, that's what I was trying to get at with my "in the age of automation" comment. If you go to a period in history without automation, then obscurity is going to be a lot more effective. And that's why I think people still want to go back to it. Obscurity is much easier to wrap your mind around than RSA, et al. However, the psychological warfare video does make me think that there's still a place for obscurity after you've already used actual security measures. If you can find any technique that makes your attacker work harder vs some other target, then it feels like there's an economic value to doing it as long as the cost to you is relatively low.
dfox 6y ago
There is one giant hole in your argument: both stack cookies and ASLR are mitigations that are nothing more than automated security through obscurity in the first place.
- saagarjha 6y ago
  I assume you're equating picking a random SSH port with scanning for an ASLR slide or guessing a stack cookie, but they are different situations: processes that die are generally treated quite seriously, and they leave "loud" core dumps and stack traces as to what is going on–usually this gets noticed and quickly blocked. With SSH you can generally port scan people quickly and efficiently in a fairly small space (and to be fair, 16-bit bruteforces are sometimes done for applications as well, when possible)–and the "solution" here where you ban people that seem to hit you too often is literally what you are supposed to be running in the first place. And in general, the sentiment was "if you are using those things, you are likely to have invested time into other tools as well such as static analysis or sanitizer use" which are not "security through obscurity" in any sense, whereas the "obscurity" that gets security people riled up is the kind where people say things like "nobody can ever hack us because we changed variable names or used something nostandard" because it is usually followed with "…and because we had security we didn't hash any passwords".

deleted 6y ago

[deleted]

mcqueenjordan 6y ago

I think the predator/prey real world analog to "security through obscurity" would be camouflage.

shadowgovt 6y ago

The only downside I see immediately is that there's a counterweighted risk to obscurity in your security layer: you can confuse your own users (or yourself). Many security tools I've used are downright user hostile in how little information they provide the end-user (or the admin!) regarding why an auth process failed. It incentivizes people to simplify or bypass the system entirely when they can't understand the system.

Gibbon1 6y ago
Semirelated. Anytime I have written a protocol with a checksum I implement a 'magic checksum' that just passes. And a debug mode that enables it and diagnostics. The reason is usually if somethings wrong with a packet of data the best thing to do is ignore it completely. But that makes development insane. So having two modes gives you the best of both worlds.

robocat 6y ago

Your example is advertising which is the opposite of security through obscurity. Obscurity is another layer of hiding or indirection: like the owl has camouflage and it has a hole in a tree. Advertising your fitness (your stotting metaphor) is effective when: you are part of a herd, and the attacker will only attack the weakest in that herd and then be satisfied. Like double locking your bike next to a similar bike that has a weaker lock. Computer security is different because usually either: a) everyone in the herd is being attacked at once (scattergun/IP address range scanning), or b) you are being spear targeted individually (stotting won’t work against a human hunter with a gun, and advertising yourself won’t help against a directed attack). An example of advertising your security might be Google project zero, or bug bounties.

Enginerrrd 6y ago
>An example of advertising your security might be Google project zero, or bug bounties. That's more akin to a gecko sacrificing it's tail IMO. You're taking a predator that's capable of a successful attack and rewarding them for not doing it at some cost to yourself. It provides an easy and less risky way of getting paid.

angry_octet 6y ago

I think it is the opposite -- systems with rigourous security tend to be more open, because the designers are confident they understand their system. In contrast, systems that practice security through obscurity are often owned/managed by people afraid of what will go wrong. We should distinguish obscurity from intentionally hiding the configuration, which makes attackers undertake discovery, and hence can lead to detection. But your internal red team / security review should have all the details available. If loss of obscurity leads directly to compromise then you don't have security. Cf insider threat.

b0rsuk 6y ago

I've heard a better analogy - security by obscurity is like camouflage on a tank. A tank has massive armor and a terrifying gun to defend itself with. But even a half-assed camouflage can delay enemy reaction by a few seconds. Sometimes it's all it takes, because it lets you shoot first. In addition, the cost of camouflage paint or a net is laughably low and can be replaced in the field. It's simply an extra layer of protection and a very inexpensive one.

deleted 6y ago
[deleted]
est 6y ago
https://www.reddit.com/r/netsec/comments/ioxux2/security_by_obscurity_is_underrated/ https://www.reddit.com/r/netsec/comments/ioxux2/security_by_... (security by obscurity ) is camouflage, not armor.
smaudet 6y ago
Its also a terrible thing to say to your pointy haired boss, which is in part where I think the heresy of talking about it comes from. If you say "security" that's the last thing your boss heard you say "oh yeah obscurity, great, that's cheap!" and you end up in camouflage in the field, with no tank. I don't like the article the more I think about it, it speaks of inexperience and perhaps not understanding the concept well, and that it is important to accurately articulate and distinguish concepts. No one is going to argue that camo isn't an advantage to a soldier, but it is not security in any meaningful sense, no more than camouflage is a bunker, or a trench, or a tank. And Camo comes with a real downside too, just like in the field, if you're camo'ed too well, you're apt to take friendly fire or be missed by artillery lobbing a shell.

will4274 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 this analogy perfectly explains my hostility to security by obscurity. When I see a system that uses standard ports and demonstrates best practices, I think "oh well, they probably know what they are doing." When I see a system using strange ports and / or has extra extraneous crypto, I think "well, maybe this guy is an idiot" and take a deeper look.

erie 6y ago

When moving to some scary streets in my travel,I would shout to my companion in the local language, trying to signal to potential thugs to choose chasing someone else. I did it once in Russia while in a dodgy neighborhood to buy vodka, and back in the 1990 when westerners were under some threats in the middl east.

eru 6y ago

The security example of stotting would be the exact opposite: Remove all obscurity and expose all your techniques and algorithms and setting up bounties for people to break your defences. See eg https://cloud.google.com/beyondcorp https://cloud.google.com/beyondcorp and https://cloud.google.com/security/beyondprod https://cloud.google.com/security/beyondprod where Google gives up on VPNs.