Acceptance of FIDO 2.0 accelerates the movement to end passwords
paypal-engineering.com
paypal-engineering.com
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:
def mangeletti_safe(raw_password):
return len(raw_password) >= 8
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).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.
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.
Same if you lose your password.
> 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.
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 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.
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.
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.
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....
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?
Any insights?
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.
Does anybody know, if it would be possible to use this within a WebView in a native app?
The yubikey page is light on details, but confirms that you can use a yubikey with Google Authenticator for U2F [1].
[0] http://binaryelysium.com/blog/2011/12/13/a-reluctant-relatio...
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.
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.
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.
(If you lose the key anyway, most services currently allow you to do authentication over SMS, or use a set of backup codes.)
I think both of these options will become the standard for anything where security matters.
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.
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.
There will likely be a "I lost me U2F token" reset on websites which allow you to register a new U2F token/password.
Personally I'm not holding my breath though, people hate extra steps and don't even use password managers when companies pay for them.
In the corporate space I feel like they compete with 2FA and it's not obvious this will come out on top in most environments.
http://security.stackexchange.com/questions/43374/could-sqrl...
https://www.cl.cam.ac.uk/~fms27/papers/2014-JenkinsonSpeWarE...
What is the difference between the $5 key from Yubico to their $50 key?
If I secure GMail, how does GMail on my tablet/phone work?
Are there other keys than from Yubico recommended?
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.
See: https://www.yubico.com/products/yubikey-hardware/
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.
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.
Most people are not cognizant of these issues young or old. I don't find young people any more careful.
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 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.
No one has taken me up on that offer yet. ;_;
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.
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.
As a 43-year-old sysadmin, thanks for warning me. I better find alternate employment in the next two years.
"I'm not racist, I have a black friend."
> Why do you need to interpret things in such a black-and-white manner?
You said something absurd, so I said something absurd to highlight it.
This was a while ago and I dont have a source. The plans could have changed.
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.
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).
They would really like if all devices had some kind of UAF sensor built in.
You can get U2F devices for about 15$.
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.
Have a look at this short overview:
https://fidoalliance.org/specifications/overview/
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.
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.
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.
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.
If somebody knows more, Im all ears.
Is the plan to integrate a fingerprint sensor into the FIDO stick so it can become sufficient without passwords?