Re: [apps-discuss] [OAUTH-WG] [http-state] HTTP MAC Authentication Scheme

[Tim <[e-mail]>]

Hi Eran,

> ... Until everyone deploys TLS, including such non-TLS bits in a TLS
> page cause the browser to show a broken TLS state in the address bar.
> For most web users, that's more of a red flag (valid TLS but with some
> resources loaded without TLS) than no TLS at all. 

And in fact, in any modern browser, this situation is rightfully
called out as an insecure deployment.  Many one of those non-TLS
resources you refer to could be modified by an attacker to inject
malicious script and therefore hijack sessions.


> The reality is that
> it is really hard to deploy TLS applications today without having
> issues with at least one vendor (especially when that vendor is an ad
> network you rely on for your profits).

Agreed.  It is a typical "no one can do it because no one else is
doing it" situation.


> Yes, adding MAC to cookies without TLS
> does not provide anywhere near the protection of TLS, but it is better
> than nothing, when TLS is not available.

To Nico's point, I'm not entirely sure about that.  If something like
MAC caught on, where would people deploy it?  They deploy it to
protect credentials over non-TLS connections, right?  So it might be
used as yet another excuse not to use TLS, even though it doesn't
provide the kind of protection that most users would expect.

In modern browsers, MAC would do nothing to stop someone from
injecting script into a response which initiates arbitrary requests on
behalf of a user.  A browser would have no idea that the script was
malicious, so it would happily sign requests as if they were
user-initiated.  To the point: session hijacking isn't just about
stealing and reusing a session token.

I see no problem trying to provide something to help protect user
credentials through hard-to-crack hashes and the like, since those are
often used in more than one place, but I see no point in trying to
provide one-way integrity protection.


thanks,
tim