OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
From: Dan Kaminsky (dan_at_doxpara.com)
Date: Mon Oct 14 2002 - 13:40:16 CDT

  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

    >
    >
    >> * Automatically providing tamper control (eg. message digests) to
    >> data that are not supposed to be tampered with.
    >>
    >>
    >
    >And you verify that the digest isn't changed *how*? (Hint - how do you
    >keep your attacker from handing you a piece of data along with a digest that
    >matches?
    >
    >
    For remotely computed data / hashes, you can't -- thus the folly of
    trusting MD5 hashes on critical files downloaded off of untrusted
    servers. If somebody can modify the tarball, they can probably modify
    the hash too.

    But for cookie-style fields that are reflected back to stateful systems,
    you can certainly provide tamper control using the HMAC (Hashed Message
    Authentication) construction. Essentially, the HMAC adds a symmetric
    secret to the resulting hash -- mere possession of data becomes
    insufficient to compute a new hash; one must possess the secret as well.
     So people can either pass back the valid data, or nothing at all. Elegant.

    Encrypting your state and embedding it into a cookie(or URL, hideously
    enough) is actually a great way to trade computation for bandwidth; at
    the cost of a bit of bandwidth, your applications can be completely
    stateless. As Caezar pointed out a few days ago to me, a brilliant
    variant of this for systems with *huge* amounts of state is simply to
    pass to the clients a small HMAC'd handle to some state cached on a
    central state-cache, which then upon receipt of a validated handle sends
    to the stateless backend web request plus the relatively large amount of
    data the server needed to process the request. The load balanced server
    remains stateless, the central state cache does nothing but hash,
    validate, store, and forward (all trivial ops), and the wire doesn't get
    flooded with garbage we didn't want to keep around.

    As for a global site scripting solution...hmmm, I can imagine one tag
    I'd like in web browsers: "After this point, no scripting allowed, DOM
    is dead, go away." Think about it -- it's just priv dropping.

    --Dan
    www.doxpara.com