4 ms·

Say it with me, "Security through obscurity is no security at all". Surely you'd know this working for Mozilla :) Probably due to business reasons in that it i

by SEJeff 10y ago

Say it with me, "Security through obscurity is no security at all". Surely you'd know this working for Mozilla :) Probably due to business reasons in that it isn't meant to be a general purpose fuzzer and is likely tied to internal google infra.

felipemnoa 10y ago
Not sure why you are getting down-voted. "Security through obscurity is no security at all" is a very true statement. It is the reason why the code for AES is known to everybody.
- dgfgfdagasdfgfa 10y ago
  Except it's not true. Obscurity still has cost to decipher, and the cost may be the ends you're looking for. Not all security-oriented goals are make-or-break. Hell, if you're talking about a time scale of hours (not uncommon with 0-days) even using a trivial cypher could slow people (attempting to understand (and then fix) your vulnerability) down for long enough to "get away" with the data/transfer/rootkit/whatever. Obfuscation has its role; it's to retard understanding, not to prevent understanding.
  - kajecounterhack 10y ago
    Obfuscation as a way to prevent copyright violation makes sense. Obfuscation as a way to purposefully hide security holes is terrible. "Security through obscurity is not real security" is true, and has nothing to do with obfuscation in general. It has more to do with auditability. Real security has a quantifiable difficulty to break through. Security through obscurity means the quantity of effort to needed to break through is an unknown. Example: We do know what it takes to break bcrypt. So if you've implemented bcrypt for security, great. Not obscure, but known to be safe. We don't know how long it'll take random black hat to find out you're storing passwords in plaintext but hiding the fact cleverly. If you release your source code auditors / community can see quickly that "oh storing plaintext passwords is a bad idea" and fix the bug. If you don't you might not know you're vulnerable and the obscurity will ultimately cost you for your ineptitude.
    - londons_explore 10y ago
      Hashing algorithms have historically been mostly obscurity. It turns out we're really good at coming up with functions we think are one way and later find aren't. MD4 and SHA0 were both once believed to be good...
      - kajecounterhack 10y ago
        I don't think it's so much about obscurity as it is about an arms race. Hashing algorithms are constantly being measured up against new exploit methods, faster cracking speeds, etc. It's a feature that we found collisions and other problems, not a bug. A bug would be us continuing to use those algorithms without being able to mitigate their flaws. The fact that we can find out that these functions are not as good as we hope and improve upon them is argument against obscurity. You can't do those things unless knowledge of these functions is common knowledge.
    - dgfgfdagasdfgfa 10y ago
      I guess you can call certain forms of protections people use "real" security versus "unreal" security, but I don't see your demarcation in practice. > Obfuscation as a way to purposefully hide security holes is terrible. I misspoke; I meant to say 'obscurity', which is the relevant concept in this thread, and there are most certainly reasons to have security through obscurity: once you've found a flaw, you must fix it before its obscurity vanishes. This is certainly relevant it the development of fuzzers where novel approaches could reveal 0-days.
