And, who cares whether you consider it "real" or not? That's quite irrelevant, really. It's in common use, no matter what you'd call it, and most of the world calls it 2FA.
And you're the one that goes off on huge tirades about how you magically don't need any of it personally.
What is relevant? User behavior... that's what's relevant.
Code based 2FA sucks, because users have to type in a 6 digit code. Not only do they give those codes up via the same social engineering BS that they lose their passwords with, but they're inconvenient as all get out. It doesn't matter how they get these codes. Now, SMS and email based code delivery opens up a whole new can of worms in this space for stealing those codes... but the fact remains access to the codes themselves is not secure, largely due to user stupidity that we'll never completely cure.
Push notifications don't work, because most of them are a simple accept / reject prompt. They fail for the same reason UAC prompts with admin rights fail. Users do not think about them, they simply get them and push OK. Get a user busy, and they'll reflex that accept button EVERY TIME. So this process isn't any better than a password while the user is awake.
Proper 2FA is designed for all of the above. Both Google and Microsoft have the means to do this properly. Microsoft calls theirs "Phone Sign-on".
The signin process for Phone Sign-on is like this:
User punches login into thing that needs it, a login form appears on the screen with a two digit code, the user receives a notification on their mobile device, user unlocks their mobile device, types in the two digit code on the device and touches accept. Login complete.
Not only is the above process idiot proof easy, but it's patently impossible to subvert. Attackers cannot "steal" a code, because one doesn't exist. The password cannot be stolen because it too, doesn't exist. (passwordless sign-on is part of this) The only thing they can do is breach the authentication system itself. They could also steal the phone... But that tends to generate phone calls. So for a remote and quiet breach they need something that can break the sandbox of a mobile device and let it eavesdrop on the mobile app doing the lifting.
So if you have a real phone, a Google Pixel or an Apple iPhone, that's fully patched and serviced... the above simply doesn't happen. For the same reason these sorts of things don't tend to happen on Microsoft Windows that's fully patched and serviced. Got a crap phone from a crap vendor that isn't getting patches? Well... you aren't safe... you're running an unpatched and out of support device! That's a problem, stop it.
This stuff is game, set, and match for impersonation breaches. Hyper-Secure environments use dedicated hardware for this process instead of mobile devices for a reason. Because something you have (your phone / HOTP device), and something you know (unlock code / pattern / biometric / password) is as an authentication base is as good as it gets. Most of us don't need or want something that strong, so using our phones is just easier.
As for the article? I've been training users on these concepts for years. They are not new techniques. This isn't even news. And it most certainly isn't evidence of why not to use 2FA. It is however why I say, real 2FA doesn't rely on these codes. The fact that banks and other massive organizations don't do this correctly is on them. We have the technology, we have buckets of places refusing to use it.
