Yubico Forum

I've been using YubiKey for several years now. I found out about it because Fastmail, my email provider, supported it for 2-factor authentication. "YubiKey, what's that?" Read about it, ordered some, and never looked back.

I have since installed the Linux PAM module on my remote servers (so SSH requires YubiKey), and even coded support into my own PHP game servers (so the admin login requires YubiKey).

And that's the thing... it's SO simple! Anything that can receive keyboard input and execute a simple HTTP request can leverage it. It's like 3 lines of code, no libraries needed.

Now I'm reading about U2F and YubiKey4 and Google's support.... and I'm kinda scratching my head. It's so much more complicated. All this back-and-forth. And the whole "it's just a keyboard" is out the window, because it sounds like you need to use a special web browser with drivers that does 2-way communication over USB with your YubiKey. Challenge-response...

My question: why is this necessary? Yes, I get that the old YubiKey effectively provides its own challenge (the sequence number that it signs) and includes it in the clear with what is sent to the server (and the server sends it to YubiCo through the API for verification). But YubiCo marks that sequence number as forever stale, preventing replay attacks.

And it's not like an attacker being able to specify their own challenge would give them some edge, assuming that the underlying crypto is sound.

So, why do we need all that extra complexity? It's just going to make it way harder for people to adopt and implement. Like... for SSH login, I think it's pretty much impossible to support U2F. And even for the people who DO implement it (Google, GitHub), the extra complexity (browser plug-in, etc.) mean that people aren't going to use it. If they can't use it EVERYWHERE they go (without a special browser), what's the point?

And it's amazing that Google and GitHub are finally waking up and figuring out that YubiKey rocks and they should support it....

But what was wrong with the old, simple YubiKey? I don't want to use Chrome... why can't I use any browser? What if I'm in some computer lab, stuck using an out-dated IE? That's exactly the situation where I NEED 2-factor, but it won't work.

Are these folks totally out to lunch, or am I missing something?