nickpsecurity 10y ago
Say it with me: "Obfuscation on top of solid, security practices provably reduces risk against talented hackers." It's why the Skype attack took forever. They spent so long on reverse engineering where open software with obvious weaknesses would've cracked almost instantly. Now, put that concept in for runtime protections, NIDS, recovery mechanisms, etc. Hacker has much more work to do that increases odds of discovery during failures. Obfuscation was also critical to spies helping their nations win many wars. There's so many ways for well-funded, smart attackers to beat you when they know your whole playbook. When they don't, you can last a while. If it changes a lot, you might last a lot longer. If not well-funded or maximizing ROI (most malware/hackers), they might move on to other targets that aren't as hard.
- zenlikethat 10y ago
  > They spent so long on reverse engineering where open software with obvious weaknesses would've cracked almost instantly Not necessarily true. If the software is available to everyone white hats are much more likely to find bugs and help fix them. They might actually have skin in the game alongside you. White hats won't bother with proprietary software at all, and baddies sure aren't going to turn in their exploits, they'll just sit on them or sell them. If you're being targeted by sophisticated nation-state attackers keeping the code private isn't going to help you. These are people who make worms like Stuxnet, MITM major Internet services, and pop government employee Gmail accounts for their full time job. You're just reciting the same tired old rhetoric that security through obscurity is a valid defense mechanism. It's just not.
  - nickpsecurity 10y ago
    " If the software is available to everyone white hats are much more likely to find bugs and help fix them. They might actually have skin in the game alongside you." The state of most FOSS security says otherwise. A better assumption is virtually nobody will review the code for security unless you get lucky. If they do, they won't review much of it. Additionally, unless its design is rigorous, the new features will often add vulnerabilities faster than casual reviewers will spot and fix them. This situation is best for the malware authors. "White hats won't bother with proprietary software at all" You mean there's never been a DEFCON or Black Hat conference on vulnerabilities found in proprietary systems + responsible disclosure following? I swore I saw a few. Regardless, proprietary software should be designed with good QA plus pentesting contracts. Those relying on white hats to dig through their slop are focusing on extra profit instead of security. ;) White hats will also definitely improve proprietary software for small or no payment if they can build a name finding flaws in it. Some even do it on their own for same reason. This effect goes up if the proprietary software is known for good quality where finding a bug is more bragworthy. "You're just reciting the same tired old rhetoric that security through obscurity is a valid defense mechanism. It's just not." You're misstating my points to create a strawman easier to knock down. I said attacking unknowns takes more effort than attacking knowns. I also said, if monitoring is employed, the odd behavior that comes with exploration increases odds alarms will be set off. These are both provably true. That means obfuscation provably can benefit security. Whether it will varies on case-by-case basis per obfuscation, protected system, and use case. Feel free to look at my obfuscated options in recent reply to SEJeff to tell me how you'd smash them more easily than a regular box running Linux and OpenSSL whose source & configs are openly published to allegedly benefit their security.
cpeterso 10y ago
There's a difference between the system being open and the test tools being open. Mozilla has open sourced most of its fuzzers [1], but only after they are no longer finding existing bugs. The fuzzers are then used to prevent regressions. [1] https://github.com/MozillaSecurity https://github.com/MozillaSecurity

by SEJeff 10y ago

felipemnoa 10y ago

Not sure why you are getting down-voted. "Security through obscurity is no security at all" is a very true statement. It is the reason why the code for AES is known to everybody.

dgfgfdagasdfgfa 10y ago
Except it's not true. Obscurity still has cost to decipher, and the cost may be the ends you're looking for. Not all security-oriented goals are make-or-break. Hell, if you're talking about a time scale of hours (not uncommon with 0-days) even using a trivial cypher could slow people (attempting to understand (and then fix) your vulnerability) down for long enough to "get away" with the data/transfer/rootkit/whatever. Obfuscation has its role; it's to retard understanding, not to prevent understanding.
- kajecounterhack 10y ago
  Obfuscation as a way to prevent copyright violation makes sense. Obfuscation as a way to purposefully hide security holes is terrible. "Security through obscurity is not real security" is true, and has nothing to do with obfuscation in general. It has more to do with auditability. Real security has a quantifiable difficulty to break through. Security through obscurity means the quantity of effort to needed to break through is an unknown. Example: We do know what it takes to break bcrypt. So if you've implemented bcrypt for security, great. Not obscure, but known to be safe. We don't know how long it'll take random black hat to find out you're storing passwords in plaintext but hiding the fact cleverly. If you release your source code auditors / community can see quickly that "oh storing plaintext passwords is a bad idea" and fix the bug. If you don't you might not know you're vulnerable and the obscurity will ultimately cost you for your ineptitude.
  - londons_explore 10y ago
    Hashing algorithms have historically been mostly obscurity. It turns out we're really good at coming up with functions we think are one way and later find aren't. MD4 and SHA0 were both once believed to be good...
    - kajecounterhack 10y ago
      I don't think it's so much about obscurity as it is about an arms race. Hashing algorithms are constantly being measured up against new exploit methods, faster cracking speeds, etc. It's a feature that we found collisions and other problems, not a bug. A bug would be us continuing to use those algorithms without being able to mitigate their flaws. The fact that we can find out that these functions are not as good as we hope and improve upon them is argument against obscurity. You can't do those things unless knowledge of these functions is common knowledge.
  - dgfgfdagasdfgfa 10y ago
    I guess you can call certain forms of protections people use "real" security versus "unreal" security, but I don't see your demarcation in practice. > Obfuscation as a way to purposefully hide security holes is terrible. I misspoke; I meant to say 'obscurity', which is the relevant concept in this thread, and there are most certainly reasons to have security through obscurity: once you've found a flaw, you must fix it before its obscurity vanishes. This is certainly relevant it the development of fuzzers where novel approaches could reveal 0-days.

