Microsoft, stop sending user identifiers in clear text(annoyedmicrosoftuser.blogspot.com)
annoyedmicrosoftuser.blogspot.com
Microsoft, stop sending user identifiers in clear text
https://annoyedmicrosoftuser.blogspot.com/2015/10/microsoft-stop-sending-user-identifiers.html
10 comments
Let's not forget the whole Skype thing where knowing a user's ID is enough to edit any of their messages.
If you can look up skype Id by CID then this also opens your IP up to discovery. Which is a really big deal for people who stream (like my little brother).
But I have no confirmation that is possible or not. Just speculation.
But I have no confirmation that is possible or not. Just speculation.
As far as I know, this used to be a big problem in the Starcraft 2 pro gamer community, before everyone switched to naming their account "||||||||" or some such. (They would get DDOSed a lot.)
Everyone seems to talk about what MS should do, and why it's bad. But I wonder why the people working on these systems do not think or feel the same, and want to fight internally to fix it etc.
While you're at it Microsoft, please also give a way for users to remotely log out all active sessions on other computers and devices.
It's a terrible hack, but changing your Skype password via their website does log you out of all active sessions within a 2-5 minute timeframe. A friends Skype got "hacked" via a third party botting a message to all of his contacts, and as soon as I changed the password the spam stopped and soon after his local client logged out.
It's not a hack... this is exactly what is guaranteed for OAuth2 servers that follow spec to deauthorize all tokens.
What would you want this feature for?
Security? Forget to log off somewhere, cell phone gets stolen, account gets hacked...
It's nice to be able to force logoff everywhere.
It's nice to be able to force logoff everywhere.
It's nice being able to invalidate tokens on demand.
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? ;)
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? ;)
How should Microsoft resolve this? Not using CIDs at all?
1. Not using any persistent identifiers when they're transferred as plain text.
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.
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.
Not include them in the (sub)domain name?
So it's fine to use them in the query string?
The profile picture URL looks like “https://cid-___.users.storage.live.com/___”. Both the host part and the path part contain your CID. The CID in the host name really doesn’t have an effect (from the client’s perspective); you could use, for example, “cid-0000000000000000.users.storage.live.com” instead, or really just “storage.live.com”.
Isn't the real point that one should not be able to obtain that much information simply by knowing some user id or user name?
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.
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.
It is well known that unique identifiers are used to identify general internet traffic as the host moves to different IPs. This works even when the intended meaning of that identifier isn't known.
https://www.eff.org/deeplinks/2013/12/nsa-turns-cookies-and-...
https://www.eff.org/deeplinks/2013/12/nsa-turns-cookies-and-...
Fair argument that every unique id or name makes you trackable, but that is a much bigger (and IMHO long lost) battle on so many fronts, and it does not seem very fair to single out Microsoft here. And I don't think that is the motivation of the author either.
I'm absolutely not singling out Microsoft, and I'm not sure why you would think I was.
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.
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.
I noticed that my bank (Halifax) sends a long numerical code to webtrends for every page that I visit. The code that it sends seems to be unique for each session.
This is blocked by uBlock but it is concerning.
This is blocked by uBlock but it is concerning.
Different problem. That session identifier is probably unique to each session. The complaint here is that the CID is always the same for you, and can be used to look up more information (your profile)
Intriguing that this renders Tor essentially transparent in some contexts - that could almost seem by design.
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?
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?
>Intriguing that this renders Tor essentially transparent in some contexts - that could almost seem by design.
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;"
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;"
When I heard about the "re-centralization" of Skype, I ran an experiment. I set up calls with a couple of people in various locations and monitored my network connections (on OSX I used nettop). Voice and video traffic is still direct P2P. It was the same when I tried it again last year. Not that I did not investigate messaging connections, nor group video chats, not mobile usage, all scenarios where a centralized service may be more useful.
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.
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.
Are you suggesting that the ability to log metadata ("call setup") isn't important?
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.
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.
Sure metadata could be important, but I'd argue it's only useful in identifying who some agency might want to wiretap next. Without the actual content of the calls you don't know if somebody is talking to a collaborator or ordering in.
>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.
>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.
I Agree. Using metadata like call duration and start time can learn a lot of patterns that relates to either single person or a group of people's activity, therefore to id a someone/group even some of them aren't connected.
Impossible to wiretap or monitor? The Skype client was an obfuscated blob! There's no reason to believe it wasn't trivial for Skype to wiretap individuals. After all, authentication authority was centralized. Here's a simple test: is there a password recovery feature you can do via email or so?
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?
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?
>There's no reason to believe it wasn't trivial for Skype to wiretap individuals.
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.
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.
Why?
DNS lookups are routed through Tor just like HTTP/TCP traffic (in implementations that aren't broken).
DNS lookups are routed through Tor just like HTTP/TCP traffic (in implementations that aren't broken).
Ah, OK, I see. My understanding of Tor is far from complete, I should point out - it's not my area of expertise at all, and I'm just an interested observer!
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?
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?
The enemy sees that someone using Tor exit node E is accessing Microsoft using user id XYZ and they can infer that other traffic coming out of exit node E is also more likely than average to be from the owner of Microsoft account XYZ.
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.
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.
Given that Microsoft recentralized Skype in order to make it suitably wiretappable, we can hazard a guess at the reason.
Another concern: modern HTTPS use SNI standard and those who sniff your traffic, can extract the hostname from this traffic, because it's not encrypted yet. So DNS sniffing is not necessary, if I understand everything correctly.
I would consider that as misuse of DNS. User id must be in request parameter or path, not in hostname.
I would consider that as misuse of DNS. User id must be in request parameter or path, not in hostname.