
YubiKey 5 Series with New NFC and FIDO2 Passwordless Features - ofrzeta
https://www.yubico.com/2018/09/introducing-the-yubikey-5-series-with-new-nfc-and-fido2-passwordless-features/
======
lvh
I think the YK5's biggest problem is that the YK Neo and 4, which have been
out for years, were already so good. Unless you really care about NFC at the
same time as RSA-4096, I'm not sure I see a big impetus to upgrade. Hopefully
the USB-C line won't be plagued with supply issues.

WebAuthn is mostly boring and I think that's mostly a good thing. I'm glad
that there's a way to evolve the spec. Some of the changes are arguably
improvements; I could see how Direct Anonymous Attestation is better than the
old certificate method. On the other hand, that's more exciting crypto than I
want to see in W3C specs. But the vast majority of deployments don't care
about attestation at all: they just care that you can register a specific U2F
key once (say, during employee onboarding), and then you never have to care
about attestation again. So other than crypto-nerdery, I'm going to choose not
to care much about (EC)DAA.

U2F keys already do WebAuthn (individual sites doing bogus feature detection
notwithstanding). Despite the name, at the end of the day U2F is just a way to
sign some stuff so that it can't be replayed and you can't get phished. If you
really wanted to use it as a single factor, you could.

I'm not sold that the integration of e.g. the browser's password manager into
WebAuthn is super valuable, but I'm still happily monitoring what they come up
with. That is not a criticism, and certainly not a deprecation. The bottom
line is U2F was great, and WebAuthn not convincing me yet is not a good reason
to shy away from WebAuthn. WebAuthn is still the best authentication mechanism
we (realistically) have by far. Go use it.

~~~
jolmg
> the YK Neo and 4, which have been out for years, were already so good

I agree that the keys themselves are good; I just wish that configuring Linux
systems to take advantage of them would be easier. I've been working on
setting my systems up in bits of my free time for more than a month now. I'm
in my last stretch, but I have to do some weird things. Maybe I'm just trying
to squeeze more out of the key than most would.

For example, when I'm in my laptop and I ssh to my desktop and use sudo, I
want it to use the key connected to the laptop to authenticate me. At the same
time, if I walk over to the desktop and use sudo, I want it to seek the key in
the desktop. Same if I use gpg or anything else that wants to use the key.

As part of this, to make use of the key as transparent to me as possible, I'm
finding myself making a compiled executable to override gpg and gpgconf to
unshare the mount namespace and bind mount a socket specified by environment
variable over the default gpg-agent socket, because there seems to be no
easier way to override the gpg-agent socket path via environment variable.
gnupg seems to have no such environment variable, and while other utilities
query the socket path via gpgconf, gpg itself seems to just know what it is...
You know what... I'm starting to realize that's not going to work... Programs
that query gpgconf would connect to the wrong agent. I gotta figure out how
gpg knows the gpg-agent socket path... Since it doesn't call gpgconf, I wonder
if it shares an .o file with it...

