Lithuania: Students stop university from using only proprietary authentication

If you think of it as a keyring there's nothing wrong with not backing up the keys by default. You are right, however, that it should inform the user about the importance of having more copies of the keys if the service doesn't implement backup codes. Personally I prefer to transfer key clones directly to backup devices without the need for the backup device to be online. The few keys that I lost due to MS Authenticator were from a time before I introduced this process.

Nice seeing this little victory, but a big one for the students.

But to me is what M/S is doing with their WSL (and secure boot). They want to get to the point were Linux can only execute under Windows on new Laptops. The Companies that control Linux (yes, Linux is now pwned by corporate interests) do not care what really happens to Linux as long as Wall Street is happy.

They went straight for Extinguish. Microsoft Authenticator is far from being any form of "Enchancement"

I asked our sysadmin at work to enable it and found out it is only an option for personal accounts. Business accounts force you to use the Microsoft authenticator app.

TOTP doesn’t perform mutual-authentication: a lookalike on-screen prompt can be used to capture individual codes from unwitting users.

Stopping phishing-based MITM attacks is one of the main things addressed with FIDO/U2F/Webauthn versus TOTP. Imagine an imposter website that is impersonating the real relying party as part of a phishing attack.

With TOTP, the user is relaying a short-term secret code from their authenticator into the relying party's UI. But there isn't any authentication step to ensure that the user is really interacting with the expected relying party, and there is a time window where this code can be replayed. Once the attacker has this code, they could initiate multiple authentications with the real relying party during that window (approximate 1-2 minutes).

With Webauthn, the relying party origin is used as part of a cryptographic signing step by the authenticator. There is also a per-request salt to prevent replay attacks. The imposter website would not be able to initiate a useful authentication step with the authenticator, since it would not be able to impersonate the real origin to the authenticator protocol. The various push-based authenticator apps have the opportunity to offer similar security, since they can authenticate the relying party challenges, show the user a trustworthy challenge prompt, and ensure that the response is not usable for replay attacks.

A different category of attack might be to compromise the user agent itself. Then real sessions could be hijacked to perform operations not intended by the user. The non-replayable responses can partially mitigate these attacks too. The user can be prompted in real-time to reauthenticate for high-value operations, and may notice spurious prompts when they were not intentionally doing such actions. However, fatigue can set in if the user has too many relying parties registered with an authenticator and/or too many challenges and/or have non-determinism between UI actions and challenges. Then, the user could be confused into approving a challenge for the hidden attack operation happening in the background between their own intended actions.

AFAIK, the only way to fully protect against this would be to include details of high-value operations in the challenge/response signature and have a way to display this detailed context in a trustworthy prompt. I.e. a mobile phone authenticator might be trustworthy even with a compromised desktop browser. But if your mobile browser is compromised, I would suggest you also should not trust the authenticator app on the phone. A dedicated hardware authenticator with a screen could show you challenge context, even if the user-agent is trying to fool you. This would be an improvement over the typical security key that at most blinks an LED and leaves it to the user to guess what is being authenticated.