5 ms·

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

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.
  - czzr 6y ago
    But it’s easier to find Arab women. Or an Irish girlfriend of an Arab man. Or two old Korean people. (All real examples)
    - jfk13 6y ago
      I'm pretty sure the potential recruitment pool of young Arab men is still many times greater than the pool of Irish girlfriends of Arab men. It's about improving the odds/reducing the exposure, not achieving some theoretical absolute perfection.
      - gowld 6y ago
        It's bad math. It doesn't matter if you have 1 arab man and 1 korean woman, or 1000 arab men and 1 korean woman. You only need 1. If you calculate the probabilities correctly, you get very different results.
    - thaumasiotes 6y ago
      No, obviously it's harder to find two old Korean people than one old Japanese person. Everything you've listed is hundreds, thousands, or millions of times more difficult than the young-Arab-man case. Suppose you take down a plane with a young Arab man, and then you want to take down a second plane. There is a neverending stream of similar men willing to do the job. If your strategy requires you to use elderly Korean couples, you're done after the first plane -- you'll never find a second one.
  - Nasrudith 6y ago
    The point is that if you try to be a selfish bigotted dick and create profiling to shift the inconvenience of security delays onto the other you create a gaping hole for that shortcut - don't look the part and then do damage. It is a bad policy morally and practically meaning the only rational reason to support it is being an asshole who sees the harm as a good.
  - bleepblorp 6y ago
    The problem with heavily focusing on Arabs while paying less attention to other threats is that Arab Islamist terrorists aren't the only problem aviation security needs to deal with. Focusing most of the security effort on Arabs is a good way to fight the war of 19 years ago, but it leaves the air travel system vulnerable to upstart terrorist movements that see the lack of universal security as an exploitable vulnerability. For example, there's nothing to say that America's right wing terrorist groups won't decide to switch from shootings and vehicle ramming attacks to attacks on air travel. The TSA ought to be prepared for this, or any other, emerging threat.
- BurningFrog 6y ago
  > You seem to be thinking in terms of security mechanisms either perfectly blocking attacks or being useless. Ours is an industry with a lot of people "on the spectrum". https://thesilentwaveblog.wordpress.com/2017/03/08/aspergers-autism-and-black-and-white-thinking/ https://thesilentwaveblog.wordpress.com/2017/03/08/aspergers...
- cgriswald 6y ago
  It's still bad security. Sure, it increases costs for a certain subset of attackers. Instead of sending easily found and trained young Arab men, they have to put more effort into recruitment. However, in return for that, they get far reduced scrutiny. Therein lies the problem. It is the real-world equivalent of dropping all packets from a country instead of properly analyzing the packets. You'll stop the low-cost automated garbage attacks, but you won't stop a dedicated attacker, even if the attacker is in that country.
- AmericanChopper 6y ago
  You’re only considering one side of the costs. Obfuscation mechanisms also impose a cost on your legitimate users. There’s lots of reasons why you want your users to actually buy in to using your security controls, and annoying controls with highly questionable effectiveness is the best way to kill that buy in. Users will only tolerate so much burden from user facing controls, so you want to make sure all of the controls you impose upon them are actually useful. The other thing that’s harmful is relying on something to provide security, when it actually can’t. That’s actually going to have a negative impact on your threat model. People will say (they’re even saying it in this thread) that their port knocking or non-standard port usage has cut out the port scanning noise in their logs. But who cares? A properly secured ssh port isn’t going to be cracked by an automated scanning tool. But a poorly secured hidden one will be easily found and cracked by any motivated attacker. You have to implement the proper control anyway, and the obfuscation one ends up providing no benefit while simply annoying your users. Security by obscurity is dumb, it doesn’t provide any benefit. Security in depth doesn’t mean multiple layers of controls that don’t work add up to one that does. Obscurity is just a way of spending your scarce resources on controls that don’t work, and wastes your scarce command of your users attention on controls that don’t work. So in reality, they’re also always coming at the opportunity cost of controls that actually do.
