cases where multiple apps/servers are authorized with the same credential/token but aren't or shouldn't be trusted not to replay the token against other services
-
-
It's a real attack for sure, but.... Is token binding the correct solution? It really feels like "no" to me, but maybe there's a convincing argument I haven't heard.
-
The right solution is not using wildcard-scoped cookies and instead doing SSO-like cross-subdomain auth only in one direction. But this is heavy retrofitting. I think the idea is that token binding provides a lazy fix...
-
But my impression is that token binding is more about building/fitting into a Windows-AD-like ecosystem and being a nuisance against exercising control over your own auth tokens than about improving security.
End of conversation
New conversation -
-
-
I asked Ryan about it, subdomain takeover has the same problem, you could just serve some js that does your attack instead of steal cookie then attack from your machine. I think this is another "why not just use the vector you used to get the cookie in the first place"?
-
fair point but driving a whole attack from js served from the subdomain is more difficult than doing it directly with the cookie. Raising the bar rather than complete prevention. The same is true for XSS and the httponly flag on cookies but it still exists and gets used.
-
That's true, but you have to admit if httponly was as invasive a change as token binding, it probably wouldn't exist?
-
your point is taken. But given that it's optional and only used when negotiated by both parties in the TLS handshake, it doesn't seem that invasive to me.
-
The argument I heard was that because this will break Antivirus (I'm the last person who would complain about that), they will just start being more invasive with hooks and patching. That's pretty convincing argument, bluecoat aren't just going to close down the business

-
I took it the other way, IMO, someone at MSFT mentioned it as another way to get endpoint TLS MitM further untenable
-
Right, but is that good or bad? They can switch to hooking and patching instead - they're going to do that, because they're business depends on that and they already need Admin to install cert. So did we make things better or worse?
-
If we could prevent endpoint mitm, you know I would be all for this, but aren't we just forcing them to be more sketchy?
- 6 more replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.