Just a Spoonful of Obscurity Makes the DefCon Level Go down!
Rich, It feels heretical, but I can agree that obscurity can provide some security. The problem comes when people count on secrecy as their only or primary security. Jim: āOh, we donāt have to encrypt passwords. Sniffing is hard!ā Bob: āHey, thank you for those credit card numbers!ā Jim: āWhat?ā Bob: āHa ha, my friend Joe got a job at your ISP about a year ago, and started looking for goodies.ā Vendor: āNobody will ever bother looking in the MySQL DB for the passwords.ā Cracker: ā0WNED! Thank you, and letās see how many of your users use the same passwords for their electronic banking!ā Vendor: āBut nobody else has access to the server!ā Cracker: āBut I found a hole in your PHP bulletin board. Game over, man!ā GeniousDood: āI just invented a perfect encryption algorithm! Nobody will ever break it!ā Skeptic: āHow do you know?ā GeniousDood: āI checked. Itās unbeatable.ā Skeptic: āThanks, but Iāll stick with something at least one disinterested person has confidence in ā preferably Schneier.ā IT Droid: āCheck out our new office webcam! Itās at http://camera.example.com ā Paranoid: āWhatās the password?ā IT Droid: āPassword? No-oneās ever going to find it.ā Paranoid: āGoogle did.ā I can accept that obscurity makes cracking attempts more difficult. This additional difficulty in breaking into a system might be enough to discourage attackers. Remember ā you donāt have to outrun the bear, just your slowest friend! Also, if you have a short period before the fix is available, during which there is a gaping hole in your defenses, obviously itās going to be easier for people to exploit if they have full details, so itās hard to see how full disclosure could ever look like a good thing to a commercial vendor. On the other hand, open source projects are more likely to benefit from full disclosure, as it substantially widens the pool of people who can provide a patch, and open source communities attract people who want to deal with security problems themselves (certainly many more Linux & FreeBSD admins want to patch Sendmail or BIND, than Windows users want to patch IE or their DLLs). Security companies are like this too ā they want enough info to protect their customers. Restricted access information is fine, as long as the security companies are on the list ā such access becomes another asset for the security vendor. But back to obscurity: it can be used as one component in a layered defense, or it can be used as the only defense. One is useful, the other is dumb. Alternatively, obscurity can be used as a temporary barrier: āIt will take them a few days to figure out how to break IE, so weāll get a chance to distribute the patch before they can start attacking our users.ā This is a very different proposition than āpermanent obscurityā as (hopefully part of) a defense. The problem, of course, is that not everybody gets the patch immediately. Some people donāt because they donāt know about it, others because they have important systems which they canāt change ā perhaps because the risk of breakage is unacceptable, or the āfixā is unacceptable. This may last a few days, or forever. Some people donāt have the bandwidth (full dot upgrades for Mac OS, and Service Packs for Windows, are large downloads), and may or may not get the upgrades another way. Some just donāt want to be bothered, and believe theyāre invulnerable. Others cannot afford the upgrades. So those people may have no defense aside from obscurity, and they are vulnerable; on the Windows side, they tend to get hacked. Obscurity is just not a good long-term defense, since most secrets leak eventually, and patches can be reverse-engineered to find the hole. This leads into the issue of vendors who donāt patch in a timely manner, but I have to leave something for Rich to rant aboutā¦ Share: