I believe they logged into coinbase with Google SSO. And then they used my Google Authenticator codes which were cloud synced as the second factor auth method.

A warning to auth engineers: if an account is using a Gmail address, then auth codes from Google Authenticator should not be considered a second factor.

▲

avree 5 days ago | parent | next [-]

This isn't something "auth engineers" can control, there's no magic Google Authenticator flag on a 2fa code - it's all HMAC and numbers, you don't know if the code came from Authy, Google Auth, a homebrew code generator, a dongle, etc.

▲

wmf 5 days ago | parent | next [-]

It sounds like we're back to physical Yubikeys as the only secure auth.

▲

moduspol 5 days ago | parent | next [-]

Seems reasonable if you need to secure five figures or more in crypto.

▲

acdha 5 days ago | parent | prev [-]

Passkeys also solve this even if they’re not hardware backed. He was able to give them a code but wouldn’t have been able to do a passkey handshake for a domain which isn’t Google.com. Plus they’re easier to use and faster.

▲

wmf 5 days ago | parent [-]

I don't know about that. If they can hack your Google/iCloud account they can add a new device, sync all your passkeys to that device, then log into all your other accounts.

▲

acdha 5 days ago | parent | next [-]

How do they do that if you are incapable of giving them a valid authentication code?

I don’t use Google but at least in the Apple world you also get a fairly different prompt for enrolling a new iCloud Keychain device than simply logging in. Obviously that’s not perfect but there is a good argument for not getting people accustomed to hitting okay for both high and low impact challenges using the same prompt.

▲

ameliaquining 5 days ago | parent | prev [-]

But they can't hack your Google or iCloud account if it's secured with a passkey, unless they have some other non-phishing means of doing so, which the attacker in this story presumably did not.

▲

Symbiote 4 days ago | parent [-]

I had to reset the 2FA for a domain admin account for Google Apps earlier this year — I'm not sure if my password manager somehow lost the passkey, or if I missed creating one before some deadline. (It's a little-used domain.)

I think I requested the reset with various details, then had to wait 24 hours before continuing.

	▲	acdha 4 days ago \| parent [-]
		I feel like a lot of things would benefit from that time delay and, perhaps, an in person check like the notary ID verification AWS used to use. About a decade ago I had suggested to Google at an identity forum that they embrace a local government/organization model for their hard-landing account recovery process (since it can ultimately devolve to an ID check) by having a mechanism where you can start the account reset process and get something which could be taken to a third party to approve after they do an ID check. As people increasingly depend on things like email accounts for everything there are a constant stream of people who will lose access to their phones but could easily visit a notary, library, DMV, police station, etc. and pass a check against a pre-registered government ID.

▲

davidscoville 5 days ago | parent | prev [-]

Exactly. Google created vulnerabilities for the whole industry by introducing cloud synced Authenticator codes.

	▲	commandersaki 4 days ago \| parent [-]
		Similarly the SSO sign in, which I think is much worse. Though arguably Coinbase is at fault for that one.

▲

haarolean 4 days ago | parent | prev [-]

>A warning to auth engineers: if an account is using a Gmail address, then auth codes from Google Authenticator should not be considered a second factor.

Incredible take. I don't know what's worse here — suggesting gmail address = google authenticator, thinking you can know the source of "auth codes", or the fact this is coming from an auth engineer. I'm switching to handwritten HMACs on paper napkins today.