Building secure software requires careful design; building a secure software system requires consideration not just of technical details, but also how users will interact with the software. A secure design is the result not just of technical and algorithm choices, but also user experience/interface decisions. Any system is only as strong as its weakest link, and your user forms a part of the system you’ve built (that’s why those stick people keep making an appearance in design documents).
A user must be “reliably made aware of the security tasks they must perform” (Why Johnny Can’t Encrypt, 1999). It is on these grounds I declare Google Apps‘ administrative interface a failure and a security risk.
Around a year ago, I decided that one of our employees would be better suited for a different employer. In accordance with our termination checklist, we set about changing any password they had been given, including the password to their Google Apps account. But I quickly realized that – despite resetting their password – they actually still had complete access to their Google Apps email account.
Why? Ironically, because of our attempt to increase security. We enabled two-factor authentication in Google Apps and asked our users to setup their phones as a 2nd factor for authentication. Using two-factor authentication requires the creation of “application specific passwords” to access an account using a native mail client. Users are able to create and administer “application specific passwords” on their own.
When you go into the Google Apps admin panel and change a user’s password, any application specific passwords they have created remain valid. And the user interface doesn’t make you aware that you haven’t finished the job of revoking their access. It would be an incredibly understandable mistake for an administrator to believe “I changed the user’s password” is equivalent to “I revoked the user’s access”. But in this case, it’s not. And using the explicit “disable user” functionality does not allow an organization to perform the work needed to transition data and access to new users.
I quietly reported this as a vulnerability to Google’s Vulnerability Reward Program and gleefully awaited my $10,000 check. They instead responded with a link to documentation describing how to revoke a user’s application specific passwords – as if the fact a documented procedure exists for correctly revoking a user’s access mitigates the risk.
I respectfully disagree. An implementation which assumes that users will read and remember all of the documentation for a system is naive.
It has been nearly a year since I reported the issue, and Google does not appear to have made any significant improvements to their interface to help administrators understand how to properly secure access to an organization’s data.