TOTP is one thing. Having your backup TOTP key locked in a safe effectively stops it from being abused.

SMS 2FA, on the other hand, has real security issues[0][1]. In my experience, SMS 2FA is most commonly the required type of 2FA, before you can add TOTP/U2F as a secondary.

SMS 2FA is the hardest to lose or break, so forcing everyone to keep it enabled minimizes support costs for the provider.

[0] https://www.theregister.co.uk/2016/07/24/nist_says_sms_no_go...

[1] https://duo.com/decipher/reddit-breach-illustrates-dangers-o...

The other thing driving SMS 2FA is that this is a clean way for the site/org to get their hands on a real phone number for you with no extra effort.

SMS 2FA has been repeatedly proven to be trivial to break with a simple phone call to a mobile provider, since there so far is no downside at all that I am aware of to the providers. If someone jacks your SMS and drains your bank account, at least in the US your mobile provider just goes "oops". Until there is some penalty for them allowing your number to be ported without your consent, SMS is essentially useless for real 2FA security. Even if the account security was foolproof, though, it still is vulnerable to SS7 routing attacks.

Using Authy may be a good idea. There is a slight risk of exposing the TOTP key to the cloud, but having it available on all devices (current and future) is very convenient. Authy has an option to encrypt the key using a user specified passphrase, so it is at least better than storing the raw TOTP key in the cloud.

There's a small downside to TOTP even if you never use it in anger.

For U2F/ WebAuthn the relying party doesn't end up knowing any secrets. So if for example I get a month old database backup of Facebook, I don't learn how to log in with U2F as any of the users whose credentials I have, because Facebook can't do that either, only the legitimate users can.

For TOTP that stolen data gets me in, because I can synthesize correct TOTP codes for any user whose secret key I have stolen.

But you are correct that social engineering attacks will be far more common. The particular concern with SMS is that the attack can target your mobile phone company, so that all the security at say Facebook or Twitter doesn't help you because your security was blown up at T-mobile or AT&T.

Interesting point - it's essentially a long lived secret.

Actually what would happen if [large_comapny] had their TOTP secret revealed? Would they be forced to invalidate everyones TOTP? They can't just disable it they would have to somehow authenticate you a third way....

> Actually what would happen if [large_comapny] had their TOTP secret revealed? Would they be forced to invalidate everyones TOTP?

Yes.

RSA got hacked for their SecurID information, so that the attackers could then turn around and get into Lockheed Martin:

* https://gcn.com/articles/2011/06/07/rsa-confirms-tokens-used...

* https://www.scmagazine.com/home/security-news/rsa-confirms-l...

Among other things, LM makes the F-35 fighter:

* https://en.wikipedia.org/wiki/Lockheed_Martin

Ooh that's interesting! Coincidentally my very close relative works for their F16 program! Yeah they're one of the largest military contractors - not a company anyone wants to have a breach.

It's not one secret, it's a secret per pair. Imagine Anne and Barry both use TOTP with Google and Facebook, there would be one secret for (Anne,Google), one for (Anne,Facebok), one for (Barry,Google) and one for (Barry,Facebook).

A good implementation chooses the secret randomly. But both sides need to know what it is. In the example above Anne needs to know both her secrets (they'd be inside her Google Authenticator) and Facebook needs to know both their secrets (probably in a SQL database).

Stealing Facebook backups would get me the (Anne,Facebook) and (Barry,Facebook) secrets, but not the Google ones.

I know the client key is derived from the server key (So if Facebook's was released, your Google's TOTP is still safe).

I'm guessing it depends on the implementation, are the server secrets normally derived per user or shared across users (Talking about just a single service such as facebook)?

> I know the client key is derived from the server key

No. TOTP is a shared secret system, there is only one key.

> I'm guessing it depends on the implementation, are the server secrets normally derived per user or shared across users

Again no. The only reasonable thing to do is pick secrets entirely at random for each user. If the same secret is used then users can trivially impersonate each other, which makes no sense.

TOTP, unlike a password, can't be brute-forced. If the secret is lost, its game over, but if the secret stays protected, you can't guess it because you can only test the codes, not the secret itself. Brute-force for TOTP would only be possible if you could test 2^6 OTPs in the 60-second window, which would be mitigated by rate-limiting.

So it really doesn't do any hard to have TOTP enabled as a fallback if you never store the key anywhere.

It’s worth noting that TOTP secrets are more vulnerable than passwords on the service-provider side.

They have relatively tiny key space (generally 6 digits), so if the provider doesn’t protect against brute-force, it’s quick and easy to slam the whole key space until you win.

They also need the secret in a reversible format, since the service provider has to use the secret to calculate valid codes. So the most common password brute-forcing pathway (theft of a database full of password hashes) is rendered moot: you don’t have to brute-force the hashes because they aren’t hashes, they’re just secrets. At best, the TOTP seeds are encrypted at rest, but since whatever server validates tokens has to decrypt them to do so, most implementations in the wild either don’t encrypt or keep the decryption key right next to the data.

While the resulting codes you get at the end of the process are only six digits, the TOTP secret can really be any length.

Everything is fed into an HMAC after all. It's only the last step where truncation occurs.

Yes, but the key space to brute force is the key space after truncation. You don’t need to brute force the original seed.

If an attacker can (for whatever reason, be it rate limiting or cost) only brute force 100 guesses per time period (say, 30s), they'll expect to be able to 'win' the challenge in about 58 hours.

The probability of guessing the challenge _wrong_ once is (1 - (100 / 1000000)). Every 30 seconds you get another chance. The probability of guessing the challenge wrong N times in a row is (1 - (100/1000000)) ^ N. Around chance number 7000, the probability that you've guessed it wrong all N times goes lower than 50/50. ~7000 * 30s in hours is around 58 hours.

At some point the 2FA protected system should stop accepting guesses entirely for a period - the same way you would lock an account for incorrect password guesses, or at worst rate limit down to a single guess per time period after a certain number of failed guesses.