Earlier quoted context omitted.
Yubikey recommends a backup key for that very reason. Most providers allow you to register multiple keys.
And where do you store the backup key?
In each one of my PCs and also on my key-ring is how I do it.
Apple, Google and Microsoft Commit to Expanded Support for FIDO Standard
191–200 of 525 posts
Re: Apple, Google and Microsoft Commit to Expanded Support for FIDO Standard
#192Does this provide any benefit over a (properly used) password manager?
I’d be happy with just:
- an “alphabet”, “minlength” and “maxlength” attributes on password fields so password managers generate perfect passwords every time
- a well-known URI for password managers to do zero-touch password rotation.
- actual elements for login components to close the confused deputy attack for password managers.
All these things would be much easier changes for crufty old sites to make, which would aid adoption.
Re: Apple, Google and Microsoft Commit to Expanded Support for FIDO Standard
#193Earlier quoted context omitted.
> Are there any FIDO security keys that explicitly support backing up and restoring their master secrets? Why would you need that ? On most services that I use that support FIDO, you can register as many keys as you like. Seems to me that is a much more secure option than to provide a potentially exploitable option of allowing key extraction.
I want to avoid having to fetch my backup key every time I want to setup a new account. The backup key is kept offsite and thus inconvenient. It's offsite because that protects me from fire or other such catastrophic events. This is what keeps me preferring password based security because I can backup my encrypted password database offsite with ease. Everything else provides hard path to recovery.
> I want to avoid having to fetch my backup key every time I want to setup a new account. The backup key is kept offsite and thus inconvenient.
As stated, you can have as many backup keys as you like.
Thus you are not limited to two keys.
Buy one more key. Keep one off-site and two on-prem. Rotate them once in a while to keep the off-site one fresh.
Re: Apple, Google and Microsoft Commit to Expanded Support for FIDO Standard
#194Does this imply that every service you connect to knows your unique identity?
Re: Apple, Google and Microsoft Commit to Expanded Support for FIDO Standard
#195Earlier quoted context omitted.
There's a frequent misconception that hardware keys are no better than, say, a TOTP seed on a secure element of your phone. The core practical difference between a hardware key and that TOTP code on a secure element is the hardware key, when registered with a domain, is programmed with the domain name in it. Lookalike domains - or anything besides the exact domain you registered the key with - fail to 2FA because the…
But this seems like a technological solution to a very human problem. If I can trick a user into approving the login, then hardware fobs, secure elements, etc, are meaningless. The audience here is likely to assume that the security is solid. And it probably is. But this is a technology targeting your average user. It'll certainly be easier for the end user. But it seems like it introduces a human-based attack vector…
What I mean is: with modern hardware keys you literally can't trick a user into approving a remote login, or a login to a fake domain. It's not possible unless you can control the domain that the user is logging into (say you've got code execution on their machine or compromised their network and broken TLS, attacks which are significantly more complex than phishing). Hardware keys enforce that the device can only authenticate against the real domain, not a phishing domain. The core of this is a real improvement of how 2FA works at the protocol layer, rather than simply a change to how the user interacts with the device.
Hardware keys also require that the key can only authenticate a local session, so there's also no risk that your "hardware key tap" can be captured and used by a remote adversary who doesn't control the local computer.
Re: Apple, Google and Microsoft Commit to Expanded Support for FIDO Standard
#196Earlier quoted context omitted.
Just so you don't feel alone with the replies being of the typical variety, I'm 100% with you. The flaws in the "backup token" approach are rehashed constantly but the world keeps turning as though they're irrelevant. I look forward to hardware tokens reaching a popularity level where we see implementations in software and this conversation can be rendered moot. Shout out to Mozilla and Dan Stiner for their work so f…
Software ("virtual") implementations are already possible in WebAuthn. It's up to the service whether to allow enrollment via a software authenticator; most services will want to allow this, seeing as it's still way more secure than ordinary username/password.
Are there any existing implementations I should be aware of?
Re: Apple, Google and Microsoft Commit to Expanded Support for FIDO Standard
#197Does this imply that every service you connect to knows your unique identity?
No.
Re: Apple, Google and Microsoft Commit to Expanded Support for FIDO Standard
#198Does this provide any benefit over a (properly used) password manager? I’d be happy with just: - an “alphabet”, “minlength” and “maxlength” attributes on password fields so password managers generate perfect passwords every time - a well-known URI for password managers to do zero-touch password rotation. - actual elements for login components to close the confused deputy attack for password managers. All these things…
First you need to invent a password manager that can be properly used? The one I have runs on my computer and trusts everything else I've ever installed not to have put in a mechanism to observe memory allocated to my browser.
Re: Apple, Google and Microsoft Commit to Expanded Support for FIDO Standard
#199Earlier quoted context omitted.
Just so you don't feel alone with the replies being of the typical variety, I'm 100% with you. The flaws in the "backup token" approach are rehashed constantly but the world keeps turning as though they're irrelevant. I look forward to hardware tokens reaching a popularity level where we see implementations in software and this conversation can be rendered moot. Shout out to Mozilla and Dan Stiner for their work so f…
Software ("virtual") implementations are already possible in WebAuthn. It's up to the service whether to allow enrollment via a software authenticator; most services will want to allow this, seeing as it's still way more secure than ordinary username/password.
For web apps/services, the browser needs to be involved here too, right? (And maybe the OS?) How can I tell Chrome on my desktop to use my "software token" instead of Chrome looking for a hardware token over USB or finding it via NFC, so the remote service can ultimately interact with my (virtual) token?
(I don't even want to think about how to tell Mobile Safari on my iPhone how to find my key)
EDIT: My ideal setup, I think, is an app on my phone that I can use as my token - somehow signaling to my desktop/laptop that it's nearby and can be used as a token and ideally popping up a notice on the phone lock screen when there's an authentication request so I can quickly get to it. Then in my app, I'm free to export and backup my keys for all of the sites I'm enrolled with as I see fit. I know, I know, maybe being able to export the keys makes the setup less secure, but I will trust myself not to accidentally give the backup to a phishing site. (And I do worry that I'll accidentally get phished using a TOTP app, so I'd like to switch to FIDO, but I don't want the pain of multiple keys)
Re: Apple, Google and Microsoft Commit to Expanded Support for FIDO Standard
#200Does this imply that every service you connect to knows your unique identity?
No; each site to which you authenticate gets a separate, probabilistically unique credential id.