5 ms·

The idea that "security through obscurity is not security" is a dumb meme that needs to die. In the real world security through obscurity is absolutely security

The idea that "security through obscurity is not security" is a dumb meme that needs to die. In the real world security through obscurity is absolutely security. Your threat model is not super hackers with unlimited resources, obscurity helps, in some cases it helps a LOT. (to be clear I'm responding specifically to your second point, I believe RIOT is institutionally incompetent and it is fully possible to have a game with an open source core that has less cheating than LoL, I also believe that the folks at RIOT are incapable of such a thing because of a combination of bad incentives and incompetence)

psychoslave 4y ago
>Your threat model is not super hackers with unlimited resources, obscurity helps, in some cases it helps a LOT. You don’t know who is going to try to hack the system, and the security strategy should handle the fact that the system is going to be compromised at some point. Otherwise you don’t have a security policy, but simply a more or less efficient palliative to fear that risks generates. Yes, if you know who is going to have a will to attack, in which timeframe and with which resources at hand, security by obscurity surely can help a lot. Otherwise this is just buying the comfort of delusion, in my humble opinion.
- thot_experiment 4y ago
  > Otherwise this is just buying the comfort of delusion The same goes for any other security "guarantee". Security isn't something you rely on, it's a constant fight, obscurity is a reasonable thing to have in your arsenal. If you're at some point claiming "this is secure" you're deluding yourself, the only reasonable claim is "we have a lot of barriers to being compromised" or perhaps "we are secure against this vector", if obscurity is one of those barriers that's real and it provides a tangible benefit. Penetration is stochastic, the measures you take to prevent it change the odds.
- UncleMeat 4y ago
  Kerckhoff's Principle only applies to cryptosystems. In systems security it is more like an onion or layers of swiss cheese.
SturgeonsLaw 4y ago
Yep. Too often people fall into a binary way of thinking - it's either perfectly secure, or not secure at all. It's like that bell curve meme with the dunce at one end ("we should obscure our system"), the midwit at the peak ("security through obscurity is not security"), and the genius at the right ("we should obscure our system"). Obscurity *by itself* is a poor security measure, but it can decrease the surface area for automated attacks substantially. A determined human can figure them out eventually, but if their bot never sees you in the first place, the human might never even attempt the attack. Obscurity is not a bulletproof shield, it's another layer of Swiss cheese.
- tomkarho 4y ago
  Continuing with the food analogy: Obscurity is not the meat and potatoes of your security. It's salt and pepper.
cartoonworld 4y ago
I'd go with "Fake it till you make it" security. Everything will be fine.
kleiba 4y ago
> our threat model is not super hackers with unlimited resources Then what is it? Script kiddies? I doubt that they are going to benefit from gaining access to a complex code base.
chongli 4y ago
Security is only partly about the threat model. The other part is the failure mode. If your failure mode is “our company goes out of business if our code ever leaks out” then you’re probably too heavily invested in security by obscurity.
cthalupa 4y ago
The argument that security through obscurity isn't security is that when it is open there are more eyes that can see security flaws within the code and get it fixed vs. just the people attempting to exploit it. Not having access to the source might obscure potential vectors from attackers, but at the same time, those vectors might be fairly discoverable without the code, or they might be quickly fixed if more people were looking at the code. I don't think anyone in this comment thread has the data to truly argue one way or the other. The open source world is obviously the easiest example here - there have certainly been plenty of exploits that people started using in the wild before any of the "Good Guys" caught it. But there's also been huge numbers of security bugs quietly fixed because some random person saw it and contributed a fix. And plenty of the highest visibility exploits over the past decade have been found by security researchers unrelated to the projects utilizing the open source code was part of their toolkit in finding issues. If it was closed source, would the "Good Guys" have found it before the "Bad Guys"? Who knows! You'd need to actually compile and analyze all this data to have a strong argument that isn't just people going off of what sounds the most logical to them, and there's also all sorts of confounding factors that would need to be accounted for, like value of the potential target, overall popularity of the codebase, etc.
- deelowe 4y ago
  > I don't think anyone in this comment thread has the data to truly argue one way or the other. There are plenty of historical examples of source code leaks leading to new attack vectors being discovered (e.g. TF2).
maldev 4y ago
In games obscurity isn't really a thing. They are prime targets for memory scanning and getting extremely accurate results. Here's how to build a simple "bot" for any game in about 30 seconds. Step 1, Scan memory for Hp using a tool like cheat engine. Step 2. Since you know simple C programming, you know HP is kept in a structure, most likely the player structure. Look at surrounding memory and you'll have something like this. struct LocalPlayer { INT32 CurHP; INT32 MaxHp; INT32 CurMana; INT32 MaxMana; Position Pos; } Step 3. Now you have a basic structure, how do you find what uses it? Well, you know what a getter setter is from your CS 101 class. So you set a HW breakpoint on Read for the hp, and a HW Breakpoint on Write for the hp. Now you have GetHp(); And SetHp(); Step 4. You also remember how linkers work from your Compilers class, so knowing this, just like the structure has similar variables in memory, the binary will also have similar functions next to eachother(Or you can use class/variable passing from your struct.). So Right below GetHp, is 99 % of the time going to be GetMana. Step 5. Now you have your structures, and know what functions use it, so find the global variable or scrape how these functions get the address to update. Step 6. Repeat for other players using exact same steps, congrats, you now have all you need for a wallhack, bot, or whatever you want. So as we can see, no code is needed, no big brain hacks are needed. A cs 101 student can do this(And alot do, this is why cheats are filled with skids). And it's all done through super simple dynamic analysis. Games are different, since in a regular application, you won't be able to memory scan as easily.

psychoslave 4y ago

>Your threat model is not super hackers with unlimited resources, obscurity helps, in some cases it helps a LOT. You don’t know who is going to try to hack the system, and the security strategy should handle the fact that the system is going to be compromised at some point. Otherwise you don’t have a security policy, but simply a more or less efficient palliative to fear that risks generates. Yes, if you know who is going to have a will to attack, in which timeframe and with which resources at hand, security by obscurity surely can help a lot. Otherwise this is just buying the comfort of delusion, in my humble opinion.

thot_experiment 4y ago
> Otherwise this is just buying the comfort of delusion The same goes for any other security "guarantee". Security isn't something you rely on, it's a constant fight, obscurity is a reasonable thing to have in your arsenal. If you're at some point claiming "this is secure" you're deluding yourself, the only reasonable claim is "we have a lot of barriers to being compromised" or perhaps "we are secure against this vector", if obscurity is one of those barriers that's real and it provides a tangible benefit. Penetration is stochastic, the measures you take to prevent it change the odds.
UncleMeat 4y ago
Kerckhoff's Principle only applies to cryptosystems. In systems security it is more like an onion or layers of swiss cheese.

SturgeonsLaw 4y ago

Yep. Too often people fall into a binary way of thinking - it's either perfectly secure, or not secure at all. It's like that bell curve meme with the dunce at one end ("we should obscure our system"), the midwit at the peak ("security through obscurity is not security"), and the genius at the right ("we should obscure our system"). Obscurity *by itself* is a poor security measure, but it can decrease the surface area for automated attacks substantially. A determined human can figure them out eventually, but if their bot never sees you in the first place, the human might never even attempt the attack. Obscurity is not a bulletproof shield, it's another layer of Swiss cheese.

tomkarho 4y ago
Continuing with the food analogy: Obscurity is not the meat and potatoes of your security. It's salt and pepper.

cartoonworld 4y ago

I'd go with "Fake it till you make it" security. Everything will be fine.

kleiba 4y ago

> our threat model is not super hackers with unlimited resources Then what is it? Script kiddies? I doubt that they are going to benefit from gaining access to a complex code base.

chongli 4y ago

Security is only partly about the threat model. The other part is the failure mode. If your failure mode is “our company goes out of business if our code ever leaks out” then you’re probably too heavily invested in security by obscurity.

cthalupa 4y ago

The argument that security through obscurity isn't security is that when it is open there are more eyes that can see security flaws within the code and get it fixed vs. just the people attempting to exploit it. Not having access to the source might obscure potential vectors from attackers, but at the same time, those vectors might be fairly discoverable without the code, or they might be quickly fixed if more people were looking at the code. I don't think anyone in this comment thread has the data to truly argue one way or the other. The open source world is obviously the easiest example here - there have certainly been plenty of exploits that people started using in the wild before any of the "Good Guys" caught it. But there's also been huge numbers of security bugs quietly fixed because some random person saw it and contributed a fix. And plenty of the highest visibility exploits over the past decade have been found by security researchers unrelated to the projects utilizing the open source code was part of their toolkit in finding issues. If it was closed source, would the "Good Guys" have found it before the "Bad Guys"? Who knows! You'd need to actually compile and analyze all this data to have a strong argument that isn't just people going off of what sounds the most logical to them, and there's also all sorts of confounding factors that would need to be accounted for, like value of the potential target, overall popularity of the codebase, etc.

deelowe 4y ago
> I don't think anyone in this comment thread has the data to truly argue one way or the other. There are plenty of historical examples of source code leaks leading to new attack vectors being discovered (e.g. TF2).

maldev 4y ago

In games obscurity isn't really a thing. They are prime targets for memory scanning and getting extremely accurate results. Here's how to build a simple "bot" for any game in about 30 seconds. Step 1, Scan memory for Hp using a tool like cheat engine. Step 2. Since you know simple C programming, you know HP is kept in a structure, most likely the player structure. Look at surrounding memory and you'll have something like this. struct LocalPlayer { INT32 CurHP; INT32 MaxHp; INT32 CurMana; INT32 MaxMana; Position Pos; } Step 3. Now you have a basic structure, how do you find what uses it? Well, you know what a getter setter is from your CS 101 class. So you set a HW breakpoint on Read for the hp, and a HW Breakpoint on Write for the hp. Now you have GetHp(); And SetHp(); Step 4. You also remember how linkers work from your Compilers class, so knowing this, just like the structure has similar variables in memory, the binary will also have similar functions next to eachother(Or you can use class/variable passing from your struct.). So Right below GetHp, is 99 % of the time going to be GetMana. Step 5. Now you have your structures, and know what functions use it, so find the global variable or scrape how these functions get the address to update. Step 6. Repeat for other players using exact same steps, congrats, you now have all you need for a wallhack, bot, or whatever you want. So as we can see, no code is needed, no big brain hacks are needed. A cs 101 student can do this(And alot do, this is why cheats are filled with skids). And it's all done through super simple dynamic analysis. Games are different, since in a regular application, you won't be able to memory scan as easily.