~~~
lvh
Do you care if the auth is GPG or U2F? Seems like you want -L to forward a
socket, and GPG_AGENT_INFO to point to it. I tweeted this series a while ago
because it’s hard to find how that works:
[https://twitter.com/lvh/status/966408198558244864?s=21](https://twitter.com/lvh/status/966408198558244864?s=21)

~~~
jolmg
Not U2F because it requires the systems to always have an internet connection.
I could setup an authentication server on each machine to avoid that, but I
think that would make replay attacks possible (nevermind, see EDIT). Also,
since GPG is an option for this, it means that I can just depend on that for
absolutely everything. If I break the key in two, I can use an encrypted
backup of the GPG key to keep working (authenticating, decrypting, and
signing) until I get a new yubikey and write the backup to it.

It's an -R forwarding what I want. -L would require the host I'm logging into
to automatically login back to the host I'm at. That's something that raises
way to many convoluted issues. By using -R and ControlMaster, and overriding
ssh with one that sets up the forwarding first if the corresponding control
socket does not exist, I can share the forwarding among all the ssh terminals
I've opened to the same host.

I saw GPG_AGENT_INFO on the manpage, but it says that it's an obsolete
environment variable that's now ignored. In my system, gpg2 is a symlink to
gpg. I wondered if maybe gpg decided to ignore or use GPG_AGENT_INFO depending
on $0, but from grepping the source I don't think it does. It only appears on
documentation and automated tests. Still, it might be a good starting point to
check the source of gpg 1.4 to get an idea of how to patch gpg2 to get the
agent path from an environment variable. Thanks for the help.

EDIT: I made the U2F comment assuming that it works like OTP, but there is
some material online referring to it as a protocol using a challenge-response
mechanism. If that's the case, what I said would be false. Still, I feel I'm
close to an ideal with GPG, so I'm not sure there would be something to gain
by using U2F. Unfortunately, most of the material online about it is about
using it to login to specific web services like Google.

EDIT 2: I was taking a quick look at pam-u2f[1], and I found this piece
interesting:

> manual: Set to drop to a manual console where challenges are printed on
> screen and response read from standard input. Useful for debugging and SSH
> sessions without U2F-support from the SSH client/server. If enabled,
> interactive mode becomes redundant and has no effect.

I imagine this is in consideration with U2F keys that come with a keypad.
Otherwise, terminal emulators would have to be extended to support an escape
sequence with which it could recognize when a challenge has been presented to
automatically pass it on to the key connected.

EDIT 3: Extending my terminal emulator like that and using pam-u2f (after
extending it to use that escape sequence) would eventually lead to solving the
problem of using sudo remotely. However, going the route of forwarding my gpg-
agent also allows me to use gpg (and dependents like pass) remotely. It also
seems relatively easier since the only step left for me to figure out is how
to get gpg to accept the agent socket path via environment variable.

EDIT 4: On "U2F-support from the SSH client/server", I don't suppose adding an
authentication method like that would work when chaining ssh interactively
(calling ssh to another machine from a ssh session), like how you can forward
ssh agents with -A. I wonder if it's possible to add U2F support to ssh
agents. I imagine the agent works on a challenge-response mechanism too, in a
sense. Maybe the agent can be made to work like a proxy to the key. That way,
-A can be made to work to forward authentication to the key.

[1]
[https://developers.yubico.com/pam-u2f/](https://developers.yubico.com/pam-u2f/)

~~~
jolmg
EDIT 5 (can't edit anymore :( ): I imagine that's what gpg-agent does when
working as a ssh-agent, and the ssh server has a public key corresponding to
the openpgp card that would be the yubikey. Really, U2F seems to do a subset
of what PGP can do.

------
nikanj
I have an iPhone and a Macbook. It's frustrating that I have to choose between
USB-C support for the Macbook, and NFC support for the phone. It's odd that
they don't make a USB-C version with NFC.

~~~
Alex3917
The 5C nano is designed to be plugged in the all the time though, so in that
scenario what do you really gain from NFC?

~~~
lvh
Because one day we'd like to securely authenticate to things on phones in
phone browsers. (I agree that it's not a big a deal as one may think; it only
matters if you're logging in to a critical service via the browser and not the
app. If you're using the app, it's the app's problem to make sure that you're
talking to the Correct Service(TM), so phishing concerns go away.)

~~~
scient
BLE solutions are going to work much better for mobile devices than NFC I
think. Google already supports it for their apps via SmartLock and Advanced
Protection on both major mobile platforms. Its the browsers, and namely
Safari, thats being the blocker on iOS right now - both for NFC and BLE
solutions.

~~~
Boulth
> BLE solutions are going to work much better for mobile devices than NFC I
> think

Yubico would disagree. According to their research studies BLE devices are
harder to use and less robust.

Source: [https://www.yubico.com/2016/06/yubikey-u2f-tracking-
bluetoot...](https://www.yubico.com/2016/06/yubikey-u2f-tracking-bluetooth-
maturity/)

------
nikolay
Just to warn you - although you can put Yubikey 5C on a keychain, it's not
robust, and the plastic disintegrates after light use in just months. I had
two that got destroyed. Unlike the USB-A, which are highly resilient to wear,
the USB-C version are greatly subpar! Given how expensive this is and how
important is, it's highly disappointing that they didn't put more thought into
the material selection process! Or maybe that was the main idea - make you buy
a new key every year.

~~~
eldridgea
Just so you know - I had the same problem but emailed Yubico recently and they
said they made some changes because of this defect and sent me a new one for
free. It's been at least 2 months and there's been no degradation like my
first one.

~~~
nikolay
Thanks for the info! I'm glad that fixed this. I will reach out to them today
as I migrated off the old key long ago. If they replace it, I will give it to
my 10-year-old son, who uses my old keys. :)

------
cflee
Technical Manual at
[https://support.yubico.com/support/solutions/articles/150000...](https://support.yubico.com/support/solutions/articles/15000014219-yubikey-5-series-
technical-manual):

> Like FIDO U2F, the FIDO2 standard offers the same high level of security, as
> it is based on public key cryptography. In addition to providing unphishable
> two-factor authentication, the FIDO2 application on the YubiKey allows for
> the storage of resident credentials. As the resident credentials can store
> the username and other data, this allows for truly passwordless
> authentication. YubiKey 5 Series devices can hold up to 25 resident keys. If
> RSA keys are used, there is a maximum of three RSA with the rest being ECC.

I wonder what the user experience will be like at 25 resident keys, they
mention that the YubiKey Manager (ykman) can set/change FIDO2 PIN and reset
FIDO entirely, but nothing about managing individual resident
keys/credentials.

It seems like it might be a bit challenging to manage this, especially if end-
users accidentally register the authenticator multiple times or run out of the
25 slots for some other reason, and be told that they need to reset the whole
authenticator and do recovery for all their sites...

~~~
GoMonad
My understanding is that for udf / fido2 authentication, keys are not stored
but rather regenerated with an HMAC

[https://developers.yubico.com/U2F/Protocol_details/Key_gener...](https://developers.yubico.com/U2F/Protocol_details/Key_generation.html)

I'm curious what these resident keys are for.

~~~
lvh
The spec doesn't insist on it, but that's how Yubico devices do it, yes. It's
the straightforward thing to do when your scheme eventually relies on ECDH and
there's an obvious and performant way to go from a base secret to a specific-
use secret (via a KDF, here HMAC) to a public key (via scalarmult). It'd be
less straightforward if your key generation is expensive and complicated.

~~~
GoMonad
If I'm understand correctly, the resident keys can be used in the case of a
non-ECDH scheme and otherwise they wouldn't be used? How flexible is the FIDO2
specification on crypto schemes?

~~~
lvh
I don't understand what you're saying. Which resident keys?

WebAuthn adds a number of crypto schemes -- to wit, I think they add RSA. You
can certainly deterministically generate RSA keys but it's a lot more of a
pain in the neck than x = HMAC(k, "u2f" \+ custom); P = xG :)

~~~
GoMonad
In the parent comment link to the technical manual it mentions 25 resident
keys can be stored.

It is now starting to make sense to me why. As jiveturkey pointed out, it
allows usernames to be stored. And, as you're pointing out, it's useful for
RSA or maybe other crypto. Thanks.

------
lambada
Flicking between the comparison tables at
[https://www.yubico.com/products/yubikey-hardware/compare-
yub...](https://www.yubico.com/products/yubikey-hardware/compare-yubikeys/)
and [https://www.yubico.com/products/yubikey-hardware/compare-
yub...](https://www.yubico.com/products/yubikey-hardware/compare-
yubikey-4-neo/)

it appears like the only differences between YubiKey 4 and Yubikey 5 NFC is i)
the addition of NFC and ii) the addition of FIDO 2 support

The differences between Yubikey NEO and YubiKey 5 NFC appear to be i) The
addition of docker login support (?!); ii) FIDO 2; iii) RSA 4096 (PGP) support
and iv) ECC p384 (not in PGP) support.