nickpsecurity 10y ago

Say it with me: "Obfuscation on top of solid, security practices provably reduces risk against talented hackers." It's why the Skype attack took forever. They spent so long on reverse engineering where open software with obvious weaknesses would've cracked almost instantly. Now, put that concept in for runtime protections, NIDS, recovery mechanisms, etc. Hacker has much more work to do that increases odds of discovery during failures. Obfuscation was also critical to spies helping their nations win many wars. There's so many ways for well-funded, smart attackers to beat you when they know your whole playbook. When they don't, you can last a while. If it changes a lot, you might last a lot longer. If not well-funded or maximizing ROI (most malware/hackers), they might move on to other targets that aren't as hard.

zenlikethat 10y ago
> They spent so long on reverse engineering where open software with obvious weaknesses would've cracked almost instantly Not necessarily true. If the software is available to everyone white hats are much more likely to find bugs and help fix them. They might actually have skin in the game alongside you. White hats won't bother with proprietary software at all, and baddies sure aren't going to turn in their exploits, they'll just sit on them or sell them. If you're being targeted by sophisticated nation-state attackers keeping the code private isn't going to help you. These are people who make worms like Stuxnet, MITM major Internet services, and pop government employee Gmail accounts for their full time job. You're just reciting the same tired old rhetoric that security through obscurity is a valid defense mechanism. It's just not.
- nickpsecurity 10y ago
  " If the software is available to everyone white hats are much more likely to find bugs and help fix them. They might actually have skin in the game alongside you." The state of most FOSS security says otherwise. A better assumption is virtually nobody will review the code for security unless you get lucky. If they do, they won't review much of it. Additionally, unless its design is rigorous, the new features will often add vulnerabilities faster than casual reviewers will spot and fix them. This situation is best for the malware authors. "White hats won't bother with proprietary software at all" You mean there's never been a DEFCON or Black Hat conference on vulnerabilities found in proprietary systems + responsible disclosure following? I swore I saw a few. Regardless, proprietary software should be designed with good QA plus pentesting contracts. Those relying on white hats to dig through their slop are focusing on extra profit instead of security. ;) White hats will also definitely improve proprietary software for small or no payment if they can build a name finding flaws in it. Some even do it on their own for same reason. This effect goes up if the proprietary software is known for good quality where finding a bug is more bragworthy. "You're just reciting the same tired old rhetoric that security through obscurity is a valid defense mechanism. It's just not." You're misstating my points to create a strawman easier to knock down. I said attacking unknowns takes more effort than attacking knowns. I also said, if monitoring is employed, the odd behavior that comes with exploration increases odds alarms will be set off. These are both provably true. That means obfuscation provably can benefit security. Whether it will varies on case-by-case basis per obfuscation, protected system, and use case. Feel free to look at my obfuscated options in recent reply to SEJeff to tell me how you'd smash them more easily than a regular box running Linux and OpenSSL whose source & configs are openly published to allegedly benefit their security.

cpeterso 10y ago

There's a difference between the system being open and the test tools being open. Mozilla has open sourced most of its fuzzers [1], but only after they are no longer finding existing bugs. The fuzzers are then used to prevent regressions. [1] https://github.com/MozillaSecurity https://github.com/MozillaSecurity