[wp-trac] [WordPress Trac] #14682: Privacy leakage: gravatars leak identity information

[WordPress Trac]

#14682: Privacy leakage: gravatars leak identity information
-----------------------------+------------------------------
 Reporter:  jmdh             |       Owner:  (none)
     Type:  defect (bug)     |      Status:  reopened
 Priority:  normal           |   Milestone:  Awaiting Review
Component:  Privacy          |     Version:  3.0
 Severity:  normal           |  Resolution:
 Keywords:  privacy-roadmap  |     Focuses:
-----------------------------+------------------------------

Comment (by pputzer):

 Replying to [comment:54 Denis-de-Bernardy]:
 > Replying to [comment:45 pputzer]:
 > > Ways to fix this without replacing Gravatar with another user avatar
 system:
 > > * Cache the Gravatar response and serve the images from the local
 server.
 >
 > This won't solve or prevent anything. You can still scrape WordPress
 sites and get the Gravatar ID.

 It does solve the issue of site visitors being (potentially) tracked by
 Automattic. It's a different issue than the identity leakage, but a
 privacy issue nonetheless.

 > > * This also improves performance (at least on HTTP/2), because no
 other connection needs to be opened.
 >
 > But this won't solve the privacy problem.

 By itself, of course not. That's why I said multiple steps were needed.

 > > * The public URLs of the cached images should use a more secure
 algorithm than MD5 (like SHA256) and a site-specific salt.
 >
 > In spirit you are correct but the suggestion is not. SHA is designed to
 be fast. You want a slow algorithm. One that is adaptive to boot (which is
 to say, tunable so that you can make it arbitrarily slow by changing a
 parameter). So what you really want is something more like bcrypt or
 whatever else is used for password hashing nowadays. As to a site-wide
 salt, you're much better off with a per user per site salt.

 You are right these measures would make brute-forcing the email address
 from the public hash more difficult. Using `bcrypt()` might be feasible
 for this specific application (and please note that `sha256()` was only an
 example). I see some real-world impediments to implementing per-user salts
 (mainly related to the number of DB requests necessary for commenting on
 high-traffic sites), but that suggestion can certainly be explored.

 > For the note, I checked the plugin that got linked, and the only
 conclusion I picked up from scanning through the core file was that it was
 doing (bad) security through obscurity. sha256 with a salt-wide salt is
 *not* adequate.

 I'm not sure how you arrive at "security through obscurity". It prevents
 privacy leakage that is ridiculously easy to exploit on a large-scale
 basis across the whole internet. Is it providing perfect security (or
 treating the email address like a password)? No, but that was never the
 point. (And, since it is open source, you are welcome to
 [https://github.com/mundschenk-at/avatar-privacy provide a pull request].)

 > Also, you don't even need to brute force the thing. If users
 consistently fill in their image then an image search will let you track
 them down on every site they're using irrespective of the hashing method
 used by site A or B.

 Sure. But that is their choice (as opposed to the current WordPress Core
 implementation which leaks everyones MD5 hash, even for people who do not
 use Gravatar at all.

 > > Doing this will leave only the lesser issue of always disclosing the
 hashed email address to Gravatar.com, possibly without their consent
 (especially if they don't even have a Gravatar account). Fixing this as
 well requires the addition of a checkbox, and an alternate way to create
 non-static default avatars. (Not technically hard, because all the dynamic
 default images available in Gravatar were once standalone WordPress
 plugins.)
 >
 > There remains the issue of Gravatar being used wholesale in forum
 software, gmail plugins, and what have you. The truth of the matter is
 that it's used everywhere, and not necessarily in a WP context. So fixing
 this in WP only is merely applying a bandaid.

 True, but WordPress is a big chunk of the web and applying "a bandaid"
 here removes those sites from the equation, which is still much better
 than doing nothing at al.

 > The actual issue, and the only sensible fix, is that the Gravatar ID
 generation code should be changed on the Gravatar website. Anything short
 of that and you'll still end up with opportunities to track users online.
 You can obfuscate things with some salting or some algorithm change but
 you cannot prevent it. And as already noted, even with perfectly adequate
 hashing on Gravatar's end, Google image search can potentially spoil the
 party.

 For those people who choose to use Gravatars, yes. But the issue described
 in this ticket affects a lot more people than those. That's why I disagree
 that we should all wait for Automattic/Gravatar to change their API (which
 obviously will not happen).

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/14682#comment:56>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform