> Nobody here is talking about password brute-forcing.
Exactly. The problems being "solved" are orthogonal to password security. They are phishing and keylogger problems. Attempting (but failing) to put a bandage on one of the symptoms of these problems (stolen passwords) is not the solution.
Since you ignored the point in my last comment, I'll reiterate: U2F's supposed value pertaining keyloggers is dubious at best, because if a machine has a keylogger, then it by definition[1] has malware on it, which A) could gain access to your private key's encrypted bytes, B) listen for your "challenge" password when you enter it, and/or C) listen for all of your other private data anyway, rendering the password bits a lot less important.
Pertaining phishing, and I'm shooting from the hip here because I haven't read the whole spec, but the protection might be dubious or worse there as well. Here's why: Considering that a public key is, at best, by definition, not protected, an attacker could gain access to your public key, then ask you to connect to them, send you a verification message for you to unencrypt to verify it's really them (I assume this is how it works, unless the spec proposes a new kind of certificate authority... another problem to deal with). Assuming that's the case, then guess where we are; back at the start, since now we've got to find a way to ensure we can trust the original interaction, which leads us to an education issue (e.g., "always ensure you're connected to the correct site by checking the URL... never click from an email a link when you're first signing up using U2F... make sure you're using HTTPS").
> I'm shooting from the hip here because I haven't read the whole spec
I think it would be good if you did. An attacker can send a challenge to the user, and even get it back after signing, but it would be useless simply because each login would have a different challenge. A Man-in-the-Middle attack is possible, however.
I think malware will have a tough time getting a private key out of what is a device that is entirely separate from your computer, is a hardware security module and therefore has no writable memory. It is not possible to steal the private key, barring some catastrophic failures.
I don't think you understand what a challenge even is, if you think "listening" to it helps at all.
> A Man-in-the-Middle attack is possible, however.
Which is exactly what I'm talking about.
> a device that is entirely separate from your computer
I'm speaking about the first authenticator type in the spec, which are embedded authenticators. As we've been talking, I didn't realize (until now) that the U2F you were talking about was a physical device (rather than just a standard). The kind of computer lay people we're trying to protect won't actually carry these things around (think back to RSA - most of my programmer peers were reluctant o deal with one of these things). My understanding is that this will be primarily used as an embedded service.
> I don't think you understand what a challenge even is, if you think "listening" to it helps at all.
My mistake. I assumed this was similar to the password protecting my private key. If private keys (in the embedded authenticator) are not password protected, then we've just introduce yet another security flaw.
Exactly. The problems being "solved" are orthogonal to password security. They are phishing and keylogger problems. Attempting (but failing) to put a bandage on one of the symptoms of these problems (stolen passwords) is not the solution.
Since you ignored the point in my last comment, I'll reiterate: U2F's supposed value pertaining keyloggers is dubious at best, because if a machine has a keylogger, then it by definition[1] has malware on it, which A) could gain access to your private key's encrypted bytes, B) listen for your "challenge" password when you enter it, and/or C) listen for all of your other private data anyway, rendering the password bits a lot less important.
Pertaining phishing, and I'm shooting from the hip here because I haven't read the whole spec, but the protection might be dubious or worse there as well. Here's why: Considering that a public key is, at best, by definition, not protected, an attacker could gain access to your public key, then ask you to connect to them, send you a verification message for you to unencrypt to verify it's really them (I assume this is how it works, unless the spec proposes a new kind of certificate authority... another problem to deal with). Assuming that's the case, then guess where we are; back at the start, since now we've got to find a way to ensure we can trust the original interaction, which leads us to an education issue (e.g., "always ensure you're connected to the correct site by checking the URL... never click from an email a link when you're first signing up using U2F... make sure you're using HTTPS").