A recent internal network breach at a security company has prompted criticism of Google’s authenticator app due to what the company claims was a worsened security situation. Retool, a firm specializing in software development platform security, raised these concerns after disclosing a breach in its customer support system. This breach allowed attackers access to the accounts of 27 customers, all within the cryptocurrency industry. The breach was initiated when a Retool employee clicked on a link in a text message that appeared to be from the company’s IT team.
The attacker utilized a deceptive tactic, informing the employee that they couldn’t participate in the company’s open enrollment for health care coverage until a supposed account issue was resolved. This occurred while Retool was in the process of transitioning its login platform to security firm Okta. Notably, Okta had previously disclosed a breach of one of its third-party customer support engineers and the compromise of four customer Okta superuser accounts, although these events were not mentioned in Wednesday’s notification.
While most Retool employees did not respond to the message, one employee logged in to the linked site. The poorly-worded disclosure seemed to indicate that the employee may have unwittingly shared both a password and a temporary one-time password (TOTP) from Google Authenticator. Subsequently, the employee received a phone call from an individual claiming to be an IT team member, who appeared to possess knowledge about the company’s office layout, colleagues, and internal processes. During this call, the employee provided an “additional multi-factor code.” According to Retool, this is where Google’s authenticator synchronization feature, introduced in April, exacerbated the breach’s severity.
The synchronization feature allowed the attacker not only to compromise the employee’s account but also to infiltrate various other company accounts. This capability was pivotal as it enabled the attacker to add their own personal device to the employee’s Okta account, granting them continuous access to Okta multi-factor authentication. This access extended to Google Workspace, raising concerns about the security of multi-factor authentication codes when linked to Google accounts.
The post raised questions about the terminology used, particularly regarding the “OTP token.” Despite seeking clarification, Retool declined to elaborate, citing an ongoing law enforcement investigation. However, it appears that the employee was manipulated into sharing a TOTP twice, first to access the Okta account and later to enroll Google Authenticator on an attacker’s device within the Okta account. This allowed the attacker to access all accounts associated with the employee, including VPNs and support portals.
Retool also criticized Google for employing what it referred to as “dark patterns” to encourage users to sync their multi-factor authentication codes to the cloud, arguing that there was no straightforward way to disable this feature, especially within corporate Google accounts.
Additionally, the post implied that Retool may have used Google Authenticator’s TOTP-based MFA, which is vulnerable to phishing attacks, instead of adopting more secure forms of multi-factor authentication, like those compliant with the FIDO2 specification.
It’s worth noting that Google defended its Authenticator backup feature, believing that the benefits of cloud syncing outweigh the risks for most users. However, it acknowledged that certain enterprise environments might prefer to keep OTP codes stored locally. Users who wish to disable syncing can do so by ensuring that their app displays a line through the cloud symbol.
The spokesperson expressed concerns regarding the possibility of administrators disabling synchronization, which could lead enterprise users to resort to storing their codes on personal accounts. They reiterated the earlier point about the enhanced security offered by FIDO2 authentication methods compared to TOTP-based ones.
“The industry is heavily investing in FIDO-based technologies due to the phishing and social engineering risks associated with legacy authentication methods like OTP,” the representative emphasized. “While we are actively working towards these changes, we want to ensure Google Authenticator users are aware that they have the choice to either sync their OTPs with their Google Account or keep them stored locally. In the meantime, we are committed to striking a balance between security and usability as we explore future enhancements for Google Authenticator.”
Furthermore, the representative mentioned the potential implementation of end-to-end encryption (E2EE) in Google Authenticator in the future. However, they cautioned that this feature could pose a risk of account lockouts for some users if they happen to forget their passwords.
Kodesh, on the other hand, expressed surprise that the method Google Authenticator uses to sync codes with Google accounts could jeopardize Retool’s security. He stated:
“The fact that Google Authenticator syncs to the cloud is a novel attack vector. What we had originally implemented was multi-factor authentication. But through this Google update, what was previously multi-factor-authentication had silently (to administrators) become single-factor-authentication, because control of the Okta account led to control of the Google account, which led to control of all OTPs stored in Google Authenticator. We strongly believe that Google should either eliminate their dark patterns in Google Authenticator (which encourages the saving of MFA codes in the cloud), or at least provide organizations with the ability to disable it. We have already passed this feedback on to Google.”
The key takeaway from this narrative underscores the significance of FIDO2-compliant multi-factor authentication (MFA) as the benchmark for safeguarding accounts. While TOTPs remain an option, Google Authenticator strives to strike a delicate balance between convenience and security, appealing to individuals seeking a measure of MFA without the concern of potential account lockouts due to device loss. However, for enterprises like Retool, where security takes precedence and administrative control over accounts is paramount, Google Authenticator falls short of meeting the required standards