With that in mind.... how widely is FIDO2 deployed? I haven't yet found a two
factor app supporting app/site that doesn't support my Yubikey 4.

~~~
arusahni
IIRC the NEO only does TOTP over NFC. It sounds like the 5 does U2F over NFC,
now?

~~~
lambada
Oh, interesting! That's not called out on their comparison chart for the NEO.
That would certainly be a tempting upgrade for any NEO users then

~~~
anilakar
Now I've only got one problem remaining: how do I upgrade my old U2F-capable
NEO on all the websites? Do I have to keep it with me ad infinitum? I cannot
really destroy it either, as I cannot be 100 % sure I've remembered to enroll
my new Yubikey 5.

This raises a more generic question: What's the proper upgrade path for
hardware authentication tokens?

~~~
albuic
> This raises a more generic question: What's the proper upgrade path for
> hardware authentication tokens?

This is the reason why I'm still using only a password manager. I agree that a
hardware token more security but the lost/stolen/change key problem is really
not easy right now.

I hope there will be a new common API to change all enrollment you have done
but it seems hard as the key don't even know them.

Maybe in a future version ?

------
Latty
It is annoying you have to choose between USB-C and NFC. I was really hoping I
could have both in a new device.

I have a 4C and think it is great - the only downside is the lack of NFC and
that only a subset of sites support it, but more are implementing it as time
goes on.

