6 ms·

It's good someone finally took the effort to write this up. When discussing some security by obscurity measure, other people almost invariably come up with the

• mikeash 10y ago
  What should be said is that security only through obscurity is bad. Security through obscurity is fine as long as you're not relying on it. At the worst, it doesn't hurt, just don't count on it to save your bacon.
  • dllthomas 10y ago
    > At the worst, it doesn't hurt At the worst, it imposes cost for little benefit.
    • sametmax 10y ago
      Obscurity almost always drive down script kiddies and generic bots away so the cost is amortized by the ressource you save and can focus on real threats.
      • AstralStorm 10y ago
        Or instead assume that your untested defences are working. Or in case of an obscure algorithm, assume it is good, because it had not been challenged.
        • sametmax 10y ago
          You will be tested and challenged. Just by a few competent people instead of a lot of noise. Besides, you can always have a honeypot with no obscure defense for a quick beta test if you need to. You'll have your flies quickly.
      • dllthomas 10y ago
        I did not imply that this was every case, or most cases. Parent said "worst case" - you have to be mindful of the cost you are imposing.
  • mfoy_ 10y ago
    That's exactly what the article is about.
  • ethbro 10y ago
    Exactly. Maybe a better way to look at its benefits is by cracking "security" into two components: scalability resistance and penetration resistance. Scalability resistance is the probability of a given vulnerability being successful against your configuration. Penetration resistance is the probability of your configuration being penetrated by an attacker focusing on it. Scalability is a valid security threat as it defines the vulnerability time window due to scarce attacker resources (attack attempts/time unit). Yes, it does and should fail catastrophically -- either the attack is not applicable to your config or it has been adapted and is. But just because plate armor had gaps didn't mean it was a stupid idea...
  • wepple 10y ago
    My biggest concern with security through obscurity is that it begins to be relied upon as a significant defensive mechanism. the incredible rate at which I see "but we have X" as a reason not to do good security is depressing.
    • mikeash 10y ago
      I totally agree with that. If you do this kind of thing, you have to be absolutely sure that it's never used as an excuse for not having actual security.
    • PeterisP 10y ago
      Just came in from grading a bunch of student-made systems. Several of them were proud of having their passwords secured in the database - by storing unsalted SHA1 or MD5 hashes. It's like going through a checklist of desired features, finding "security" on it and doing any single half-assed thing to check that box.
  • ademarre 10y ago
    > At the worst, it doesn't hurt I do agree with the article, but at its worst, obscurity can hurt. Obscurity can add complexity, and it's said that "complexity is the enemy of security". For example, sysadmins and maintainers could lose track of which layers are security and which are obscurity. In turn, this leads to decisions that compromise security because the maintainers overvalued the obscurity layers.
    • zanny 10y ago
      Not just added complexity, but added sense of false security. To be in a situation where you consider obscurity even a cursory part of your infrastructure is the moment you are relying on it by the nature of considering it even a fraction of total security. It is only reasonable to consider when its both insignificant in the total security stem and you have the willpower of a monk to resist ever considering it valuable.
    • jrochkind1 10y ago
      Yep, complexity, the false sense of security you get from an inflated judgement of what it gives you, and the 'opportunity cost' of time you spent devising, implementing, and dealing with it instead of some actual secure protection.
  • Natsu 10y ago
    It's more like the parts that have to be secret should be small and easily changed (passwords, keys, etc.) rather than your protocols (which are going to be very hard to change). There's no harm in a layer of obscurity over a secure system, but there's a social problem where it's more often used to obscure the workings of insecure systems than anything else. So all things being equal, one would prefer the cipher that's been well-studied by academics without being broken vs. the mystery cipher that claims to use all the most secure cryptographic constructs without giving anyone the details.
  • taneq 10y ago
    I'd take that a step further and say "defense not in depth is bad." Don't rely on any single method (mathematical, steganographic, misdirection, anything) if you want to be really secure.
• dllthomas 10y ago
  > For example, with most webservers you can pretty safely restrict access to a file by giving it a filename containing some key that cannot realistically be guessed. What I dislike most about that is that it's using traditionally non-key material as the key. Systems you're interacting with will probably treat that non-key material as not-a-key.
