De-Anonymizing Web Communities with Gravatar(rgov.org)
rgov.org
De-Anonymizing Web Communities with Gravatar
http://rgov.org/2010/11/27/gravatar/
4 comments
One of the best aspects of gravatar is that fact that it takes one line of code to implement:
"http://www.gravatar.com/avatar/#{MD5::md5(email.downcase)}"
...have it use a stronger hashing algo?
When I said 'stronger' what I really meant was 'one with a larger number of possible hashes', so it'd be harder to resolve them. Not that it'd stop it totally, because he still knows enough about the keyspace...
Then again, crypto is not my strong point, so I should probably stop talking.
Then again, crypto is not my strong point, so I should probably stop talking.
you still have the problem that the thumbnail stays the same. if you change the url you could just hash the thumbnail binary content... pixel colors or whatever you want to use. its still no help to jzst change the user id.
Not really. The people you are de-anonymising are those who are not using gravatar, so whilst they all have different MD5's for their email addresses at the moment, they all have the same placeholder image.
There was a post here a while back by someone who did the same thing with the Stackoverflow data dump. I think he was able to recover about 10% of users' emails from a vastly larger search space.
Moral of the story: simply hashing emails is not enough if you're going to display them publicly. It's trivial to use a salt and prevent such an attack.
Moral of the story: simply hashing emails is not enough if you're going to display them publicly. It's trivial to use a salt and prevent such an attack.
I believe the mechanics of Gravatar make salting impossible, though. The whole system works because there's a single hash for any given author email address.
Yep. The salt would have to public, which would defeat the purpose.
However, a user can protect herself by "salting" her own email with an address tag. For example, provide [email protected] as your address instead of [email protected].
However, a user can protect herself by "salting" her own email with an address tag. For example, provide [email protected] as your address instead of [email protected].
A few years ago, I tried using email tags with many online services so that I could use the tags for email filters. Most form validations rejected my email tags because they considered "+" to be an invalid character in email addresses.
Using your own domain with different local names lets you get around that. But requires a domain.
No, it doesn't. The forms rejected the email as a valid one, probably because they just use a regex like /w+@w+\.\w\w\w/, because they're dumb. It does fix a stupid provider who refuses to accept such an email, though.
HTML5 'email' fields should hopefully mean this'll be fixed in approximately 30 years.
HTML5 'email' fields should hopefully mean this'll be fixed in approximately 30 years.
I've been using this technique for 10+ years. Sadly it doesn't work with Gravatar because
md5("[email protected]") != md5("[email protected]")
I ended up using that very same technique and ran into the exact same problem. My solution to this has been to sign up for one gravatar, but after that I simply stopped caring about the service.
If whatever service I am using can't work without gravatar, they will have to see a generic picture.
If whatever service I am using can't work without gravatar, they will have to see a generic picture.
Indeed. A work-around would be to fetch the gravatars in the backend and serve them yourself, that way you will not have to expose the hash.
[deleted]
A commenting system that still shows user specific avatars next to anonymous comments? That sounds like a terrible implementation.
thats funny... i still have an email from probably 2006 telling gravatar that a single md5 for each user (email address) is just idiotic for many reasons. possible collisions, anonymity, and so on.
they replied back within an hour that im wrong, that there is no risk of collision because every email is unique because its the primary key (dah?) and they will continue using it.
made me laugh. since then i ignored the service as they are obvious just a bunch of script kiddies.
to be honest - the only obsticle for such a service is server redundancy. nothing special about it. besides that its now a obsolete service since every major site offers oauth.
made me laugh. since then i ignored the service as they are obvious just a bunch of script kiddies.
to be honest - the only obsticle for such a service is server redundancy. nothing special about it. besides that its now a obsolete service since every major site offers oauth.
Given your statement on MD5 collisions, it's not entirely clear to me who's the script kiddie here.
how many users do they want to store in their db with a unique md5 string? its just a really bad bet.
thats a script kiddie for me, assuming that a hash never collides within a database and than chosing md5. there are better, even very simple, ways to store hashes without forcing collisions.
There are an awful lot of md5 digests - so, even with an insane number of users it is highly unlikely they would have a collision. Hell; at work we generate insane numbers of hashes and it took us quite a while, and a large dataset to find a collision :-)
Nevermind the fact that if the gods did cause such a collision to occur it wouldn't exactly be the end of the world. (And the accessibility of md5 more than makes up for this consequence.)
Agreed -- It was also my first thought when I read about the service. It's easy to make a database of md5 hashes and link the comments to that, no reason to even decode them. There goes anonymity. This article is only new in that it is (afaik) the first person that actually bothers to test it out and publicize about it.
I think that works, but I try not to think about crypto at three in the morning, or at all really.
EDIT: Also, a consumer site could implement this themselves with a simple proxy server. They could even open up the service to other sites.