- wglb 6y ago
  > but it raises their costs. I would ask by how much. Having to perform source audits on code with obfuscated variable names added almost no time to the task. Again, these methods work against not-so-determined attackers. If you as a defender have limited resources, where would you choose to spend it--on defending against unskilled attackers, or attackers that are more likely to cause you damage? >but when the costs to those actors exceed the loss you may experience. There are several problems with this logic. First, it kind of presumes that there is a symmetry in the costs for the attacker and defender. Wise defenders will use methods that have high leverage. Also, the attacker doesn't care at all about your costs. They care about what they can get from you--whether it is access to something that you aren't thinking of, or your crown jewels. Encrypting databases is sometimes required by compliance, but is no defense against a good attack.
historyremade 6y ago
And Asshole it take time to deobsufucate no matter how clever as you are
historyremade 6y ago
By your logic, We don't need borders at all.
umvi 6y ago
> Assume for every code obfuscator there's a deobfuscator or at least someone as clever as you out there. There is still some information lost in the process: - "let eigenvector_coefficient = 23" => "let x = 23" A de-obfuscator isn't going to be able to recover the valuable information contained in the original name. Will it stop a determined attacker? Maybe not, but it would surely slow them down as they now need to spend an order of magnitude longer trying to understand what the code is doing. > Randomizing variable names it just a nuisance, it won't stop any competent pen tester or attacker. Believe it or not, nuisances are enough to stop some people. A lot of would be attackers are just cruising for low hanging fruit. Remember, the goal is to "reduce risk" and not "stop any highly skilled targeted/tailored attack". Because let's face it, even if you are the greatest crypto wizard in the world, you will fall victim to a highly sophisticated attack tailored specifically to you.
- aeternum 6y ago
  It might make sense in some contexts, but code obfuscation is a great example of where software engineers think it provides security where it provides none. Developers often have some idealized notion that an attacker is going to need to piece their program logic back together and try to decode the purpose of each obfuscated variable in order to find a hardcoded password/value. In reality an attacker is just going to dump strings and try them all or simply set a breakpoint just before the important syscall and let your program do the work. Code obfuscation provides little to no value for these common methods, yet we cannot resist the urge to list it as a bullet point in security meetings, leading to a false sense of security.
  - saagarjha 6y ago
    Exactly. If you're running crypto and think getting rid of variable names is going to stop people; it's not. Any off-the-shelf algorithm is usually easy to recognize to an accomplished reverse engineer with a basic background of what kind of things they're looking for.
    - XMPPwocky 6y ago
typon 6y ago
> competent pen tester So it does eliminate incompetent ones? That's kind of the point of the article.
- marcosdumay 6y ago
  If you have any bit of real security, incompetent people wouldn't pose a risk. So, what's the gain?
drchopchop 6y ago
>Randomizing variable names it just a nuisance, it won't stop any competent pen tester or attacker. Sure it will. Imagine that your old, unpatched Wordpress admin is at /random-gobbledygook instead of /wp-admin. An attacker would have to try to hit random alphanumeric directories of your webserver over and over again, hoping that he stumbles across a specific thing that they can attack. This is completely impractical, unless they're somehow clued in that the URL exists. It's really about making life difficult for an attacker, so much so that they will simply give up, or find an easier target. That can be achieved by throwing up a series of difficult/obscure barriers, each which makes it less likely you'll be trivially penetrated.
- scarface74 6y ago
  One of the first widespread security vulnerabilities I had to deal with was this one: https://www.giac.org/paper/gcih/115/iis-unicode-exploit/101163 https://www.giac.org/paper/gcih/115/iis-unicode-exploit/1011... You could basically encode DOS commands in the URL bar for a site running IIS and it would run remotely. The automated attack basically replaced the index.html pages. But if you didn’t use the default pages. It didn’t have any effect.
- mncharity 6y ago
  I ran a world-writable off-the-shelf wiki for years. Trivially tweaked the edit url, visible on every page. But that was enough to break automated spam tooling defaults, so the spamming human might get to see a note, pointing out that robots.txt was blocking indexing, so there was really no reason to waste both our times. The dominant threat wasn't the spammer, but their dumb automation.