• eximius 10y ago
  Reminds me of the Slack attachments vuln a while back. IIRC, the data was public under some hash which is (realistically) impossible to guess. Except it wasn't for Reasons (tm), which made it bad.
• Esau 10y ago
  Obscurity is a useful layer but any well designed security system should work without it.
• mc32 10y ago
  Google anti SEO gaming has a lot of "security" through obscurity aspects to it, so, it's not as though the technique doesn't have real world valid examples of usefulness.
  • seanwilson 10y ago
    That's a good point. If they were open on how they measure page rank though, it would force them to more rapidly improve their algorithm. Right now, it seems people slowly figure out how to game it and Google have to change the rules again (e.g. hidden content, follow/nofollow links, guest blogging).
    • mc32 10y ago
      If they showed their hand, it'd just become a race to utter chaos. People would use the recipe for lousy sites. And then Google would have to redefine things over and over and over (this is allowable and that's not, and that's no longer allowable, except like this and that, except when this... This slows down the evolution rate significantly. And gives them plausible deniability.
      • seanwilson 10y ago
        Spam filters and anti-virus vendors seem to cope OK with having their algorithms understood though. It's always going to be an arms race but I see your point that using obscurity slows down the need to refine earlier. It'll be interesting to see what the final stages of the algorithm is as it converges on a proper definition of what relevant content means.
• Natsu 10y ago
  Yes, there always has to be some separation between your secrets (keys, passwords, etc.) and the non-secret parts (methods, protocols, etc.). The point of avoiding security by obscurity was that people were always tempted to make the methods, protocols, etc. secret, rather than a few small, easily-changed bits like passwords. Because you can't very well go around reprogramming entire systems, this means that the security fails in a very bad way when compromised as compared to other systems where you just reset the passwords/keys/etc.
  • jrochkind1 10y ago
    That's a very good point, well-stated, thanks!
• onion2k 10y ago
  For example, with most webservers you can pretty safely restrict access to a file by giving it a filename containing some key that cannot realistically be guessed. While that might feel like your security is an unguessable filename, the actual security you're relying on is the server not listing what's in a directory - which is reliant on every service on the machine that has file system level access to list a directory being secure. If an attacker gets access to any of them then they can get to your file. In other words, while the key is not public per se, it's very easily attacked through unrelated services. That is a problem.
  • SideburnsOfDoom 10y ago
    Like with the ssh example, the vast majority of attacks (I mean in terms of sheer numbers) are dumb, automated and done in bulk. e.g. Like just requesting the file "admin.php" on any website. Like trying to login with user "admin" and common passwords. If you don't have these files/logins then from a theoretical point of view of securing "every service on the machine" you haven't done anything; but as the 18,000 : 5 ratio in the article shows, you are in fact safer by halting the vast majority of naive attacks at that layer. And at a fairly low cost.
  • xg15 10y ago
    Add to that other systems which treat URLs as data with little security value - e.g. proxies or browsers that record visites URLs and may allow other people to reconstruct the filename.
• Illniyar 10y ago
  "someone without the key cannot access the file, and thus it shouldn't be called security by obscurity; the method is public, the key is not." It's not a key, just like a username is not a password, it's an identifier, and as such cannot be replaced. If you are ever going to share the url with anyone, they'll have to be notified manually when the url changes, and they can't share the url anywhere for fear that it'll be found out by bad actors. Compared to a an authentication scheme that every user has it's own credentials to remember and the identifier can be freely shared without worrying that unauthorized individuals can access it.
  • Confiks 10y ago
    The key can in fact be changed, in exactly the way you are describing. That the key can not be easily changed doesn't make it a non-key.
• jrochkind1 10y ago
  > with most webservers you can pretty safely restrict access to a file by giving it a filename containing some key that cannot realistically be guessed In my experience (yes, I've actually experienced this, multiple times), it almost always ends up indexed by google anyway, if it's on the public web. I guess a robots.txt can go far with regard to google specifically. And I guess that is essentially what Dropbox 'private links' (without password protection you get with a paid account) are, sure. And they seem to work... okay. But I sure wouldn't rely on anything particularly sensitive remaining private in a dropbox unsecured private link.