Google likes to boast about its security, but on Tuesday it admitted making two password hash storage blunders. one of which dates back to 2005. For a number of unnamed organizations and users, passwords weren’t hashed, making it possibly easier for them to be cracked.
As a result, an unknown number of G Suite administrators have been told all users have to reset their passwords.
The problems only affect the paid enterprise G Suite and not the free consumer Google accounts.
The most recent problem was discovered in May when Google was troubleshooting new G Suite customer sign-up flows and found it had inadvertently stored a subset of unhashed passwords. Those passwords were stored for a maximum of 14 days, said Suzanne Frey, Google’s vice-president of engineering for Cloud Trust, in a blog Tuesday.
One Canadian G Suite admin was told more details in an email from Google: Between January 13, 2019 and May 9, 2019, an internal system that logged account signup information for diagnostic purposes, inadvertently stored a user account password in Google’s encrypted systems in an unhashed format. Normally Google stores a hashed password with an encrypted username. This error affected new account signups during the four-month period. The log information was retained for 14 days following the signup process, and then was deleted according to Google’s normal retention policies.
Hashing is a one-way scrambling of information, like a password. Unlike encryption, which is designed to be scrambled and unscrambled, a hash is applied only once. When a user tries to log in with the same password it gets hashed the same way, and the security system compares the attempt with the stored hash. If they are identical the login is accepted.
Hashing on top of encryption is considered one of the strongest ways to protect user credentials.
“Honestly, it’s inexcusable,” said Darryl Burke, a security consultant and G Suite administrator for two Ontario firms, said of this miscue after he received a warning email. “The amount of risk for internal espionage for companies who use G Suite and Google employees who had access to users’ password is huge. Couple that with password reuse [by users] on third party sites that use a G Suite email as user ID and it [risk] gets worse.”
He added someone could pass on or sell those passwords to third parties with little if any trail back to them.
The other hashing problem was discovered in April and dates back to the implementation of a feature in 2005, Frey said in her blog. G Suite business domain administrators have had tools for years to set and recover passwords, which ran through their administrator consoles. The idea was to help them with onboarding new users. However, Google now admits, it made an error when implementing this functionality in 2005: The admin console stored a copy of the unhashed password, although it was encrypted.
One Toronto firm was told three of its 30 G Suite users were affected.
This message went out to affected companies: “We are writing to inform you that due to legacy functionality that enabled customer Domain Admins to view passwords, some of your users’ passwords were stored in our encrypted systems in an unhashed format. This primarily impacted system generated or admin generated passwords intended for one-time use.”
Starting May 22 Google will force a password change, unless it has already been changed.
The password update methodology is:
- Users With Single Sign On: Google will reset their password by changing it to a randomly generated secure value. Please note that this will have no effect on their ability to log in using their Single Sign On credentials.
- Other Users and Super Admins: Google will terminate their sessions and prompt users to change their password at their next login.
- In addition, starting Wednesday, May 29th Google will reset the password for users that have not yet selected a new password or have not had a password reset. These users will need to follow your organization’s password recovery process. Super Admins will not be impacted.
“This practice did not live up to our standards,” Frey said of the problems. “To be clear, these passwords remained in our secure encrypted infrastructure. This issue has been fixed and we have seen no evidence of improper access to or misuse of the affected passwords.”
“We take the security of our enterprise customers extremely seriously, and pride ourselves in advancing the industry’s best practices for account security,” Fry wrote. “Here we did not live up to our own standards, nor those of our customers. We apologize to our users and will do better.”