I've never heard of this either. Tor and VPNs are meant to protect you against this sort of stuff and I doubt even the CIA can find this info if you're smart enough (though I believe VPNs can accidentally leak your IP in some ways). What you might be thinking of is browser fingerprinting though which can be very useful to catch alts and just using a proxy won't help you (and I think this should be on the new forum). You might use a different IP for your accounts but you almost certainly won't be using a unique PC or browser for each of your alts and accounts could be collated and searched by them and cross referenced with other data etc.
A year or two ago I was researching fingerprinting techniques that'd work against pretty much anyone with JavaScript enabled, and I found several promising leads on that front. But then it occurred to me that I don't really want bitcointalk.org to be known as the #1 forum on the leading edge of de-anonymization technology, so I stopped pursuing it seriously...
IMO The most interesting idea I had was that you could probably fingerprint based on latency even via Tor using long-term data collection. A Tor connection looks like:
User --- ISP --- Guard --- Mid --- Exit --- Server
A B C D E
The latencies of connections A, B, and A+B are good fingerprint values; ISPs should have statistically-significant differences in latency to the server if the latency can be determined with enough accuracy. Latency will also uniquely vary over time; ie. latency will go up slightly when your ISP is busy, the schedule of which will be distinguishing. Additionally, Tor selects a handful of guards when it starts and then uses only those, so if you can figure out the complete list of guards, this fingerprints a long-term Tor session across sites and logins.
Connection E can be directly measured, as can A+B+C+D+E if JS is enabled. That alone may be enough for fingerprinting A+B if you collect data over a long period of time. You'd roughly model the random latency distribution of C+D across the entire Tor network (which is not that large and is predictable in several non-obvious ways); then since you have a whole bunch of A+B+C+D+E and E measurements, you can get a good idea of A+B.
You might be able to do even better by taking into account these facts: Tor changes to a new random Mid and Exit every 10 minutes, but it only affects new TCP connections. So you can usually control the timing exactly by opening TCP connections via JS. And it chooses a random Guard only from a small set, with that set being chosen only at the start of the long-term Tor session. So you might be able to get the guard identities (or a fingerprint of the guard identities) and info about the latencies by collecting latency data every 10 minutes via JS and looking at the clusters formed by the handful of different guards.
On a MITM attack, you can do even better. If you control both Mid and the server, then you know C, D, E, and the Guard identity. A+B is then trivial to calculate. There are only about 6000 Tor nodes, so if you only run one Tor non-exit node, you have something like a 1/6000 chance every 10 minutes to fingerprint the user this way. (That's a really rough estimate; the odds are better because you can exploit Tor behaviors like its IP-space diversity requirements, but worse because selection is not random, and is also based on things like seniority and bandwidth.) Additionally, if a user happens to choose your node as a guard when he starts his Tor session (so a smallish chance ~
per day rather than per 10 minutes), then you can completely deanonymize him (ie. get his IP address) when he visits the site; this is a well-known attack which the NSA & friends are probably doing all the time on a very large scale.