I think you're right. Users are being trained to enter their passwords and 2FA tokens everywhere with the false promise that 2FA makes it secure. Even U2F using a signed challenge seems iffy to me.
This [1] says "In fact, the spec requires that browsers only expose the API in secure contexts", so if that's correct it's better, but still not good enough.
This [2] looks like it does U2F by grabbing the challenges via browser plugin and relaying them to a phone app for signing.
Trusting the browser to "expose the API in secure contexts" seems like a failure because it's assuming nothing else can collect the credentials or send a challenge to a security key. Is that true? Could I write an app that would phish a user into signing a challenge with their security key?
> Could I write an app that would phish a user into signing a challenge with their security key?
What sort of app? A full-blown Windows/ OS X/ Linux desktop application? Yes.
You definitely should not install software that asks you to interact with your FIDO authenticator in this way unless you really trust it. I trust the Operating System vendor installed OpenSSH packages, I would not trust some random github project.
The two big phone ecosystems won't let you talk directly to a third party authenticator or to their built-in platform authenticator. The authenticator talks to them, and they talk to you. So while it would be possible to make a Windows EXE program that says "Touch authenticator to stroke your 3D pet" or whatever and actually steals your Facebook login credential this way, it should not be possible to put something on Google Play or Apple's iPhone store that does the same thing.
Edited to add: For Android at least there is a concept of "Privileged" apps that get to do stuff that is otherwise impossible to ask a user for permission to do. The ability to fill out WebAuthn-style rpId values (for WebAuthn these are Internet FQDNs) is locked behind such a privilege. So, Chrome has privilege, release builds of Firefox have privilege, and so on, but yet another fly-by-night app developer who uploads Flappy Bird clones to the Play Store can't use this feature.
Without this privilege when you talk to the authenticator (either a platform authenticator or a 3rd party one) the OS will insist on picking an rpId with a platform specific prefix. So e.g. maybe your app can ask for rpId android-584fac03:google.com but there's no way (without privilege) to get just google.com, which is a problem because that's the value you'd need in order to get working Google credentials.
If you want your app to talk to your own web site, you can build a bunch of extra goops (in Android at least) to enable that, but part of what will happen is your web site's backend code needs to explicitly go "OK, I should allow android-584fac03:my-private-app even though that's nowhere close to my actual FQDN" so that seems safe enough.
This [1] says "In fact, the spec requires that browsers only expose the API in secure contexts", so if that's correct it's better, but still not good enough.
This [2] looks like it does U2F by grabbing the challenges via browser plugin and relaying them to a phone app for signing.
Trusting the browser to "expose the API in secure contexts" seems like a failure because it's assuming nothing else can collect the credentials or send a challenge to a security key. Is that true? Could I write an app that would phish a user into signing a challenge with their security key?
1. https://security.stackexchange.com/a/206549/134291
2. https://krypt.co