I'll probably pick up a 5 as one to store on a keyring for mostly NFC use.

~~~
ecesena
Just replied in another thread: it's a few months away, but we'll have usb-c +
nfc in Solo (open source security key supporting FIDO2). We'll launch the
Kickstarter next week: [https://solokeys.com](https://solokeys.com)

~~~
LyndsySimon
Interesting. This solves about half of my problems.

I use four devices regularly: a Windows desktop with USB, an MBP with USB-C, a
6th Gen iPad (Lightning), and an iPhone X (Lightning + NFC).

What I'd really like to see is a small device that lets me use USB, USB-C,
Lightning, or NFC with the same token without a handful of dongles to deal
with. I get how difficult that is, but I've yet to see anything that supports
more than one physical standard. Even USB and USB-C in the same device would
solve most of my problem, leaving only my iPad to deal with a dongle due to
its lack of NFC.

~~~
ecesena
As of today most people seem to want a hole to attach it to a keyring. So it's
kind of hard to have even usb-a on one side and usb-c on the other side. Let
alone lightning.

If you want to give it a try, we'll open source the hardware soon under CC BY-
SA. It'd be great to see what you come up with.

------
hsivonen
Is there an "explain like I'm 5" intro to FIDO2 that explains how FIDO2 as the
single factor is more secure than the user entering username (not password)
and then using a CTAP1 token? (Also, how do you log in to multiple accounts on
the same service with FIDO2?)

How many usernames can a Yubikey 5 remember in the FIDO2 mode? CTAP1 requires
no storage beyond a token-wide counter.

------
kevin_b_er
We'll see. There was barely any uptake of FIDO U2F on the web. Sure there were
a few major players, like google, but pretty much nothing financial for the
public have taken up anything but insecure SMS/call authentication.

Meanwhile telcos are working hard to convince the public they should all throw
in with their insecure telecos accounts as a chain of trust after time and
time again showing that your telco account is trivial to steal.

Not convinced on FIDO2, either. It means you need TWO of these devices. One as
a backup and another as the common case. Why? Because if you lose a single
physical key, you'd have to recover your account. Recovering your account will
probably end up being insecure SMS auth or easily socially engineered below-
US-min-wage outsourced phone support.

~~~
lvh
Some actors doing unsafe things should not preclude us from building safe
things in the mean while. Google/GSuite accounts matter. GitHub accounts
matter.

~~~
kevin_b_er
The problem is that if poor solutions as far as usability are present, you'll
have the telecos win.

This is a race against Mobile Authentication Taskforce and their fundamentally
insecure accounts. If the solution can't beat them, it'll get trampled.

Those other "unsafe actors" are trying to completely take over authentication,
meanwhile you need 2 $50 hardware security keys at a minimum to safely use
this tech. This will lose on consumer pricing and consumer uptake to the
insecure Mobile Authentication Taskforce and you won't GET the option to use a
FIDO2, because you'll have the choice of insecure mobile auth or nothing.

You have to win against the public or they'll be suckered by bad and insecure
authentication that is easier to use, and the things you want to use will be
insecure anyways.

~~~
tialaramex
You don't need $50 products. You especially don't need two of them.

Yubico already make a Security Key that isn't also a PGP key store, a TOTP
authenticator, bagel toaster and whatever else for about $20. And there are
cheaper vendors if price is the main concern.

~~~
mercutio2
Why do you say you don’t need two?

The argument seems pretty straightforward: if you don’t trust SMS, you need to
disable all backup authentication. If you’ve disabled backup, you surely don’t
your physical device to be a single point of failure?

~~~
tialaramex
My point was that your backup "emergency" token doesn't need all the fancy
features of the 5 series.

It's the backup option, it's the reserve, it didn't have to be the best
possible thing, just enough to get you back into the game after you lose the
main token somehow.

------
walkingolof
Honest question, what happens when you lose one of these ?

~~~
kyrra
For 2FA, having multiple of these or some kind of recovery code tends to be
the answer, as you can remove the keys from sites you use it on.

I am less willing to use something like this for passwordless logins. These
types of devices should be part of the "something you have" part of 2FA, which
should always be paired with a "something you know".

Maybe I'm missing a step here, but why would you ever use this for
passwordless?

~~~
lugg
Because the something you know part isn't all that secure anyway?

[https://xkcd.com/538/](https://xkcd.com/538/)

~~~
bluGill
it is a different level of security. The comic is fully correct, but you
should still use a secret. That is why there are 3 different types of
authentication. The first is something you have - a card or key. The second is
something you know - a password. The third is something you are - a
fingerprint. Each provides protection against a different attack and is
vulnerable to different attacks. The more important the secret the more of
them you should use.

Note that you quickly get to the point where you need more than one person
involved. You can compromise one person as much as you want, but if that
person doesn't have the complete secret it doesn't do any good.

~~~
dragonwriter
> The third is something you are - a fingerprint.

A fingerprint isn't “something you are”, because it can be destroyed while you
remain, and information about it can be captured and reproduced by attackers
who are not you.

It's just a particularly hard to lose (but easy to discover, and impractical
to replace if compromised, at least more times than you have fingers)
“something you have.” In security factor terms, I'm not convinced the idea of
a distinct “something you are” category is coherent, since most candidates
seem similar to that.

~~~
bluGill
DNA is something you are.

~~~
dragonwriter
The reason DNA is useful as criminal evidence is you leave it everywhere; that
makes it a horrible security factor: like fingerprints it's an impractical to
replace wheb compromised “thing you have” that you leave everywhere for
attackers.

~~~
bluGill
That is a very good reason to not use it alone. However when combined with
other it provides a good indication that someone was actually there. Either
that, or the attacker went through more effort to get the secrets.

------
nogridbag
I'm a LastPass user using Yubikey nanos for both my work and home PCs. But I
would like to purchase a Windows 2-in-1 that only has a single USB-C port used
for charging and thus a nano wouldn't really work out well. Since Yubikeys,
including these latest 5 series, do not support bluetooth, most Windows
laptops don't support NFC, and LastPass does not support FIDO/U2F (so Google's
Titan bluetooth won't work), is my only option to unplug the charger, plug in
the USB-C Yubikey, and plug the charger back in every time I want to log into
LastPass? I'm kind of an end user with this sort of stuff...

~~~
sbr464
LastPass Enterprise supports Duo, which then allows you to use FIDO/UTF there
if you enable in the DUO admin panel.

~~~
lrvick
SMS as a 2FA method can't be disabled for Duo administrators. Sim takeover or
GSM sniffing attacks can take over the whole account. Mentioned this to their
support many times. They don't care.

~~~
sbr464
Interesting, didn’t know that

------
vader1
The difference between WebAuthn and U2F isn't really clear to me, but I hope
the older generations will continue to work with common browser's FIDO2
implementations for a long time to come. YubiKeys are great, but too expensive
to replace on a whim every year.

~~~
StavrosK
U2F can only be used as a second factor. FIDO2 can be used as a replacement
for a username/password, so you can go to a site, insert your FIDO2 key and
log in without any other information.

Old Yubikeys only support U2F, and there's a Yubico FIDO2 key. Browser support
isn't there yet, I've been trying to write a Django library for it but no
browser will support the complete FIDO2 flow as far as I know.

~~~
vader1
Ah, that's perfect. A hardware token as the /only/ factor sounds like a bridge
too far anyhow.

~~~
StavrosK
I don't know, it sounds perfect to me.

------
theli0nheart
This is fantastic! I'm super psyched about this.

> _Works on Microsoft Windows, macOS, Linux and on major browsers such as
> Chrome, Firefox, Safari, Edge, and Opera_ [1]

I looked everywhere for documentation of Safari support but came up empty-
handed. Does anyone know where this is documented? I've been waiting for this
since forever.

[1]:
[https://www.yubico.com/product/yubikey-5-nfc/](https://www.yubico.com/product/yubikey-5-nfc/)

~~~
tstevens
Looks like Webauthn support is being added to Safari.

[https://bugs.webkit.org/show_bug.cgi?id=181943](https://bugs.webkit.org/show_bug.cgi?id=181943)

~~~
theli0nheart
Great find, thank you! This is exactly what I was looking for. Weird that it's
nowhere to be found in the Safari 12 release notes.

~~~
tstevens
I don't believe support is in 12, I think it will be coming in a future
release.

~~~
theli0nheart
Hmm. Yubico claims Safari support exists right now on their sales page.

------
Ajedi32
Isn't WebAuthn backwards-compatible with FIDO 1? I was under the impression
that it was (based on some of the things I read in the WebAuthn spec).

~~~
ecesena
Yes, it. In fact most browser currently still implement U2F.

------
Leace
Wow, this looks really cool. Yubikey 4 lacked NFC support so with 5 it's easy
to use the same key via USB-A (laptop) and NFC (via OpenKeychain on Android).

It appears that RSA 4096 keys can be used via NFC, no other NFC-capable keys
have this.

One issue is that the algorithms did not change compared to 4. No ed25519,
probably due to no tamper-resistant parts with this on the market.

~~~
georgyo
Also the highest ECC is still p384 and does not support p521.

However it is still really nice that it support rsa 4096 over NFC now.

~~~
mtgx
I'd rather they support X25519 and X448 anyway.

~~~
watersb
Maybe their FIPS-140 certification prioritized the NIST curves? (speculation)

------
m-p-3
Glad they brought back NFC, I had to choose between NFC (Yubikey Neo) or 4096
PGP keys (Yubikey 4).

I went with the 4.

~~~
Snawoot
I had same dilemma. I hope one day I'll be capable to read securely encrypted
emails on my phone.

------
village-idiot
I’ve always been fascinated by these, but never had a justifiable reason to
get one.

The only use I could think of was protecting my LastPass account, but I
figured my main risk there is their security getting breached, which Yubico
wouldn’t help with.

~~~
fabian2k
I have one of the old blue U2F tokens (~20 EUR), and pretty much only used it
for GMail so far. That alone is worth it to me because many other passwords
can be reset by someone that gains control over my email account.

I personally find the token much more convenient than a TOTP code via app on
my smartphone. And the U2F/FIDO part is very interesting as it eliminates
phishing as a risk.

I ordered a Yubikey 5 NFC just now to play around especially with the NFC part
and see if I can do something useful on my phone with that. I'm still looking
for a password manager that could use an NFC Yubikey to unlock it on a
smartphone.

~~~
digianarchist
> And the U2F/FIDO part is very interesting as it eliminates phishing as a
> risk.

How does that work? Can't the challenge response be MITM?

~~~
r3dey3
The browser sends the domain as part of the request to the U2F key; so a MITM
would need to be a true network-level MITM and not just a fake website MITM.
The user would then have to ignore the cert error as well.

I'm not saying it's not impossible, but the it's not the primary attack U2F is
designed to prevent.

------
methou
Wonder what version openpgp their applet support, current app on Yubikey 4 and
prior versions doesn't support ECC.

~~~
zyberzero
This doesn't do it either [0], unfortunately :(

[0] [https://www.yubico.com/products/yubikey-hardware/compare-
yub...](https://www.yubico.com/products/yubikey-hardware/compare-yubikeys/) \-
"ECC applies to the smart card applet only; does not apply to the OpenPGP
applet. ECC P256 is the key type generated for the U2F keypair."

------
cmurf
How many e.g. gmail accounts can be supported on a single key? I've got
probably five gmail accounts.

~~~
emlun
Unlimited! Except for passwordless credentials, which do consume storage space
aboard the device. But second factor (U2F style) credentials are stored
encrypted on the server, so there's unlimited "space" for them.

------
pibefision
I look forward for a more robust and durable hardware design. Maybe a
ruggerized version?

~~~
georgyo
I don't know how much more ruggerized you need it. It's already pretty dam
strong. I've had a neo on my keys for years and it shows no sign of ware.

They already are water proof and can be run over by a car. So unless you want
to take a hammer to it, it should be rugged enough.

~~~
mtgx
I'd be more concerned about general reliability. How long will these last?
Because I think they should last at a minimum 10 years. If you only use one
for an account, and it breaks on you, you're screwed.

So I would use at least 2, but hopefully websites will allow this, and that
will probably be the largest bottleneck in the future. I couldn't care less
about "SMS backups" or such nonsense, as that completely defeats the point of
using a hardware token. Your account will only be as secure as your phone
number is.

~~~
zjs
I configure a second YubiKey as a backup, and disabled SMS-based recovery
where possible.

Many sites allow this explicitly, and will let you view details about the last
time each key was used to log in.

Some sites that use TOTP only allow for one "authenticator" to be configured.
In those cases, I scan the same QR code into each key.

This process requires you to retrieve your backup key from whatever safe place
you store it in when configuring 2FA on new accounts, but that feels like a
reasonable trade-off; I don't make new accounts very often, and when I do I
can wait to configure 2FA until I have access to my backup key.

------
TACIXAT
Could a username + U2F token be used as authentication?

~~~
emlun
If the server allows it, sure.

------
nikolay
I just tried to order one. My credit card got charged twice as I attempted
twice, got errors on their website, and the customer service rep Rachel in the
online chat is behaving highly unprofessionally. My other attempts with
another card were flagged as a possible fraud - obviously, their reputation
among the credit card processors is not stellar. I think I'm done with Yubico
and will be waiting for my Titan key from Google and consider the open-source
SoloKeys as well. I think I've invested enough money in Yubico and what I'm
getting back is not enough to justify the costs of this luxury. Their
shortsightedness not to offer NFC on the USB-C version and to make the 4C/5C
Nano so extremely hard to pull out is a clear sign they no longer are a good
choice. And for quite some time, they haven't been the only choice either.

