> I'm surprised Google encourages syncing the codes to the cloud... kind of defeats the purpose.
Depends on what you think the purpose is. People talk about TOTP solving all sorts of problems, but in practise the only one it really solves for most setups is people choosing bad passwords or reusing passwords on other insecure sites. Pretty much every other threat model for it is wishful thinking.
While i also think the design decision is questionable, the gain in security from people not constantly losing their phone probably outweighs for the average person the loss of security of it all being in a cloud account (as google cloud for most people is probably one of their most well secured account)
It's also a reasonable defence against naive keylogging techniques - including shoulder-surfing either directly or eg via security cameras. In some places this can be a pretty big threat.
I think its reasonable against spur of the moment shoulder surfing. I'm a little doubtful about how common that attack vector is - i think showing passwords as ** is a reasonable deterrant against literal shoulder surfing as well. Once you get security cameras involved things get more sophisticated and people can watch the feed live or do other things with physical access to the device.
Ultimately, i think for the average user the attacker is mostly not in physical proximity (although there certainly are exceptions), and if you are being targeted explicitly then you are screwed if they are installing cameras and modifying your hardware.
Maybe the big exception would be a camera in a coffee shop place looking for people (not live) logging into their bank accounts. I could inagine this being a helpful defense.
Well all Google needed to do to make it at least a little harder is to encrypt the backup with a password at least.
The user can still put in an insecure password but uploading all your 2FA tokens to your primary email unencrypted is basically willingly putting all your eggs in one basket.
TOTP is helpful when you don’t fully trust the input process. If rogue javascript is grabbing creds from your page, or the client has a keylogger they don’t know about, TOTP can help.
Blizzard was one of the first large customers of TOTP, and what we learned from that saga is that 1) keyloggers are a problem and 2) impersonating people for TOTP interactions is profitable even if you're only a gold farmer.
The vector was this: Blizzard let you disable the authenticator on your account by asking for 3 consecutive TOTP outputs from your device. That would let you delete the authenticator from your account.
The implementation was to spread a keylogger as a virus, and when it detected a Blizzard login, it would grab the key as you typed it, and make sure Blizzard got the wrong value when you hit submit. Blizzard would say try again, and the logger would collect the next two values, log into your account, remove the authenticator and change your password.
By the time you typed in the 4th attempt to log in, you'd already be locked out of your account, and by the time you called support, they would already have laundered your stuff.
This was targeting 10 million people for their imaginary money and a fraction of their imaginary goods. On the one hand that's a lot of effort for a small payoff. On the other, maybe the fact that it was so ridiculous insulated them from FBI intervention. If they were doing this to banks they'd have Feds on them like white on rice. But it definitely is a proof of concept for something much more nefarious.
The rouge javascript or keylogger would just steal the totp code, prevent the form submission, and submit its own form on the malicious person's server.
Not to mention if your threat model includes attacker has hacked the server and added javascript, why doesn't the attacker just take over the server directly?
If the attacker installed a keylogger why dont they just install software to steal your session cookies?
This threat model doesn't make sense. It assumes a powerful attacker doing the hard attack and totally ignoring the trivially easy one.
> Not to mention if your threat model includes attacker has hacked the server and added javascript, why doesn't the attacker just take over the server directly?
If the attacker can only hack the server that hosts your SPA, but not your API server, they can inject javascript to it, but can't do a lot beyond that
So assuming server side compromise not xss - in theory the servers can be isolated, in practise its rare for people to do a good job with this except at really big companies.
Regardless if they got your spa, they can replace the html, steal credentials, act as users, etc. Sure the attacker might want something more, but this is often more than enough to do anything the attacker might want if they are patient enough. Certainly its more than enough to do anything TOTP would protect against.
> attacker has hacked the server and added javascript
adding javascript doesn't necessarily mean the server is hacked. XSS attacks usually don't require actually compromising the server. Or a malicious browser plugin could inject javascript onto a site.
> in practise the only one it really solves for most setups is people choosing bad passwords or reusing passwords on other insecure sites. Pretty much every other threat model for it is wishful thinking.
The other side of this is that (to pull numbers out of my hat) 90% of non-targeted attacks are password reuse and 9.9% are phishing with 0.1% being something else. The fact that TOTP doesn't solve phishing does get talked about.
Ultimately totp & sms based 2fa is used because it solves the real business problem that websites face (the business problem being when enough users get hacked they blame the business not themselves, so we just need to save most of them not all). Yes there is some fear mongering to make people sign up for 2FA, but it is actually solving a big problem effectively. It doesn't matter its not helpful in more fanciful scenarios since those scenarios are largely imaginary to begin with (for the average user).
Depends on what you think the purpose is. People talk about TOTP solving all sorts of problems, but in practise the only one it really solves for most setups is people choosing bad passwords or reusing passwords on other insecure sites. Pretty much every other threat model for it is wishful thinking.
While i also think the design decision is questionable, the gain in security from people not constantly losing their phone probably outweighs for the average person the loss of security of it all being in a cloud account (as google cloud for most people is probably one of their most well secured account)