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....
I really like the Fido U2F concept, because it ticks all the right boxes; simple to use, reusable for multiple services without being traceable, multiple hardware vendors, open standard, soon implement in Chrome, Firefox, and Edge (although I am not sure about the status in Edge right now), and cheap.
But this solves logging in with a browser. I have been wondering about things like IMAP for e-mail access. To secure my mail a second factor sounds great, but right now all solutions mean I get 2FA when I log in with a browser, but as soon as I use an e-mail client I am back to username and password (application-specific or otherwise).
Ideally, Fido U2F would be an option to use with IMAP and SMTP as well, so that Thunderbird, Outlook, or Apple Mail can prompt me to touch the U2F key when I get my mail. I have not been able to find much information on this approach yet though. Is it possible? Desirable?
Nothing probits using UAF/U2F for other stuff outside web browsers. The problem is that the concept of "AppId" is not clearly defined in non Web Application but that should not stop people form doing it. Yubico has Open Source code that makes it relativly easy.
Its a very cool feature, I agree, sadly making pam_u2f work for SSH is quite a hack. Their is a patch for OpenSSH but it never went upstream. I really hope this will be work soon.
The client-side code and the standard are fairly trivial to implement — thanks to Yubico as well — but the problem lies in designing and standardising an extension to the existing mail protocols, and getting that accepted as a common feature for e-mail providers (such as Google and Microsoft) and a common feature in MTAs and MDAs.
I've been considering getting a Yubico for awhile now, but my concern is that it seems like every few months some new model comes out that supports new XYZ Standard. I'd really want the following before I bite:
1) The security community on the whole needs to come to a consensus on what is going to be used. If FIDO 2.0 is it, cool, but I'd like to be sure that they won't say "FIDO 2.0 in 2016, now and forever." then come back in 2017 and say "Actually FIDO sucks, we're all switching to ARGUS now."
2) The device should be future-proof, insofar as it would be able to support the agreed upon standard in Step 1 and/or any minor changes that might come along the way without having to dump the device. IF the device must be swapped for a newer version, there should be some way to migrate.
3) Compatibility with all of my devices--major browsers, major OS's, smartphone, etc.
Might be a tall order, but until it can be filled, LastPass + 2FA on my Android phone is good enough for me.
I was suprised that when signing in to my Goole account on my Android device with Chrome Beta, the Google Authenticator App pops up to do U2F with my YubiKey NEO via NFC. That was really seamless!
Does anybody know, if it would be possible to use this within a WebView in a native app?
I use the 'Yubico Authenticator' (like Google Authenticator but you have to connect to the Yubikey via NFC for it to reveal your login codes) if I need OATH-TOTP, this has nothing to do with U2F.
However the docs in your second link does indicate that their is some new interoperation between Google Authenticator and U2F. It seams that they use Google Authenticator as a stopgap until browser support the system directly. Pretty strange. This in turn has nothing to do with U2F.
I can not test this stuff very well because I use a Yubikey NEO that is to old for the U2F NFC and a Yubikey 4 that has no NFC. I really hope release a Yubikey 4 with NFC soon.
In Germany every service that you can sign up for online but requires proof of who you are uses something called "PostIdent" -- and its a service offered by the post office where you take the form in with your passport (or ID card) and they punch all the details in the computer and 'verify' it's you. In a (more) secure future, I see this being the real password recovery mechanism. The other technique used by online banks etc... is to send your password reset to you by mail. This assumes that physical mail to your registered address is more secure than online quizzes.
I think both of these options will become the standard for anything where security matters.
This is a good idea,and I too can see it happening in the future.
A few problems though:
1) PostIdent isn't free. You might not be paying for it, but someone is. Also that random forum you signed up for in Singapore? Doubt they're going to support password recovery via PostIdent.
2) What happens if you need to reset your login while you're travelling. I have had it happen before that a password is forgotten or not available and I really need to login (e.g. to retrieve the ticket) and a password reset to my email address is the most expedient method.
Since about half a year video ident is gaining traktion, which is basically the same but via video chat. Still not free but probably cheaper, less effort on your side and usable while travelling (as long as you don't loose your passport).
I think Revolut and some other services even use the NFC chip in passports (yes, it can be read by regular smartphones) to identify you almost automatically.
The major services that support U2F authentication now (Google, GitHub, Dropbox) allow you to associate multiple U2F keys. So, let people associate their primary key and a backup key. The keys themselves are so cheap, that they could probably be shipped with cereal boxes in a few years ;).
(If you lose the key anyway, most services currently allow you to do authentication over SMS, or use a set of backup codes.)
Such backup codes are probably the safest way to go about this. A sheet of codes that you print or write out on a piece of paper and store with your valuables.
You cannot be secure while offering easy 'backdoors' into your own account at the same time. People will just have to be more careful (e.g. by associating a backup U2F key with their account), or go through a real-world ID process otherwise (like banks typically do).
Also, for the coming years, U2F will probably just be an optional second factor like TOTP. One can only hope that more sites will follow the lead of GitHub, Dropbox, and Google, because TOTP is worthless against 'real-time' phishing attacks.
> You cannot be secure while offering easy 'backdoors' into your own account at the same time. People will just have to be more careful (e.g. by associating a backup U2F key with their account), or go through a real-world ID process otherwise (like banks typically do).
Sure, but by that logic the most secure system is offline. It's the same issue with corporate networks requiring "complex" passwords and changing of them once a month. Sure, it's technically more secure, but the end result is the office genpop writes a post-it with their current password which defeats the whole purpose.
The most secure real-world system is the one you can keep using with its designed security solutions, regardless of its (low) theoretical security level.
The real problem isn't even Firefox's lack of support. There's an addon you can install that implements it but literally every website seems to do a useragent check, so it doesn't work anyway :-(
Fido U2F support is currently in development by Mozilla for Firefox. See the last post of that bug, or look for the U2F discussions on the Firefox mailing lists if you want to find out more about the current status.
SQRL has been in development for years, not officially released yet. Right now they are in polishing phase and making sure no major flaws exist. So, what changed? Nothing. Once SQRL is officially released, it has the potential to take on FIDO and others.
Unfortunately, SQRL has been in development by a small group of people in a tightly controlled development cycle. I don't want it to continue to be vaporware as it seems like it'd be an awesome solution and competitor, but you are right that FIDO is more likely to be adopted. It's possible that SQRL could affect FIDO's development in positive ways nonetheless.
Shame the top answer is so jealous of Gibson, who isn't always right (who is?) but have never heard him boastful or say an unkind word as the links allege.
The cheap keys support way less features. The are simple U2F tokens and cant do anything else.
The others support tons of other features. You can use them for classic 2FA with OTP (TOPT/HOTP/YubiCloud OTP). They support using your Yubikey as a Smartcard, you can put your 4k GPG key setup into your Yubikey. They also support the PIV interface and you can use it for lots of different operations, like code signing, certificate authority, windows authentication and more.
Some of the sticks support NFC. This means you can use Smartcard, PIV and U2F over NFC.
Sadly at the moment they have no key that supports 4k GPG Keys AND NFC. However they will update this soonish.
There are also older models that you can still buy that don't support U2F at all.
> Are there other keys than from Yubico recommended?
Their are others, just search for U2F on amazon, seems their are at least 4 companies implementing them. Nitrokey is a pretty cool company with a interesting option that are somewhat different from Yubikey.
I support the movement to end passwords. For the average user, passwords are as insecure as they can get.
My (non-technical) family members keep using their birth dates, phone numbers etc as their passwords. I told them this is insecure, that they should use long random passwords, but their response is "I can't remember that". So I suggested writing it down, but they find that too much hassle. I managed to convince them to do it for some passwords, but they keep losing the paper (they just tuck away the paper somewhere and then forget where it is). Furthermore, they don't have computers, they ONLY use mobile devices, on which long passwords are awkward to type. So they revert to using phone numbers and passwords, with the attitude of "I'm not an important enough target, and if a hacker really targets me I am screwed anyway".
Some of them have difficulty grasping the concept of multiple passwords. To them, it's just "the Internet needs a password". If I explain to them that each website is a different vendor, they get confused. Just remembering which login username to use for a specific website (or whether it is a username or an emailaddress-as-a-username) is already difficult enough for them.
Mind you, we are talking about people older than 45. They have trouble using computers (even phones!) as-is, even before we get to the security part.
I ended up becoming their password store for their most important accounts. I setup random passwords for them, then when they need to do something (a few times per year) they have me login and do it for them.
The average user doesn't care enough about online security to really do something about it. They don't understand, or acknowledge, the risks. So we need to do everything we can to make security convenient.
> Mind you, we are talking about people older than 45.
I wish we could drop the casual ageism, age has nothing to do with it. You might as well tell me they're left-handed and that's why they can't "do" passwords. Difficult enough already (in social terms) without the blanket presumption we're all non-compos mentis as well.
And I wish that we could stop focussing on the ageism, as if that's the most important point or whether it's even a negative point. I used ageism to reinforce the notion that we should try harder to push for convenient security. It wasn't meant in a pejorative way.
Maybe your point was that ageism isn't acceptable in any form. We'll have to disagree there. I agree that pejorative ageism isn't acceptable, but doing away with ageism entirely is pretending that something real doesn't exist. Sure, not all young people are computer geniuses, and not all old people are computer illiterate -- I never said that, but that doesn't matter because focusing on that just detracts from the core point I was trying to make.
That's true, many non-technical friends I have around my age are not at all careful. But at least I've never encountered someone who thinks in terms of "the Internet needs a password" and confuses different accounts with each other. But frankly, it doesn't matter: I only mentioned age to reinforce to the reader that it is a real problem that deserves recognition and that we should try harder to do away with passwords and to strive for convenient security.
> Mind you, we are talking about people older than 45. They have trouble using computers (even phones!) as-is, even before we get to the security part.
As a 43-year-old sysadmin, thanks for warning me. I better find alternate employment in the next two years.
I wasn't talking about you, nor did I say all old people are bad at computers. When I said "they" I meant my family members, not the set of all people over 45. My accountant is over 45 and can use computers just fine. Why do you need to interpret things in such a black-and-white manner?
You set up a master password, but you don't really have to remember it: you can use a shorter PIN to unlock LastPass. (The phone itself acts as the second factor.)
I think you have to enter the full master password whenever you reboot the phone. But that shouldn't be too often.
I don't think I can teach them how to use LastPass if many of them already can't differentiate between accounts and just think of everything as "the Internet".
I can sympathize. Over Christmas I literally got my entire family into a room and used the TV as a projector with a Chromecast and walked everybody through why passwords are bad, why using the same password over and over on every site is REALLY bad, and why they should switch to a password manager like LastPass.
I even offered anyone who wanted to set one up to give me a call any time and I would remote in via TeamViewer and literally set it up FOR them.
So instead of a KeePass with a long random password for each site, I'll have a KeePass with key pairs for each site.
The added security being that if the site gets compromised, they can't log into the site using my account. But then again the site is already compromised at that point.
If you already use random passwords you get less security benefits, but you still get a lot of them.
The additional security happens if you consider MITM attacks. Assume that you want to login to https://mybank.com but somebody links you to http://mybank.com (bad dns) or https://mybank.co. With UAF or U2F the local authenticator will not sign anything (and thus the attacker can not login to your actual bank).
Now admittedly you browser plugin might warn you in some cases. However you might copy in the password by hand because you think its some kind of problem with the plug in.
The usability is of course improved as well. Their should be no need for a password manager at all. Go to the website, put your finger on the sensor and your done (or whatever other local authenticator you use).
I started using algorithmic passwords a year or two ago and it has been great. I have a different password for every domain, there is nothing to remember, and it is hard to crack. I just tested my password on this demo and got a four out of four score. I know others have done this but I don't know why it isn't discussed, or better yet, recommended more.
Well the idea is that you use the fingerprint sensor on your phone to login while browsing with your phone. You can have a fingerprint sensor on your laptop. Alternativly these could also be cheap external devices that you connect over USB, NFC or Bluetooth LE (their are already standards for this).
They would really like if all devices had some kind of UAF sensor built in.
Cool, bit of googling and found 'FIDO U2F Security Key' (USB) for £5 I expect those will turn up in our local supermarkets pretty soon.
Someone should give these hardware keys a better name. E.g. your "Privacy Lock" or something similar. Much easier to explain than a "FIDO U2F" ... whatever those letters all jumbled together mean.
UAF is authentication by means of a local device with some biometric authentication factor. U2F uses a separate hardware token that can be used via USB, NFC, or Bluetooth LE — so basically, any modern computing device.
Please be sure to avoid saying UAF needs a "biometric" authenticator. Thats not really the case, you can use any device or potentially even software, for example an external devices where you have to enter your pin or password.
I think this is importend because way to often people say "UAF isch shity because biometric authentification is bad" and thus completly mis the point of the hole concept.
I do get the impression UAF is targeted mostly as a biometric authentication system — which I indeed dislike, so I do see your point. Perhaps the confusion stems from the UAF/U2F split and the examples shown.
It is true that Fido itself always uses biometric as an example. The casual finger print sensors on all phones and laptops will probebly be the most widly deployed authenticator.
Biometric authentication companies are part of the support base for the Fido Alliance and they always push Biometric into the front as well. There seems to be no company that is about to release a pin or password hardware authenticator that could advocate for the alternative.
Also the press loves the hole 'remove passwords' storyline.
Only for Fido UAF though. Fido U2F also attains the goal of reducing the knowledge factor to a PIN or something similar, but does this by employing discrete hardware tokens as the possession factor.
Could someone explain how FIDO 2.0 fits in with U2F and UAF? I'm having a bit of trouble understanding how the pieces go together. Does FIDO 2.0 make the existing U2F and UAF specs obsolete? Is there any documentation explaining this (maybe I've missed it?). Thanks.
I have been following this for a while and I don't get it completly.
UAF/U2F are FIDO1.0 standards. As I understand the idea is that FIDO2.0 standards build on these basic blocks and add additional features. I think the problem of revoking a device accross all services is something they want to work on in 2.0.
Im also confused, but I think the UAF/U2F standards should not get depreciated with FIDO2.0.
So I bought one of those FIDO USB sticks, but when I tested it on GitHub or Google, I still had to enter my account password. So, how is this better than 2FA via smartphone SMS?
Is the plan to integrate a fingerprint sensor into the FIDO stick so it can become sufficient without passwords?
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).