(This is not an attack on YubiCo... more questioning why Google and friends didn't wake up to the beautiful simplicity of the old YubiKeys years ago....)

First off: It's great to hear about your experience with YubiKey OTP, the simplicity you describe is really what first drew me to the YubiKey as well.

Now, there's nothing WRONG with YubiKey OTP, and U2F does not make it obsolete. It still has the benefits you've identified. Easier to integrate, simpler protocol, and so on. But U2F also has strong benefits, that only become possible by adding complexity.

First off, let's talk about challenge-response. For YubiKey OTP there isn't really a challenge, per se. There are counters which ensure the order of OTPs, and that prevent replayability, etc. But if you have a valid OTP, it's valid for anything. The OTP itself conveys no information about the intended use. Is it to grant access to my email? To my bank? Is it to authorize a payment? If an attacker is able to intercept the OTP before it reaches the intended destination (through means of phishing, for example), the attacker can use it for a different purpose. This threat is eliminated by challenge-response, since the response (which replaces the OTP) is only valid for a specific purpose, namely the one for which the challenge was generated.

Second, U2F is built on public key cryptography, meaning the authenticator (YubiKey) has a secret key, and the server has a public key. This means that the server doesn't have to store any secrets to validate a U2F authentication. In addition to this, each new credential in U2F uses a different key pair, which improves privacy for the user. This also means that you can use a single U2F device with many different services, without those services having to rely on a central validation service (like the YubiCloud for YubiKey OTP) as they can validate authentications for themselves.

Third, having specialized support in the browser means we can take advantage of browser state, preventing things like phishing and man-in-the-middle attacks.

So in summary, both are viable alternatives with their own pros and cons. Either is vastly better than not having 2-factor authentication, and we see a place for both protocols going forward.

Yeah, you're right about the fishing problem.

Even worse, if you use YubiKey everywhere (like every forum starts accepting it), some untrustworthy servers could "swallow" the OTP and never send it for verification (just tell you that your login succeeded) and then rush over to your bank and try logging in there. They'd have to do this before you ever used your OTP in a valid place again, but if you've already logged in to your email (or whatever else) for the day, they may actually have 24 hours or more to make use of the OTP.

Thus, you would still need to use separate passwords everywhere (because if they get a good password along with the OTP, you're in trouble), or separate YKs, which kinda moots the point of the YK convenience.

I'm currently only using OTPs with hosts that I trust (currently FastMail and my own servers). But that's mostly because no one else supports YK. On PayPal, I had to get a separate VIP YubiKey. For my bank, they sent me one of those credit card OTP generators with a little calculator screen and a battery inside, which is a pain (type in manually), but maybe that's more secure, because I think it's actually running a clock internally.


Am I right that there's no way to use the new FIDO U2F system with terminal-based SSH logins?

Sadly, if so few people adopted YK OTP, given how simple it was, I don't have a good feeling about FIDO U2F adoption. I mean, it's great news about Google.... maybe they'll send everyone a FIDO key for free or something!



FINALLY, here's an idea that I'll run by you for secure use of OTPs:

The YubiCo server knows your secret key, right? My understanding is that it's symmetric AES, and that the server verifies the OTP by encrypting the sequence number with its copy of the same key.

So, the YubiCo server could generate a verification string using the next sequence number and the shared AES key. This doesn't need to be as long as the OTP. It could even be a single letter of the alphabet. The YC server could send this back to the requesting server, which could display it through the client to the user.

At that point, you could press your YK button again and verify that what the server sent back matches what comes out of your YK. The YK could know that if it's pressed twice in 10 seconds, the second press should display the expected verification string that's coming back from the server (instead of the next OTP) and update the internal counter.

The server would mark BOTH counters as stale.

And this could be a "normal" phase of logging in with YK. Websites could show you a second form with a spot for the server's response and a field in focus ready for you to press your YK again and visually compare. And the YK wouldn't output the ENTER character for the second string, to give you time to study the form.

Of course, for hosts you trust, this could be optional (what comes back from the server could simply be ignored and not displayed).

And if a website that you DON'T TRUST shows you the wrong response coming back from the server (or doesn't show you one, or whatever), then you know to log into a trusted host with your YK immediately to push the sequence number forward.

This does complicate things a bit and put a slight burden on the user to visually verify that strings match, but it keeps everything simple an "it's still just a dumb USB keyboard" and would work for SSH logins and such. And visual verification could be as simple as checking that two letters match.

I know this will never be implemented (it would require a complete re-working of the whole YK OTP infrastructure, including issuing new YKs). But I think it's airtight.

You're mostly correct in how the OTP works. The YubiCloud does have the symmetric key used by the YubiKey to encrypt the counters, which it uses to DECRYPT the incoming OTP, resulting in the plain text, which is then verified (counters need to be correct, etc). However, this plain text contains two different counters, as well as a timer, and a random number. The counters are deterministic, but the server would need to know the exact time between the first OTP and the generation of the second one (down to an 1/8th of a second) to be able to predict this value. Worse yet, there is no way to predict the random number. Since changing any one of these values results in a completely different OTP, the server cannot predict any part of the next OTP.

As for using U2F for SSH, it's actually possible. You can use our pam-u2f module to achieve this (see: https://github.com/Yubico/pam-u2f/issues/12), but it involves jumping through several hoops.

Hmm, yeah, that live internal clock in the YK would break what I was suggesting terribly.

My understanding is that a YK has no battery and nothing is happening when it's not plugged into USB power, so that timer is transiently running only when it's powered. Thus, it's not some kind of "universal clock" that is synced with wall clock time in any way. Thus, the problem of unused OTP being useable forever until the verification server sees a newer OTP.

If only the verification server had a more reliable way of judging an OTP as being "too old," this problem would be solved with no back-and-forth.

I can't think of any way to do this without an internal battery to keep a clock going.

But I do love the fact that a YK essentially lasts forever (I guess until the internal flash RAM for the incrementing counter wears out? but I'm guessing there are hundreds of extra redundant flash slots in there, and it automatically moves on to the next slot when one starts to experience rewrite failures).

As usual, security systems always must negotiate trade offs.

And if YK OTPs were ever adopted everywhere (like, every service that used a password used them), I can see how it would become a total security nightmare as-is.

I currently maintain three passwords (one protecting money, one protecting mission-critical services, and another for services that don't matter). In a world of ubiquitous YK usage, I guess I'd have to maintain three YKs!


Anyway, I hope U2F takes off.... but I still wish there was a simpler, easier-to-implement system that was adopted instead. If the next generation YKs did what I suggested (2nd press spit out a short verify string that should match what comes back from the server), I think it would be a nice middle ground of very easy to implement yet also very secure.