25 comments

[ 3.2 ms ] story [ 58.8 ms ] thread
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.

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.
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.
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 tom+ES85jFxz@rpi.edu as your address instead of tom@rpi.edu.

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.
I've been using this technique for 10+ years. Sadly it doesn't work with Gravatar because

   md5("comment+sitename1@mydomain.com") != md5("comment+sitename2@mydomain.com")
However, it is really interesting to see the amount of spam I get sent to certain 'snowflake' email addresses I have only ever used to submit a comment to top well known blogs. Shows how much database hacking for email harvest goes on.
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.

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.

(comment deleted)
Release a new API that uses symmetric encryption instead of a one way hash. Use however many rounds are necessary to prevent brute force attacks. Gravatar keeps a list of generated keys, but not who generated them. The API accepts a key ID and encrypted email. That makes the keys convenient to generate and change. Deprecate the old API and turn it off some day.

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.

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.
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)}"
If it wasn't that easy, I'd probably consider just doing something else. Maybe just have it use a stronger hashing algo?

  ...have it use a stronger hashing algo?
The strength of the hashing algorithm is ancillary to this vulnerability. The OP was able to resolve the emails because they had a predictable format.
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.

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.

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 :-)
but why md5 when there are better alternatives? not to speak about the issues with OP
because it's very simple for anyone to build an app that uses Gravatar since md5 is probably the most well-known hashing function.
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.
A commenting system that still shows user specific avatars next to anonymous comments? That sounds like a terrible implementation.