TL;DR Lock your machine before leaving the room.
Fun with your friend's Facebook and Tinder sessions
31–40 of 59 posts
Re: Fun with your friend's Facebook and Tinder sessions
#32Re: Fun with your friend's Facebook and Tinder sessions
#33This is extremely well written and engaging. Any other blogs like this one?
Re: Fun with your friend's Facebook and Tinder sessions
#34I'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 as…
Cert pinning doesn't help when someone installs their own certificate authority. It stops other CAs that came bundled with the browser from working, but if it stopped self-installed certificates from working it never would have gotten off the ground because many organizations demand the ability to use their own certificates for signing things.
Re: Fun with your friend's Facebook and Tinder sessions
#35This is extremely well written and engaging. Any other blogs like this one?
Thanks :). To plug myself, I quite like http://robertheaton.com/2014/01/06/how-to-win-at-dinner-part...
http://robertheaton.com/2013/07/22/how-to-hack-a-rails-app-u...
Re: Fun with your friend's Facebook and Tinder sessions
#36Earlier quoted context omitted.
http://pilif.github.io/2008/05/why-is-nobody-using-ssl-clien...
Another reason: SSL certificates cost money. StartSSL has some free option, though.
Client certificates are generated by the user's machine and signed using your server's private key. The user's client presents them to your server to prove that the client is who they said they were when you signed their certificate. These certificates don't cost anything, besides some CPU cycles on both sides of the process.
The kind of server SSL certificates that cost money are generated by you and signed by a CA that most users' browsers will trust. Your server presents them to the client to state to the client that the server belongs to the domain it says it belongs to.
Most CAs will charge you money for the service of signing those certificates, but that process has nothing to do with the lack of adoption of client SSL certificates.
The parent article does a good job describing why client certificates aren't used more often: the UX doesn't make sense to users and there's not a user-friendly way to protect them with a second factor (the way you can encrypt your SSH keys using a passphrase or authentication device).
Re: Fun with your friend's Facebook and Tinder sessions
#37This probably wouldnt work given that I am assuming its the external IP and a user agent is pretty easy to copy/clone. Seems like there should be another value mixed in that might be hard to figure out for a third party behind the same NAT.
Re: Fun with your friend's Facebook and Tinder sessions
#38I'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?)
HTML5 can't access TPM directly, but in ChromeOS, you can create or import a client certificate as a 'hardware-backed' certificate, which is then wrapped by the device's TPM.
At this point (if properly configured) an attacker can't exfiltrate client certificates from the device even with root-level access to the machine. Plus, in theory, extracting key material from the TPM should be made difficult by its manufacturer by means of various physical protections.
Obviously this is a very niche edge-case, but it is possible :)
Re: Fun with your friend's Facebook and Tinder sessions
#39This is extremely well written and engaging. Any other blogs like this one?
Thanks :). To plug myself, I quite like http://robertheaton.com/2014/01/06/how-to-win-at-dinner-part...
Re: Fun with your friend's Facebook and Tinder sessions
#40Earlier quoted context omitted.
Thanks :). To plug myself, I quite like http://robertheaton.com/2014/01/06/how-to-win-at-dinner-part...
Shouldn't the brown-eyed people kill themselves on day 101? Or are they supposed to reason that they, and they alone might have some other coloured eyes.