Follow up to my Gmail third-party access post

My previous post about a possible intrusion by non-authorized parties on my Gmail account has received a lot of attention on Hacker News, and was even linked to from LifeHacker. There were a lot of questions, concerns, and critics that quickly surfaced, and in this post I’ll address most of them. Given the volume of heterogeneous points at hand, I will present this post in an informal FAQ manner.

Image © Sooperkuh.

Did the IP 173.203.211.51 belong to a malicious user?

No. It belongs to etacts (a social plugin for Gmail), who has confirmed that the IP is one of theirs. They were authorized by me to access my inbox via IMAP for “analytics” purposes.

Why did you originally think that it could have been a malicious user?

A reverse-lookup of the IP address did not show an etacts hostname, as it had in the past, but instead a generic Slicehost server. A search quickly revealed that other people had complained online about the same IP accessing their inbox, too. This was a red flag, but contrary to some peoples’ interpretation, I didn’t freak out about it.

Oh come on, you freaked out, admit it.

Not quite, but I was reasonably concerned.

Were you a bit paranoid about it?

No.

But they are after you.

Really? Who?

Everyone. Everyone is after you.

Oh.

What about Zoho Discussions and Trendly?

Zoho and Trendly are the only two services I granted access to my Google account. In practice, this means I simply logged in using Google as a single sign-on, instead of creating a new account for each of those services. This type of OAuth-like authentication does not provide third party companies with your password, as explained by Google in this help page.

Contrary to my initial post, Zoho and Trendly could not have been the culprits. etacts on the other hand required a username and password in order to work. This is likely to change when Google introduces OAuth for IMAP.

Shouldn’t you — or anyone — know better than give your password to third parties?

Generally speaking, yes. You shouldn’t share your password with anybody. In this case, I assessed the risks and benefits of doing so, and opted for the convenience of the service, feeling that etacts was/is trustworthy.

etacts is a YCombinator-funded startup and its entire business model depends, for the time being, on people trusting them with their login credentials. Until Google launches OAuth for IMAP, there isn’t really a way around this scenario, if you want to use such a service.

I fully understand that some people may feel that it’s never wise to trust a third party regardless of the benefits involved into the equation.

Shouldn’t etacts attempt to prevent such false alarms?

Yes, and the team at etacts was very proactive in terms of proposing possible solutions to prevent those users who trust them from needlessly worrying when an usual IP is recorded. Publishing a list of their IPs and ensuring that reverse lookups of such IPs lead to actual etacts hostnames, were two of the potential solutions that they suggested.

So was it much ado about nothing?

Yes and no. Without a doubt, the event that led me to write the article was the false alarm, but the real motivation behind it was to bring Google’s access log to people’s attention, regardless of whether they shared their password or not. In fact, following my post there were reports of people who’d discovered there had been illicit accesses to their accounts.

I also published the article to share some suggestions on what to do when dealing with an intrusion.

Why did you say that you changed the password on a wired computer?

As I mention in the post, it was unlikely that someone managed to sniff my password by whatever means. Occam’s Razor did point towards the service I’d given my password to, which I made clear in my initial post.

I happened to have a newly formatted Linux desktop, so I used that one. It didn’t take any extra effort on my part. In my case, using that or using my laptop would have been no different (in fact, I used my WiFi throughout the whole ordeal, and I haven’t bothered to change my WiFi password either).

Since those were general suggestions in a checklist of sort, it didn’t hurt to include it for people who may have had their password sniffed (even though such scenario would require further action).

You don’t need DBAN to remove possible keyloggers

That’s true, you don’t. I’d been planning to do a clean install on my MacBook Pro for a long time, so I thought I’d take the opportunity and go ahead with it now. As well, formatting one’s hard drive to remove keyloggers is still a valid suggestion for those who did have their password keylogged.

You don’t need DBAN for a new installation either

These days it’s rather rare that I do a brand new installation, so when I do, I like to start with a clean slate. Booting with DBAN and running a quick erase to zero in every bit is not an overly lengthy process. It’s an unnecessary step, that is unless you have unicorn riding midget pr0n to hide.

Do you have unicorn pr0n to hide?

Only a few gigabytes. 😛

Is there anything else you’d like to add?

One thing I forgot to mention in my previous post is that, after changing your password, you may want to remove the app authorization from your list of authorized third parties for your Google Account.

BTW, what’s up with the server dying on us?

When I setup my server (a long time ago), NGINX wasn’t as established as it is today. So I went with Apache which is a slow and heavy beast. If you add that WordPress is resource hungry as well, you get a fine tuned 1GB of RAM slice that struggled with several thousand visitors in the span of a few hours. An strace of the Apache processes revealed that despite APC and the WordPress SuperCache plugin, PHP was still hogging resources like doing so is going out of style. (Despite my server issues more than 20,000 visitors managed to read the article from my old server.)

I have now moved this blog to a 4GB, 2 CPUs server in the cloud, using NGINX as a web server. I will slowly port my other blogs as well as I migrate away from Slicehost. This setup should be able to handle much heavier loads (at least in theory). If you notice any problems, please don’t hesitate to let me know. (I officially declare my current deployment as an alpha “release”).

That should wrap things up in regards to this Gmail investigation, folks. Time to move on. 🙂