https://www.fastmail.com/help/account/2fa.html
>> Why do I have to add a recovery phone number to set up two-step verification?
> Keeping your account safe from attackers is very important. But so too is making sure you don't get locked out of your own account. We are aware that SMS is not the most secure of methods for 2FA, and has been deprecated by NIST. However, for the majority of users, the risk of losing their two-step verification device is far greater than the risk of someone hacking their SMS. If you lose your phone, the TOTP key is lost but normally you can get a new SIM card with the same number from your carrier. We therefore believe requiring a phone as a backup option strikes the best balance of confidentiality (no one else can read your data) and availability (you can read your data) for the majority of our users.
> Please note, if two-step verification is enabled, access to the phone number itself is not sufficient to gain access to an account: you still need two factors (your password AND the SMS).
> Advanced users that understand the risk may remove the phone number from their account once two-step verification is enabled. Once the recovery phone is removed from the account, SMS is no longer an option as the second factor for login. If you choose to do this, we strongly recommend you write down or print your recovery code and store it in a safe location, and that you set up at least two security keys or authenticator devices. Should you lose access to all two-step verification devices and not have your recovery code, you may be permanently locked out of your own account.
It addresses the problem with phishing. The main problem with Authenticator is not that an attacker knows the one-time password, but that an attacker tricks user into entering the one-time password to their UI and uses that right away to take control of the user's account.
https://krebsonsecurity.com/2018/07/google-security-keys-neu...
But if you never actually login with TOTP, and always use your U2F key, then does it actually decrease security to have it as a backup/removal option and you know that's the only reason you'd enter it.
It feels like its competition there is "convince phone support with a sob story" and TOTP feels like a clear step up from that.
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...
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.
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.
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....
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:
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'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)?
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.
So it really doesn't do any hard to have TOTP enabled as a fallback if you never store the key anywhere.
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.
Everything is fed into an HMAC after all. It's only the last step where truncation occurs.
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.
The Yubikey explicitly supports TOTP, and will happily store your secret on the key. You can then use Yubioath to pull codes from the Yubikey as needed.
I'm a huge fan of the ability to use either U2F or TOTP with the same hardware token.
You can setup OTP (no SMS) and either keep it as a backup, or destroy the key. I don't have SMS on Github.
Admittedly, it won't solve issues with all services. From the service perspective, dealing with users who lost their security key (or don't have a backup one) is too painful wrt to forcing you to have an alternative.
The #1 weakness is the simple fact that many services don't allow you to disable alternate forms of 2fa.
Github is an example, you can always trigger the fallback SMS 2fa code.
Dashlane is another example (and arguably the most important). It's impossible to make your security key the only form of 2-FA. If you have a security key on your account, you must also have regular app-based 2-FA enabled as a fall back.
What's the point of using security keys with services that require regular SMS or app-based 2-FA as a fallback?
Edit: G Suite is one of the few services that got it right. G Suite has an optional security control that when enabled, forces authentication using security keys (explicitly forbidding alternate 2-fa methods).