> Retool needs to revise the basic security posture.

Couldn't agree more. TBH I thought this post was an exercise in blame shifting, trying to blame Google.

> We use OTPs extensively at Retool: it’s how we authenticate into Google and Okta, how we authenticate into our internal VPN, and how we authenticate into our own internal instances of Retool. The fact that access to a Google account immediately gave access to all MFA tokens held within that account is the major reason why the attacker was able to get into our internal systems.

Google Workspace makes it very easy to set up "Advanced Protection" on accounts, in which case it requires using a hardware key as a second factor, instead of a phishable security code. Given Retool's business of hosting admin apps for lots of other companies, they should have known they'd be a prime target for something like this, and not requiring hardware keys is pretty inexcusable here.

> Google Workspace makes it very easy to set up "Advanced Protection" on accounts, in which case it requires using a hardware key as a second factor, instead of a phishable security code.

This isn't immediately actionable for every company. I agree Retool should have hardware keys given their business, but at my company with 170 users we just haven't gotten around to figuring out the distribution and adoption of hardware keys internationally. We're also a Google Workspace customer. I think it's stupid for a company like Google, the company designing these widely used security apps for millions of users, to allow for cloud syncing without allowing administrators the ability to simply turn off the feature on a managed account. Google Workspace actually lacks a lot of granular security features, something I wish they did better.

What is a company like mine meant to do here to counter this problem?

edit: changed "viable" for "immediately actionable". It's easy for Google to change their apps. Not for every company to change their practices.

> What is a company like mine meant to do here to counter this problem?

What is hard about mailing everyone a hardware key? I honestly don't see the problem. It's not like you need to track it or anything, people can even use their own hardware keys.

1. Mail everyone a hardware key, or tell them if they already have one of their own they can just use that.

2. Tell them to enroll at https://landing.google.com/advancedprotection/

> Google Workspace actually lacks a lot of granular security features, something I wish they did better.

Totally agree with that one. Last time I checked you couldn't enforce that all employees use Advanced Protection in a Google Workspace account. However, you can still get this info (enabled or disabled) as a column in the Workspace Admin console so you can report on people who don't have it enabled. I'm guessing there is also probably a way to alert if it is disabled.

I can't tell you how happy I am that I don't have to fight with Google Workspace administration anymore. When I was doing it, getting TOTP enforcement enabled was very problematic. You couldn't just set the org to be enforced, because new users wouldn't be able to login, and then you'd have to turn it off for the org any day new people started, then make sure that everybody was enrolled (including existing employees that turned it off while they could), etc.

They finally fixed it, but it took them a long time, and in the meantime, horrible workarounds.

They also had no way of merging two company's accounts; which is fine because m&a never happens, and google never aquires anyone using google workspace (i certainly would refuse to be aquired by them after using their software, but I'm extra grumpy)

It is not based on the sole testimony of the employee. (Sorry I can't go into more details.)

Employees are only human. Even smart, savvy, well-trained employees can be fooled by good social engineering every once in a while.

The key to good security is layering. Attackers should need to break through multiple layers in order to get access to critical systems.

Compromising one employee's account should have granted them only limited access. The fact that this attack enabled them to get access to all of that employee's MFA tokens sounds like indeed the right thing to focus on.