Google Apps Security Vulnerability Puts Organizations’ Data at Risk

I respectfully disagree with the Daniel's blog post. Changing a password should not inherently reset all application-specific passwords, and though he doesn't mention it, it shouldn't revoke all OAuth associations either.

Perhaps I look at it in a different view point. Application-specific passwords, username/password combo, and OAuth are all separate authentication methods. The compromise of one shouldn't necessarily compromise the others (though additions/modifications subsequent to a compromise should be suspect). When the protocol for disabling a user is that you use the reset password functionality, that's using the wrong tool for the job. This is especially true when a disable user button is quite prominent on the Google Apps admin dashboard.

I worked in a K-12 school district for a while and password resets were a fairly frequent event. We also had many other web services that used Google OAuth. I'm not sure I would be keen on having to reset all of their accounts every time they forgot their password. At least 95% of password resets I did were because of forgotten passwords (remember, Google Apps doesn't have a forgot password system) and not due to a compromise or suspected compromise.

Finally, I'm not really sure what the point of changing a user's password to disable an account is. The argument could be made that you might want access to some of their data, but there's other tools in Google Apps admin dashboard for that. Want an e-mail audit? That's there (well, it was an API when I last used the dashboard extensively). There's also tools to migrate all their Google Drive data to another user. If you have the higher end Google Apps account, then you'll have Google Apps Vault which will give admins access to almost all of the user's data even once the account is suspended.

Headline is stated linkbaitly, poorly.

tl;dr: Admin reset password to disable user access, was irked that app-specific passwords were not revoked. Did not read docs how to revoke app-specific passwords.

Should there be a simpler interface for admins? (Revoke all access YES/NO?) Arguably, yes. Is this a vulnerability? Arguably.

My complaint with the headline is that it implies that Google App organizations are at risk RIGHT NOW and that these organizations should be up in arms RIGHT NOW.

Instead, there is a mild to moderate risk of continued access to very specific data - which will vary by organization - by terminated employees whose access should be revoked. In the case of email, e.g., they may - and likely do? - already have all their old email on their computer, so the risk increase is mild for this case. Other apps will vary.

Better headline: Google Apps user deprovisioning controls inordinately complex, may lead to post-termination security exposure

If you're changing a user's password to revoke access with Google Apps, you're doing it wrong.

Google Apps gives you two options to revoke access: suspending a user and deleting a user. If you suspend a user, you can later re-enable that user. In the event of firing an employee, you probably want to go ahead right away and delete the user - upon doing so you will be prompted to transfer any data to another user.

Edit: Perhaps, they should add a checkbox to revoke application-specific passwords in the change password interface.

I don't see a security vulnerability, but bad security practice.

Either they: Delete the account. All is well.

Either they: Take over the account. It is common sense then to change the phone number associated with the account. All is well.

You could solve this "bug" by reading the documentation and creating a better security protocol (which is currently putting your organizations' data at risk).

I clicked the title with just one thought it the back of my mind: "If this is an active serious vulnerability then why did OP not apply for the vulnerability program and have it fixed beforehand"?

My experience with the vulnerability team has been great (one honorable mention and one pay-out). If you did not get an honorable mention then it means the security team did not file a bug report. Your feedback could probably still be used to improve the UI.

As an aside: Hunting real security bugs on Google domains is insanely addictive (because they are so hard to find). Try to generate all their different error screens. Try to find the Google property running on aspx. To practice there is also https://google-gruyere.appspot.com/

I eagerly await the follow-up blog post, wherein Google's "Forgot Password" feature which allows a user to reset their password via a secondary linked account is decried as another gaping DEFCON 1 security hole that deserves a $10,000 reward check.

Come on. If a user shouldn't have an account anymore, delete the account.

I actually had this happen at my company. We had a dispute with a past employee and they started bringing up issues they shouldn't have known about. Eventually we figured it out.

For Google Docs/Drive, the data transfer is simple. Other apps? Not so much. And that's not even getting into third-party apps that use google apps authentication.