Live data from Hacker News

Fun with your friend's Facebook and Tinder sessions

robertheaton.com

11–20 of 59 posts

Re: Fun with your friend's Facebook and Tinder sessions

#12
post #6
post #4

I'm trying to think about whether there's a way for Facebook and/or Tinder to mitigate this attack without degrading user experience. Because the auth token used is from the response to the last request ever made from Steve's computer, having a changing auth token on each request wouldn't help in this scenario. Restricting an auth token to an IP address wouldn't work since both users are presumably behind the same NA…

I wonder if it's feasible to reference the TLS/SSL session against the session cookie? While the HTTPS session itself is probably transient, you can tell something is up if the same session cookie is being used with two different HTTPS keys.

You're describing the concept behind channel bound cookies. https://tools.ietf.org/html/rfc5929

As far as I know, it's not supported by any current browser (I welcome feedback to the contrary) but is included in SChannel. Given that we've only recently (arguably) gotten away from SSLv3, I don't have high hopes that it will be viable to require channel binding in the very near term.

Re: Fun with your friend's Facebook and Tinder sessions

#17
post #4

I'm trying to think about whether there's a way for Facebook and/or Tinder to mitigate this attack without degrading user experience. Because the auth token used is from the response to the last request ever made from Steve's computer, having a changing auth token on each request wouldn't help in this scenario. Restricting an auth token to an IP address wouldn't work since both users are presumably behind the same NA…

If each computer had a unique hardware private key, that could stop it. But I'm not sure that they do? (Or even if some do, can HTML5 access that somehow?)

Couldn't the author just copy Steve's private key to his computer then?

Re: Fun with your friend's Facebook and Tinder sessions

#18
post #4

I'm trying to think about whether there's a way for Facebook and/or Tinder to mitigate this attack without degrading user experience. Because the auth token used is from the response to the last request ever made from Steve's computer, having a changing auth token on each request wouldn't help in this scenario. Restricting an auth token to an IP address wouldn't work since both users are presumably behind the same NA…

It seems like the most reasonable mitigation would be to disallow Burp Suite from working at all by using SSL cert pinning. (I'm actually pretty surprised that they don't do this already -- I know that Google pins certs for their own apps in Chrome.)

This, of course, would not completely stop the issue. But, it would make the author's job that much harder, since he'd have to emulate the Tinder protocol without the assistance of the Tinder app -- or would have to hack the Tinder app (and run it on a jailbroken device) to disable the cert pinning.

Re: Fun with your friend's Facebook and Tinder sessions

#19

Wonder if the match referenced at the end is true. Fun read.

Monica and Steve have two kids. As they weren't referred to as "twins", I'm going to assume that they're not. Assuming Monica got pregnant on the first date and again immediately after she gave birth (which is perfectly possible, but an unusual choice and very strenuous on the mother) that puts the episode 18 months ago, no later than July 2013.

Considering that Tinder was launched around August 2012 and assuming Monica and Steve are modern and responsible people (ie. are careful not to rush into the big responsibility of parenthood), I'd say it's highly unlikely.

Re: Fun with your friend's Facebook and Tinder sessions

#20
post #4

I'm trying to think about whether there's a way for Facebook and/or Tinder to mitigate this attack without degrading user experience. Because the auth token used is from the response to the last request ever made from Steve's computer, having a changing auth token on each request wouldn't help in this scenario. Restricting an auth token to an IP address wouldn't work since both users are presumably behind the same NA…

If each computer had a unique hardware private key, that could stop it. But I'm not sure that they do? (Or even if some do, can HTML5 access that somehow?)

Can't you just sniff for a browser fingerprint and if too many characteristics have altered end the session?
Post reply on HN