Your right, a password that only works for a specific service or property or protocol would help, but "email box" is not the best example of your point - even if the only Google access is could steal off you was the ability to read you mail, you've pretty much hosed - I can now go to every other website and ask them to send you a password reset, and you're now lost down the Mat Honan rabbit hole. Where does your appleID reset go? Or your domain registrar accounts? Your Facebook/Twitter/HN password reset email?

> I can now go to every other website and ask them to send you a password reset

Yes, and, provided I've discovered the issue in time, I can use one of my ten reset codes or OTP to log in, revoke/disable all my ASPs, and reset them again. Recoverable.

If you'd stolen my whole Google account, you've likely regenerated the codes and changed the backup email and phone number. No exit.

Sure, but that "provided I've discovered the issue in time" leaves a gaping hole for a sneaky attacker. If I've got your email password, and I'm camped on your email account while hitting all the other website's forgot password forms, and I delete all the mail as soon as I've retrieved the link - how do you "discover the issue"? In some ways, that sort of attack is even more insidious than taking over the Google account completely - at least being locked out of your account raises the big red flags immediately, how would you even notice I was reading all your mail with a stolen ASP? (While I'm being particularly evil in my thinking, I'm imagining an attacker quietly gaining access to read email, and not actively doing anything to arouse suspicion, then waiting for _you_ to hit passwrod reset links on various high-value-to-the-attacker sites, perhaps forcing that on you by triggering brute force protection on those other sites…)

The Google "Application Specific Passwords" are actually complete passwords which give you access to all data in the account, which is the problem.

They don't let you log in via the web, only via protocols that have a single field for "password", like xmpp, imap, and smtp. There is tons of data in the account which is not accessible with an ASP.

When you try to log in on the web with an ASP, it asks for the account password + OTP.

That's (probably) true right now, but the article points out that mis-using the chrome autologin mechanism allowed access to anything - including unfettered access to your account settings page - with just an ASP. This was true for at least 7 months. Until last Thursday, your xmpp ASP did give anyone with some specific knowledge access to all of what you think of as "data in the account which is not accessible with an ASP".

_Hopefully_ the fix in place now makes your statement correct now and in the future. But this shit is hard - I wouldn't be betting my house on it not having further flaws.

Constructive suggestion: create a new, non-obvious, high reliability email account. Don't use it for anything except as a password recovery email address for high importance accounts. I have my Google/Apple/Amazon/eBay/PayPal/DomainRegistrars/webhosting accounts pointed to it, but not things like Twitter/FaceBook/LinkedIn/forums/HN/n-random-website. Document carefully where you've used it so in the case of a high-profile intrusion on one of your "high importance" websites you know exactly where you need to change that email address (to prevent an attacker being able to leverage the disclosure of that email address). Don't ever publish that address anywhere else. I know this is mostly "security through obscurity", which is in crypto contexts a totally flawed proposition, but in terms of "reducing the attack surface" of your critical online accounts, I think it's an effective tactic.

That's the problem though, isn't it? They don't do password specific permissions, so any leak escalates up to taking over the whole account.

No, ASPs can only be used to access account data available over imap, smtp, xmpp, and other non-web protocols that don't allow cookies/asking for the OTP.

Not true. Read the article :)

The article says it's fixed.

The fix that Google rolled out blocks ASP-based logins from accessing a few highly-sensitive pages on https://accounts.google.com, but otherwise, little has changed. With a quick API request, you can still use an ASP to skip just about any other Google web-based login anywhere on the web. Google might have to completely eliminate their Chrome/Android auto-login feature to actually prevent this sort of thing...