Jesper's Blog



More Security Myths

  • Comments 7
  • Likes
About a year ago Steve Riley and I built a presentation based on a set of security myths we put into the book. It was one of the most popular presentations we have ever made, and we kept coming up with more myths every time we delivered it, or talked to people, or sat long enough on an airplane to think a bit. In this month's issue of TechNet Magazine we wrote up another batch of myths. There is currently no presentation scheduled on these (rejected at TechEd US) but if you really think we should build one, let us know.
  • Go for it

  • Ya, would love to see it...

    Enjoyed the one's in the book

  • Please do!

  • PingBack from

  • I liked the article in the Technet Magazine but I would like to suggest that more appropriate titles be chosen for the myths because in some cases they do not match the scope and context of the analysis.

    For instance, the last myth: "Host-Based Firewalls Must Filter Outbound Traffic to be Safe". Your analysis seems correct from a home user point of view. But how about corporate environments? In those environments most users wouldn't be given the option to choose what outbound connections to allow or deny. This would be applied by security administrators enforcing security policies.

    Also, you state: "If instead you do the right things to ensure that your computers remain free of infection, outbound filtering does nothing for you other than, perhaps, to give you a false sense of being more secure."

    May I ask you just how should this be done with home users? If we agree that home users are not technically capable (let alone willing) to allow/deny outbound connections I wouldn't even think of them defining a white list in a security control that prevents execution of unauthorized code (I totally agree with you, as you state in the "Let's Block Bad Stuff. " myth, that white lists are the way to go, but this may still not apply to all environments).

    Also, you state: "Outbound filtering is too easy to bypass, too. No self-respecting worm these days will try to communicate by opening its own socket in the stack." No security control is perfect, and the fact that there is a way around it is not proof that it is useless (Same unicorn analogy would apply here, there are still thousands of malware that do establish direct connections).

    Also, there might be some other cases where outbound traffic is needed to enforce corporate policy (not necessarily to stop malware). For example, you might have a bunch of authorized applications for execution in your corporate environment for local use, but for which yo don't allow certain types of outbound network traffic per policy (e.g. you authorized execution of an IM application for internal communication only, and so you only allow it to connect to an internal corporate server, filtering any other unauthorized connection from this application).

    You can always argue that having physical access to the workstations the users can get around this or any other security measure and so they are useless, but at least this gives some points for evidence collection in cases of policy violation. How would you suggest to solve this problem in corporate environments without outbound traffic filtering? Simply filtering at network level in the perimeter firewall? (Remember you get less visibility from what is happening as you move away from the resources you are watching/protecting).

    Anyway, there is plenty to discuss around the scope and context of the analysis of some of these myths but that won't prevent me from congratulating you for doing an excellent job ;-).

    Kind regards,

    Omar Herrera

  • Not sure if it's one you've considered, but I personally believe that "passwords should be case sensitive" is a security myth.

    In the typical 6-character password, case sensitivity adds an extra character's worth of randomness.

    It also adds a significant overhead in support costs. "hd74nfr" and "hD74Nf" are roughly equivalent in their difficulty to crack, but the former is far easier to remember for most people, which reduces "post-it on monitor" security risks, reduces "forgotten password" support calls, and reduces "caps lock key on" suport calls.

    A very good example is the "human verification" graphics one sees a lot lately. Because of the comment spam problem, blogs aned forums often require users to type in a sequence of characters from a graphic, to validate that they have eyes. Making those characters case sensitive instead of one character longer causes more support issues without increasing security or reducing spamming.

    The argument some make (that case insensitive passwords are more vulnerable to dictionary attack) is valid, but imho poor. If you have allowed a 6 character password with a dictionary word, you've lost anyway. Yes you've lost in two days instead of an hour, but you've still lost.

    What about passphrases? These are prettymuch ONLY susceptible to dictionary attack, so case sensitivity should be that much more important... right? Wrong. Case sensitivity gives a false sense of security.

    Take an 80-character passphrase. Case sensitivity appears to give 80 bits extra "randomness". In truth, it's somewhat less, since not all characters will be in the range a-z: some will be spaces, numbers, etc.

    But in practice, only a couple of the characters will be uppercase. The ones that are easiest to remember. So, one or two characters, at the start or end of words (most often, start of first word or start of a proper noun). A 16-word 80 character phrase therefore has one or two uppercase letters in only 32 characters, so 5 to 10 bits extra randomness.

    You can get that just by adding two characters onto the end of the password, and the password becomes much, much easier to remember.

    So, yeah, case sensitivity in passwords gives the false sense of greater security than it really grants, and makes for more support calls.

  • Interesting points Dewi. I think it goes to show that innovative thinking is not gone, and we still have a lot to learn.

Your comment has been posted.   Close
Leave a Comment