Login.gov neutered the security of 2FA
waleedkhan.name
waleedkhan.name
Of course there are far too many organizations which use text messages for authentication, as the article points out.
It didn't offer them Google Authenticator because they already /have/ Google Authenticator.
It wants every user to have TWO (or more) second factors available, because "two is one and one is none". If we tell users to have one second factor, they will forget it and then why did we bother building a second factor system?
So they need to pick another second factor they DON'T already have. They've apparently decided they don't want to write down 10 codes (fine) and they don't own a FIDO security key (I guess maybe they're poor?) so that only leaves SMS unless you have government ID.
The correct thing to do here if you care about Security is to buy at least two different FIDO Security keys and use those. Each of your FIDO keys counts as a different method.
If you have a shiny enough Android phone (maybe only Pixel series?) you can use that (in Windows). A new enough Windows PC might work too. But the tiny dedicated Security Keys are relatively affordable, you can get ones compatible with most plausible devices (iPhones, Linux PCs, whatever) and easy to reason about like real keys are. Has anybody stolen my FIDO key? No, it is here in my pocket. OK.
edit: I just logged into my own account (using Google Auth 2FA) and it did not ask me to change my 2FA.
[0] - https://www.login.gov/help/creating-an-account/two-factor-au...
The dialog in question is only for recovering your password, which is also an important flow to safeguard. In those cases it makes sense to use a different 2FA mechanism, so that you still have two separate factors for recovering your password. An authentication app was not an option in this dialog because it was already one of my factors.
I assumed that "Personal Key" was an authentication app, specifically in contrast to a "Security Key", and that I had to replace my 2FA option for regular logins with a different option.
While SMS is inappropriate for high value targets such as employees with infrastructure access or people with government security clearances, it remains an excellent option for general consumer security.
By contrast, the vast majority of people who use login.gov likely don't understand nor will they ever install an authenticator app. It makes sense to deprecate support for this vector if, presumably, few people are using it.
The Blog poster has forgotten or confused themselves into believing login.gov wants them to replace their Google Authenticator style sign-in, but it does not, it wants TWO methods of logging in, and Google Authenticator is only one.
Why does it want TWO?
Because two is one and one is none. Any particular method is always a single failure from being unavailable. You lose the phone, you forget the code, or whatever.
If you have two or more FIDO tokens, it will accept both methods being FIDO tokens, this is the safest option (the government ID might perhaps be as safe or safer but obviously isn't available to lay people so I have no idea)
Google Authenticator and the 10 random codes are next safest and zero cost. You will need to keep them safe, and hope login.gov keeps them safe too, and they're vulnerable to being phished, but otherwise they are pretty good.
SMS is a poor final option. But it is very convenient while also being essentially free so you can see why it had to at least be an option for now.
And 2FA with SMS is much more secure than no 2FA at all.
login.gov is deprecating the personal key in favor of a better backup 2FA method. But currently it only supports 1 instance of each 2FA type. So because the author already has a TOTP app configured, they can't select that as a replacement for the personal key.
That happens for two related reasons. Firstly the WebAuthn spec. says to allow this, I haven't read the U2F stuff because it wasn't formalised like WebAuthn, but I expect that instructed implementers to allow multiple keys too.
Secondly, because it's obviously the Right Thing, which is why it's a recommendation in the specification, the U2F and WebAuthn specifications explain how everything works properly with multiple keys.
* When you register a new key, the site provides cookies from any other keys that you've already registered. Your browser asks keys if they recognise those cookies, only a key that doesn't recognise any cookies should register as otherwise you're creating pointless duplicates.
* When you sign-in the site provides as many cookies as you've registered keys - each cookie only works with the key which picked it, but the keys can tell if a cookie is theirs, so whichever FIDO key you've got, it should recognise one of the cookies sent and you're in.
This is probably also true for government ID in the unusual case that somebody has more than one.