skipants 6y ago
> Assume for every code obfuscator there's a deobfuscator or at least someone as clever as you out there. Then it filters out people who are not using a deobfuscator or are less clever than I. > Randomizing variable names it just a nuisance, it won't stop any competent pen tester or attacker. Then it will stop incompetent pen testers. I don't see how your comment refutes the point made. The point is not that it makes your likelihood of attack zero, it just reduces the likelihood via adding more roadblocks.
outworlder 6y ago
> - Randomizing variable names it just a nuisance, it won't stop any competent pen tester or attacker. But it will stop incompetent attackers - of which there are many. In fact, they are the vast majority. None of those 'obscurity' techniques will stop a targeted attack. That's not their function. But each of them raises the bar. The more hoops, the better.
xt00 6y ago
Isn't there some model where the keys that you use to decrypt the database are acting something like one time codes, and you have to use particular credentials to access the key server? So the attacker would need to be able to stay in the network to be able to actually access the data -- they couldn't just download the entire database and crack it offline. I don't know how that actually is implemented, but just curious on that.. I also wonder how many people put things in their various systems that are obvious attacker trip-mines -- like having some fake button that says like "copy image of database to disk" or something that the actual internal employees are told to never click that button -- but maybe they have even some confluence page that talks about "how to download the database", but is actually a fake entry meant to trip up an attacker in case they get access to your confluence pages as well as your database.. so they click that button and the admins get alerted...
dublin 6y ago
Overloading names is a good code obfuscation strategy, but tricky and best done with code for obvious reasons (unless you like your regular code to present the challenges of BrainF). For instance, depending on your language, you may be able to have a variable, a function, an object, a pointer, a data structure, an index variable, etc. all called just "a". Making sense out of code obfuscated this way is really* hard for humans, but will compile or interpret just fine so long as your obfuscator obeys the rules of your language. (We started on this at one of my early startups nearly 20 years ago, but didn't get funded soon enough for protecting the IP in our unique JS to matter. It was unique enough that we actually applied for a patent on part of it - drawing a 16 trace live strip chart of data from network sources at better than 4-10 Hz per channel was really hard with the bowsers and computers of 2002!)
deeringc 6y ago
The database key should be generated per encrypted database and then stored using something like the OSX keychain. The OS enforces that only a given application can retrieve that key (via application code signing).

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.
- czzr 6y ago
  But it’s easier to find Arab women. Or an Irish girlfriend of an Arab man. Or two old Korean people. (All real examples)
  - jfk13 6y ago
    I'm pretty sure the potential recruitment pool of young Arab men is still many times greater than the pool of Irish girlfriends of Arab men. It's about improving the odds/reducing the exposure, not achieving some theoretical absolute perfection.
    - gowld 6y ago
      It's bad math. It doesn't matter if you have 1 arab man and 1 korean woman, or 1000 arab men and 1 korean woman. You only need 1. If you calculate the probabilities correctly, you get very different results.
  - thaumasiotes 6y ago
    No, obviously it's harder to find two old Korean people than one old Japanese person. Everything you've listed is hundreds, thousands, or millions of times more difficult than the young-Arab-man case. Suppose you take down a plane with a young Arab man, and then you want to take down a second plane. There is a neverending stream of similar men willing to do the job. If your strategy requires you to use elderly Korean couples, you're done after the first plane -- you'll never find a second one.
- Nasrudith 6y ago
  The point is that if you try to be a selfish bigotted dick and create profiling to shift the inconvenience of security delays onto the other you create a gaping hole for that shortcut - don't look the part and then do damage. It is a bad policy morally and practically meaning the only rational reason to support it is being an asshole who sees the harm as a good.
- bleepblorp 6y ago
  The problem with heavily focusing on Arabs while paying less attention to other threats is that Arab Islamist terrorists aren't the only problem aviation security needs to deal with. Focusing most of the security effort on Arabs is a good way to fight the war of 19 years ago, but it leaves the air travel system vulnerable to upstart terrorist movements that see the lack of universal security as an exploitable vulnerability. For example, there's nothing to say that America's right wing terrorist groups won't decide to switch from shootings and vehicle ramming attacks to attacks on air travel. The TSA ought to be prepared for this, or any other, emerging threat.
BurningFrog 6y ago
> You seem to be thinking in terms of security mechanisms either perfectly blocking attacks or being useless. Ours is an industry with a lot of people "on the spectrum". https://thesilentwaveblog.wordpress.com/2017/03/08/aspergers-autism-and-black-and-white-thinking/ https://thesilentwaveblog.wordpress.com/2017/03/08/aspergers...
cgriswald 6y ago
It's still bad security. Sure, it increases costs for a certain subset of attackers. Instead of sending easily found and trained young Arab men, they have to put more effort into recruitment. However, in return for that, they get far reduced scrutiny. Therein lies the problem. It is the real-world equivalent of dropping all packets from a country instead of properly analyzing the packets. You'll stop the low-cost automated garbage attacks, but you won't stop a dedicated attacker, even if the attacker is in that country.
AmericanChopper 6y ago
You’re only considering one side of the costs. Obfuscation mechanisms also impose a cost on your legitimate users. There’s lots of reasons why you want your users to actually buy in to using your security controls, and annoying controls with highly questionable effectiveness is the best way to kill that buy in. Users will only tolerate so much burden from user facing controls, so you want to make sure all of the controls you impose upon them are actually useful. The other thing that’s harmful is relying on something to provide security, when it actually can’t. That’s actually going to have a negative impact on your threat model. People will say (they’re even saying it in this thread) that their port knocking or non-standard port usage has cut out the port scanning noise in their logs. But who cares? A properly secured ssh port isn’t going to be cracked by an automated scanning tool. But a poorly secured hidden one will be easily found and cracked by any motivated attacker. You have to implement the proper control anyway, and the obfuscation one ends up providing no benefit while simply annoying your users. Security by obscurity is dumb, it doesn’t provide any benefit. Security in depth doesn’t mean multiple layers of controls that don’t work add up to one that does. Obscurity is just a way of spending your scarce resources on controls that don’t work, and wastes your scarce command of your users attention on controls that don’t work. So in reality, they’re also always coming at the opportunity cost of controls that actually do.
wglb 6y ago
> but it raises their costs. I would ask by how much. Having to perform source audits on code with obfuscated variable names added almost no time to the task. Again, these methods work against not-so-determined attackers. If you as a defender have limited resources, where would you choose to spend it--on defending against unskilled attackers, or attackers that are more likely to cause you damage? >but when the costs to those actors exceed the loss you may experience. There are several problems with this logic. First, it kind of presumes that there is a symmetry in the costs for the attacker and defender. Wise defenders will use methods that have high leverage. Also, the attacker doesn't care at all about your costs. They care about what they can get from you--whether it is access to something that you aren't thinking of, or your crown jewels. Encrypting databases is sometimes required by compliance, but is no defense against a good attack.

historyremade 6y ago

And Asshole it take time to deobsufucate no matter how clever as you are

historyremade 6y ago

By your logic, We don't need borders at all.

umvi 6y ago

> Assume for every code obfuscator there's a deobfuscator or at least someone as clever as you out there. There is still some information lost in the process: - "let eigenvector_coefficient = 23" => "let x = 23" A de-obfuscator isn't going to be able to recover the valuable information contained in the original name. Will it stop a determined attacker? Maybe not, but it would surely slow them down as they now need to spend an order of magnitude longer trying to understand what the code is doing. > Randomizing variable names it just a nuisance, it won't stop any competent pen tester or attacker. Believe it or not, nuisances are enough to stop some people. A lot of would be attackers are just cruising for low hanging fruit. Remember, the goal is to "reduce risk" and not "stop any highly skilled targeted/tailored attack". Because let's face it, even if you are the greatest crypto wizard in the world, you will fall victim to a highly sophisticated attack tailored specifically to you.

aeternum 6y ago
It might make sense in some contexts, but code obfuscation is a great example of where software engineers think it provides security where it provides none. Developers often have some idealized notion that an attacker is going to need to piece their program logic back together and try to decode the purpose of each obfuscated variable in order to find a hardcoded password/value. In reality an attacker is just going to dump strings and try them all or simply set a breakpoint just before the important syscall and let your program do the work. Code obfuscation provides little to no value for these common methods, yet we cannot resist the urge to list it as a bullet point in security meetings, leading to a false sense of security.
- saagarjha 6y ago
  Exactly. If you're running crypto and think getting rid of variable names is going to stop people; it's not. Any off-the-shelf algorithm is usually easy to recognize to an accomplished reverse engineer with a basic background of what kind of things they're looking for.
  - XMPPwocky 6y ago

typon 6y ago

> competent pen tester So it does eliminate incompetent ones? That's kind of the point of the article.

marcosdumay 6y ago
If you have any bit of real security, incompetent people wouldn't pose a risk. So, what's the gain?

drchopchop 6y ago

>Randomizing variable names it just a nuisance, it won't stop any competent pen tester or attacker. Sure it will. Imagine that your old, unpatched Wordpress admin is at /random-gobbledygook instead of /wp-admin. An attacker would have to try to hit random alphanumeric directories of your webserver over and over again, hoping that he stumbles across a specific thing that they can attack. This is completely impractical, unless they're somehow clued in that the URL exists. It's really about making life difficult for an attacker, so much so that they will simply give up, or find an easier target. That can be achieved by throwing up a series of difficult/obscure barriers, each which makes it less likely you'll be trivially penetrated.

scarface74 6y ago
One of the first widespread security vulnerabilities I had to deal with was this one: https://www.giac.org/paper/gcih/115/iis-unicode-exploit/101163 https://www.giac.org/paper/gcih/115/iis-unicode-exploit/1011... You could basically encode DOS commands in the URL bar for a site running IIS and it would run remotely. The automated attack basically replaced the index.html pages. But if you didn’t use the default pages. It didn’t have any effect.
mncharity 6y ago
I ran a world-writable off-the-shelf wiki for years. Trivially tweaked the edit url, visible on every page. But that was enough to break automated spam tooling defaults, so the spamming human might get to see a note, pointing out that robots.txt was blocking indexing, so there was really no reason to waste both our times. The dominant threat wasn't the spammer, but their dumb automation.

skipants 6y ago

> Assume for every code obfuscator there's a deobfuscator or at least someone as clever as you out there. Then it filters out people who are not using a deobfuscator or are less clever than I. > Randomizing variable names it just a nuisance, it won't stop any competent pen tester or attacker. Then it will stop incompetent pen testers. I don't see how your comment refutes the point made. The point is not that it makes your likelihood of attack zero, it just reduces the likelihood via adding more roadblocks.

outworlder 6y ago

> - Randomizing variable names it just a nuisance, it won't stop any competent pen tester or attacker. But it will stop incompetent attackers - of which there are many. In fact, they are the vast majority. None of those 'obscurity' techniques will stop a targeted attack. That's not their function. But each of them raises the bar. The more hoops, the better.

xt00 6y ago

Isn't there some model where the keys that you use to decrypt the database are acting something like one time codes, and you have to use particular credentials to access the key server? So the attacker would need to be able to stay in the network to be able to actually access the data -- they couldn't just download the entire database and crack it offline. I don't know how that actually is implemented, but just curious on that.. I also wonder how many people put things in their various systems that are obvious attacker trip-mines -- like having some fake button that says like "copy image of database to disk" or something that the actual internal employees are told to never click that button -- but maybe they have even some confluence page that talks about "how to download the database", but is actually a fake entry meant to trip up an attacker in case they get access to your confluence pages as well as your database.. so they click that button and the admins get alerted...

dublin 6y ago

Overloading names is a good code obfuscation strategy, but tricky and best done with code for obvious reasons (unless you like your regular code to present the challenges of BrainF). For instance, depending on your language, you may be able to have a variable, a function, an object, a pointer, a data structure, an index variable, etc. all called just "a". Making sense out of code obfuscated this way is really* hard for humans, but will compile or interpret just fine so long as your obfuscator obeys the rules of your language. (We started on this at one of my early startups nearly 20 years ago, but didn't get funded soon enough for protecting the IP in our unique JS to matter. It was unique enough that we actually applied for a patent on part of it - drawing a 16 trace live strip chart of data from network sources at better than 4-10 Hz per channel was really hard with the bowsers and computers of 2002!)

deeringc 6y ago

The database key should be generated per encrypted database and then stored using something like the OSX keychain. The OS enforces that only a given application can retrieve that key (via application code signing).