Every time I read about this stuff, it makes my belly churn when the answers to questions like "how do you recover your account, if you lose your device?" are things like "they can have an extra secure password for recovery" or "they can call and provide their <insert something vulnerable to social engineering or government interference, like a 'PostIdent' - which the government actually controls>" or "bio-metric", so, basically this new standard doesn't solve any security problem whatsoever; it just makes logging in easier and account recovery more confusing.
Why not instead work on a standard that enforces password strength beyond what is economically viable for brute forcing (which is something like 6-8 chars... not exactly a tough one)? I mean, the standard could literally just be this:
A password MUST be 8+ characters in length.
Security problem solved.
Here's a comprehensive Python library for my new standard:
In all seriousness, we will need to, at some point, come to the realization that the key to authentication has always been and will always be based on a secret that only you know, whether that secret is your resting pulse combined with the color of the rabbit's foot in your left pocket, or your fingerprint, or a password, or a private key (which IS A PASSWORD).
Because your proposal is defeated by a simple keylogger, or a phishing site, or with password reuse with a compromised site, or a myriad other ways that a U2F token won't.
The answer to your original question is the same as the answer to "How do you recover your account if you lose your password?". Usually, email password resets.
Which brings you to your email account, which if protected by U2F also, means you're doubly locked out, unless you've left a backdoor to your email account, which will be vulnerable to intrusion (as well as the keylogger / phishing attacks).
Not to mention, what about the challenge step? If somebody has a keystroke logger installed, that means they have control of at least part of your machine. They can probably read the bytes of your private key and then listen for your key's password to be entered.
The solution is longer passwords and expensive hashing algorithms that render brute force attacks not economically viable. The other problems (keyloggers (read: malware) and phishing are orthogonal and need to be solved otherwise, rather than us putting bandages on the security issues caused thereby.
> The solution is longer passwords and expensive hashing algorithms that render brute force attacks not economically viable.
No it isn't, longer passwords do nothing for keyloggers.
> The other problems (keyloggers (read: malware) and phishing are orthogonal and need to be solved otherwise
They are solved otherwise. By U2F. You're saying "this solution to keyloggers is a bad solution to weak passwords, strong passwords are a better solution", but we aren't talking about strong vs weak passwords. Nobody here is talking about password brute-forcing. By all means, use stronger passwords, but they don't help with the attacks U2F helps with.
> 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.
in addition to all of those, there are still plenty of ways to create weak passwords with at least 8 characters. Dictionary words, 12345678, and so on.
You can make a smarter password strength meter, like zxcvbn[1], but its tricky and depends on many heuristics so I don't think it would be ideal for a password standard.
> "how do you recover your account, if you lose your device?"
Or the same way you recover a forgotten password: via an email containing a one-time use token, to generate a new public key pair for the web site in question.
Of course this wouldn't be much use if your email provider uses FIDO....
Why not instead work on a standard that enforces password strength beyond what is economically viable for brute forcing (which is something like 6-8 chars... not exactly a tough one)? I mean, the standard could literally just be this:
Security problem solved.Here's a comprehensive Python library for my new standard:
In all seriousness, we will need to, at some point, come to the realization that the key to authentication has always been and will always be based on a secret that only you know, whether that secret is your resting pulse combined with the color of the rabbit's foot in your left pocket, or your fingerprint, or a password, or a private key (which IS A PASSWORD).