Hacker News Reader

Comment by robg | Hacker News Reader

Why not just a canary that a (unknown) IP has logged into the account? Gmail displays the logged in IPs. How hard would it be to grab that info into similar notifications? Add to that reverse look ups and you could get a IP and location. Train the system through use and you'll quickly get a white list.

I'd pay for that service.

View on HN

I think that's a good idea, but I didn't realize (at the time I created my canary mail) that it would be possible for me to write a Google Gadget inside Gmail that would do this sort of thing. It turns out that it would be possible to have a Gadget that reports the IP address when the UI is loaded and from that an interesting service could be built. From there I could probably do similar work for other online services.

I can imagine paying for a 'cloud watch' service that keeps an eye on all my online accounts and tells me if something odd is happening.

The problem is, once such an online service is well known, the hackers could just blacklist the host name(s) to the service so no alerting messages are sent. I think this is something that would have to live on the actual Gmail servers so it is not detectable from the client-side.

The problem is, once such an online service is well known, the hackers could just blacklist the host name(s) to the service so no alerting messages are sent.

Agreed, this is another problem. However, I think that it also depends on who you think might be targeting you. I know that a few years ago, plenty of everyday non-technical folks "hacked" their ex-girlfriend or boyfriends' accounts by doing a password reset with known details.

If the aim is to get notified of similar issues (e.g. my home laptop accessing during office hours), such a service could have merit.

The other catch with the ex-girlfriend/boyfriend is that they are not really after bank details so the Barclay's email won't interest them as it would the professional criminal... The problem with the canary is that it is trying to tailor a trap to someone without knowing much about them.

Which is another reason why the IP-based approach works better.

The IP-based approach seems flawed from my pov as someone who travels often. I'm always checking in from various IP addresses. Even locals who like to log in from the nearest cafe would get false positives, while the canary approach is more targeted.

You would get a false positive just after logging in from an unknown IP, but you would also know that it was due to your own actions (and could therefore ignore it).

What about the attacker who compromises your home computer and then is using it remotely while you are not home?

An IP based check won't help you there. This canary would.

If he's cautious enough to do two-factor auth, he probably doesn't leave his accounts logged in. Plus you have a whole lot of other problems if someone owns your personal machine.

If he's cautious enough to do two-factor auth, he probably doesn't leave his accounts logged in.

Suppose he uses http://googleblog.blogspot.com/2011/02/advanced-sign-in-secu... and has it remember the second authentication for 30 days (available from a checkbox). Then someone who has compromised his machine and has installed a keylogger can find it password, and log back in as him from that machine when he is not there. Two-factor has not saved you. Nor has the IP check.

And yes, you're right. If someone owns your personal machine you have a whole lot of other problems. This fact makes discovering that someone owns your machine more important, not less.

Facebook could do a facial recognition match to see if you match your profile picture ...

Wouldn't work. A hacker could just hold a picture of you up to the camera.

Or replay a generated video feed of a picture of you, saves the arm muscles and printer ink you see.

Because if you have a smartphone that you use to access your email then you'll be getting notifications non stop. That is, unless you want to whitelist every single IP address your carrier would use.

I think that's where the reverse look ups to location becomes important. The chance that a hacker would be in the same physical location seems small.

I fear your assumption might be wrong. It's much easier to steal someone's password when they're in the area than from afar. A bit of clever packet sniffing, session hijacking, DNS fun, or even some plain old binoculars are MUCH more effective than trying to guess someone's password.

How many folks manually enter in an email pswd on their smartphones?

If any of the tools you mention were readily doable today, I fear we'd be so deep in trouble, no canary would help.

All of these tools are available. Also, recall that most mail clients will use STARTTLS opportunistically, i.e. will not encrypt stuff if you MITM them. The better ones may not send the login in the clear, but an attacker can still read mail - or steal the authenticated connection (this is more tricky, and pretty much requires being on the same network.)

Seriously, most online security works only because the competent people have better things to do.

And many mail clients happily continue non-encrypted sessions if the STARTTLS negotiation fails.

I wasted _days_ recently trying to track down code bugs that weren't there - a piece of Cisco gear that was in the clients network was running a standard configuration called SMTP Fixup which was deep packet inspecting and rewriting the "250-STARTTLS" capability responses and passing them on as "250-XXXXXXXA" on the fly. It took me way longer than it should have to debug, partly 'cause I started looking in the wrong place, but largely because most of the testing we did was with mail clients that were perfectly happy to transfer mail unencrypted when the STARTTLS capability wasn't announced.

Anybody MITMing you in Starbucks could easily do the same.

A little bit of thinking with my "evil hat" on leads me to believe a similar protocol aware packet inspection/modification tool could easily rewrite webpages on the fly, looking for links to common service login forms and rewrite appropriate links and form actions to be http instead of https...

Maybe an appropriately paranoid way to set up this sort of canary is to have all your mobile (ie, non-fixed ip address) devices use a vpn into a trusted and well secured host?

> A little bit of thinking with my "evil hat" on leads me to believe a similar protocol aware packet inspection/modification tool could easily rewrite webpages on the fly, looking for links to common service login forms and rewrite appropriate links and form actions to be http instead of https...

That already exists in the form of sslstrip: http://www.thoughtcrime.org/software/sslstrip/

Reply on news.ycombinator.com