- From: Tim <tim-projects@sentinelchicken.org>
- Date: Tue, 7 Jun 2011 16:41:31 -0700
- To: Nico Williams <nico@cryptonector.com>
- Cc: "apps-discuss\@ietf\.org" <apps-discuss@ietf.org>, "http-state\@ietf\.org" <http-state@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>, OAuth WG <oauth@ietf.org>
> > A passive attacker can sniff your cookie and thus hijack your session. All > > you need to accomplish that attack is connect to any open wifi network and > > use Firesheep. It's a good bit harder to be an active attacker, even on an > > open wireless network. > > Yes, but only for resources that you've already stated you don't care about. > > If you cared about those resources you'd protect more of the request > _and_ response, or you'd use TLS. But you don't want to protect the > response and you don't want to use TLS and you don't even want to > protect the request body. What you're proposing adds a very marginal > degree of security that will be trivial to defeat on open wifi > (particularly once the toolset for doing it gets published). > > Are we serious about security? Or it this just for show? > > Or am I missing something? I have to agree with Nico here. In almost all cases I assert that, on typical modern networks: let P = difficulty of passive attack let M = difficulty of active (man-in-the-middle) attack O(P) = O(M) . This isn't to say the "real world" difficulty of an active attack is just as easy, but it is within a constant factor. If someone has published a tool that conducts MitM attacks for the specific protocol you're dealing with, the difference in difficulty clearly becomes marginal. Consider the complexity of the attacks implemented by sslstrip and yet the relative ease with which you can use it to MitM all SSL connections. I didn't bring this up before because I didn't understand any of the context behind the MAC proposal, but I will now, at risk of sounding ignorant: What is the MAC Authentication proposal intended to accomplish, in a security sense, above and beyond HTTP Digest? Yes, the HTTP Digest spec is, shall we say, a little rough around the edges, but would it make more sense to simply *fix* the minor problems with it and slightly extend it to integrate with OAuth? Note that it already does allow for arbitrary encrypted blob values to be attached to the digest... Ignoring the integration details for a minute though, how does MAC improve on Digest from a security persepctive? tim
Received on Tuesday, 7 June 2011 23:41:56 UTC