Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Just to be clear, they didn't obtain any passwords, but auth tokens. This would potentially allow them to log into accounts, but only as long as the tokens are valid.

Also, they don't reveal which "third party app stores" served infected apps, but they do provide a list of infected apps, and searching for these yields some real shady download sites: http://imgur.com/a/0luW3



Couldn't Google just revoke all of those access tokens? It'd be a minor inconvenience for some, but it would hardly be a big deal, right? You'd just have to grant access again.


    > Google also stated that they are ..., revoking affected tokens
That alone obviously isn't a fix though, just plasters over the hole such that you can still punch through just as before.


You're forgetting the less diligent users. I guarantee some Google users don't remember their password and just count on never being prompted, I know some of them.


Does 2FA help in this situation? If the token signs in from a previously unknown device/server wouldn't it prompt for authentication details?


FTA:

> While Google implemented multiple mechanisms, like two-factor-authentication, to prevent hackers from compromising Google accounts, a stolen authorization token bypasses this mechanism and allows hackers the desired access as the user is perceived as already logged in.

The trouble is that auth tokens are generally not tied to a specific device or IP. There aren't really any mechanisms for this in standard OAuth 2.0 flows (if indeed this is what they're using).


No, but this would be solved if Google and client applications implemented OAuth token binding: https://tools.ietf.org/html/draft-jones-oauth-token-binding-...


No. The malware steals a secret stored on the device that gives the attacker the same access to your google account as your own phone.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: