Microsoft, stop sending user identifiers in clear text
annoyedmicrosoftuser.blogspot.com
annoyedmicrosoftuser.blogspot.com
I guess (unless Tor is completely broken) that there would still be more legwork involved in associating traffic from the endpoint with its corresponding traffic into Tor, but even "user logs into that service through Tor" is still a pretty fertile datapoint. Obviously Microsoft would be able to see that pretty easily anyway, but why would they make it easy for others to see it too?
DNS lookups are routed through Tor just like HTTP/TCP traffic (in implementations that aren't broken).
But surely the point still stands? Even if you only see the DNS lookup as it emerges from the endpoint, you still know that User XYZ uses Tor to access Service ABC, correct?
Obviously, the enemy may know more about the owner of Microsoft account XYZ: for example, they may know the name you typed when registering it or, if you login to the same account from your home internet connection, they may know that it is the same person that had assigned IP I at time T and may thus know that it is the same person that the ISP who was assigned the IP address block containing IP I claimed presented ID stating he was Mr X to the ISP as part of subscribing to the ISP.
This means that between accessing the Microsoft account XYZ and doing other things that you don't want to be associated to the owner of Microsoft account XYZ, you should use the "New Identity" button in Tor Browser, or use a separate machine or Tor Browser instance. Of course you cannot know which services reveal your user id to your enemies, so you should always do that regardless of whether the service is known to send it in plain text or not.
I would have commented on your tinfoil hat, except for what Microsoft did to Skype post-acquisition:- Completely rewriting its protocol architecture from one which was P2P with end-to-end encryption and practically impossible to wiretap or monitor, to a centralized architecture (ostensibly for scalability reasons) which made it much more easier to wiretap or obtain metadata.
http://www.zdnet.com/article/skype-ditched-peer-to-peer-supe...
http://www.theguardian.com/world/2013/jul/11/microsoft-nsa-c...
Here's a choice quote from the above article.
"In July last year, nine months after Microsoft bought Skype, the NSA boasted that a new capability had tripled the amount of Skype video calls being collected through Prism;"
However this gels with their explanation that they have only centralized the call setup servers for reliability and voice/video traffic for mobile devices where P2P is not very feasible. On laptops and PCs, where P2P remains feasible, traffic is still routed directly been peers.
Now I haven't run the same experiment in the past year, but I hope somebody will, and that too at larger scale. Given this forum is "hacker" news, there is a distinct lack of technical investigation to verify technical claims, and a disturbing propensity to take tech media for its word, especially when biases are being confirmed.
Few people care about the contents of VOIP calls. The relationship maps you can generate from the metadata is far more useful.
Also, "reliability" doesn't make sense as a reason to centralize skype. Being very generous, it is a workaround for the problem of NAT removing the average user's ability to self-publish on the internet.
>Also, "reliability" doesn't make sense as a reason to centralize skype.
I've written a P2P app or two. The NAT issues that you handwave are a huge problem. It's not just the connectivity of nodes, it's the symmetry in which nodes are reachable. NAT and general internet weirdness make this a much harder problem than it needs to be. I had to do a significant re-architecting when I ran into these issues during internal testing, and I had less than two dozen users!
The next problem is latency. By the time you wait to discover a suitable supernode and for your "hello" message to reach your target peer, you will have already connected and started communicating with your peer if you use a centralized "registry" server.
This is compounded by churn. Even if there's a single intermediate hop in your routing, your chances of a successful message delivery drop drastically when a peer can leave anytime. Think about how you use your laptop and how long you keep it running and how abruptly you close it. The move towards laptops away from desktops means average node uptime is reducing sharply, without even considering the move to mobile.
This is further compounded by the need for presence for the case of Skype. You don't want to find a peer is unreachable after you start a call. This implies the need for a global state. But without central server, this can only be achieved with DHT, where the first two problems are even worse. Note the existing DHTs are all used for long running "sessions" where the session is the availability of a torrent. User presence is a lot more ephemeral.
And there's the original problem for P2P apps, of course: bootstrapping. Peers don't come online knowing all their other peers on the Internet. There has to be a way for them to discover each other, which, without Internet-wide multicast, means a central server. If you're going to have to solve this problem, you might as well solve the others.
There is actually a thread on p2p-hackers mailing list about this exact issue. Many experienced P2P devs agreed that whenever you can get away with a centralized solution, you should go for it. In this context, partially centralizing Skype as they did makes complete sense.
There may have been evil reasons for Skype's change. Or maybe, MS realised that needlessly taking customer resources to run the Skype network isn't suitable behavior?
You could still glean info from monitoring the network communication (although i personally haven't done anything).
Also if the leaked docs are to be believed, the fact that the agencies boasted a 3-fold increase in intercept-able traffic post-acquisition, then it is reasonable to assume that wiretapping was non-trivial before.
I would consider that as misuse of DNS. User id must be in request parameter or path, not in hostname.
It's nice to be able to force logoff everywhere.
However, in the case of a hack/theft, shouldn't changing your password also invalidate all login tokens? You'd be doing that anyways. Right? ;)
2. Not allowing to retrieve any information based on persistent identifier alone i.e. require authentication for all resources (unless all data under some resource was explicitly meant to be publicly available).
3. Optionally, try to get rid of any long-term persistent identifiers (of course, besides Microsoft account ID which is meant to be persistent), in favor of ephemeral ones that are reasonably short-lived and rotated frequently.
I would guess plenty of services include the username in some URLs.
Edit: of course the autor also stated that, but more as a side note. Leaking the CID would not be a problem if there wasn't any futher information to be gained.
https://www.eff.org/deeplinks/2013/12/nsa-turns-cookies-and-...
Anybody that is regularly putting a unique identifier in plaintext network traffic is harming their users, and that goes for Microsoft embedding CIDs in dommain names, Verizon with their X-UIDH vandalism, Google's 3rd-party tracking cookies, and the like similar.
Also, you will never win a war if you give up the fight. This battle is absolutely not "long lost". The only way that could be true is if you give up, thereby self-fulfilling the prediction.
But I have no confirmation that is possible or not. Just speculation.
This is blocked by uBlock but it is concerning.