Yubico Forum

Hey guys, I love the idea of the Yubikey, I'm looking for ways to implement it, and I must say that Steve Gibson is doing a good job at getting me to think about potential issues with the architecture.

It occurs to me that the Yubikey does not provide authentication. All it does is prove that a particular hardware token was used at a particular login process. Ok, I know this sounds confusing, let me try to elaborate.

When I look at my key, it has a static ID, that first 12 characters that identifies the TOKEN. There's nothing that identifies ME. My problem is, what happens if I loose my token? If it was openid, I simply get a new token, link my openid server to the new token URL, and we're good to go, but what about applications like this phpBB for example... it knows me by my token. If my token is lost, stolen, broken, then I (me) will never be able to log onto this site ever again. I will have to get a new token, register a new account, etc.etc.etc.

There is a layer missing. The layer that identifies which token (or yubikey) is linked to which account. So that when I do log in my email address (for example) as login ID, yubico can then use that to see if it's linked to the right yubikey. Should I loose my yubikey, I can go through some process to validate my real identity to have a new token linked to my account.

Basically, I don't like the idea that the keys are "stand alone" devices.. There needs to be a way to manage your authentication and your tokens. When you run your own server, you could build that in, fair enough, but I don't want that.. I want to use the Yubico server.

What are your thoughts?

Cheers
Phil Massyn

The way I see it, what comes out of a Yubikey is a combination of a (random) username and a password. In that regard, one could say that it works just as any other username+password mechanism for authentication, the only difference being that the password changes from one use to another and contains encrypted data.

This forum could actually use the Yubikey prefix (that static ID you refer to) as username, it's just not very friendly for human eyes and recognition, so the account name that you see here (levitte for me, Massyn for you) can be seen as a user-friendly alias.

What you say is lacking is really in place, it would be impossible for this forum to know that it should identify me as "levitte" when I log in if there wasn't a link between my Yubikey's prefix and my account name here.

What's lacking is a clear mechanism to revoke and renew Yubikeys connected to an account. That's unfortunately as painful as the loss of a PGP key, a X.509 certificate+private key or a password. All these authentication methods require some external renewal mechanism (you've probably seen as many solutions to recover lost web site passwords as I have, for example).
The OpenID example that you mention does require some kind of out-of-band handling, right? You have to fiddle with the web page that you use for authentication, and that in itself requires another authentication.

Cheers,
Richard ( I don't know yet how this would be handled in practice, maybe I'll get to do some coding )

I see it this way: the Yubikey is labeled as "This is the key" - and this does not only work out for its key-like shape. For me, it's just like the key to a door, to a car, a lock, a whatever. If you lose one of those keys, it's painful as well - and it has to be, even for the Yubikey! Because otherwise every attacker could just pretend to be you and say "Oh, I've lost my key, can you let me in without it? Just this time? Please?"
So let's think this through - if you lose a Yubikey that was linked to your OpenID provider, you surely want to revoke it to prevent any abuse. Ok, now you have to authenticate with something else - because that "something you have" has gone missing. How do you do that? Security question? Biometrics? Faxing your ID card?

Under the line: better not lose your Yubikey!

_________________
"Grant me the strength to accept the things that I cannot change,
the courage to change the things I can
and the wisdom to know the difference."

Phil,

As I understand your point, you're not faulting the YK, but rather the implementation for this forum. You assume that if you were to lose the YK, that you'd have to start from scratch with a new account because you'd have a new YK. I agree that that would be undesirable, but don't think that's necessarily the case.

I checked the registration process and entry of an email address is a part of that process. Entry of a PIN is optional. If you were to lose your YK, the email address (and PIN, if entered) could be used to connect you and the new YK to your existing account. I realize that merely using the email address isn't as secure as various other means, but we're only talking about access to a forum so it's probably adequate for that purpose. If the stakes were higher, more information could be collected at the time of registration to be used to verify your identity before allowing you to use a new YK.

The fact that you don't have to enter your email address AND use the YK each time you login doesn't negate the fact that the email address is already associated with the YK and your account.

That said, I don't know what the actual procedure would be if you were to lose your YK. My point is that a means exists to connect your identity to a new YK if necessary.

Dick

Maybe using the forum is a bad example, but it does pose a few interesting arguments.

1) The Yubikey indicates that someone has the "something you have". It does not guarentee that you are the person that has the "something", so if your key gets lost or stolen, someone else could impersonate you. This also poses the question - how do you revoke a Yubikey?

2) This does pose an interesting problem for non-Yubikey authentication... Do I ask your secret question, which can easilly be spoofed, or do I fax my passport to some odd number in Sweden... This adds to inconvenience, and becomes impractical.

3) Using an openID service like clavid has it's own set of issues. You can overwrite it with a password, which defies the need for a Yubikey. Next up, the weakest point of failure would be your web server where you host your "openid redirector". If that's just a dodgy FTP account with a static password, you're again vulnerable.

Cheers

Phil

If you set a PIN when you set up your forum account, you then have something you have and something you know as requirements to log in. If it was something more than access to the forum, I'd probably do that. Given that it's just forum access and that the YK that accesses it doesn't leave home at this point, I don't feel the need to do so. I may change that if I start carrying the YK around more.

Seems to me that the way that different entities implement their use of the YK depends on their specific needs. It can be the only aspect of authentication or it can be one of many. That's up to the entity. The YK is just a tool that they can use to do that. In other words, a particular system could require a password, the YK, a fingerprint, and an iris scan if they felt justified by what was being protected. If all they decide that they need is one such method, that's not a weakness in that method, but rather in how they've implemented it.

Dick

Hello Massyn, I'm a little late to this discussion but I see you've hit the same barrier I did.
First off let me clearly state: "I see Yubikey as a viable and economic maximum-compatibility security device."

The Yubico's OTP is very nice but when you loose the Yubikey. Or the washing machine/dryer/ore-crusher/swarm of locust eats it, or whatever, then you're locked out of your password-vaults, email program, blog site, OpenID, etc...
No-one I've discussed the Yubikey with locally, would use the Yubico OTP because they've all come to the same realization, and often within ~12 minutes.
Basically, if you damage it, loose it, or misplace it for 6 years (long story), then your up a creek and, er, with no way back...


I'd suggested the "Backup Yubikeys" concept for basically the same reasons as you have stated.
The Discussion pages are where Kamikaze28 points out a serious problem, but there is a simple old-school hardware solution to this.
http://wiki.yubico.com/wiki/index.php/A ... up_Yubikey

Quote:

For me, it's just like the key to a door, to a car, a lock, a whatever.

All those types of keys have at least 1 duplicate key and most people give a copy to at least one person they trust.
Any reader not familiar with "Keyed alike Yubikeys" concept, please read the Discussion pages where Kamikaze28's keen insight gives me plenty to think about.
http://wiki.yubico.com/wiki/index.php/A ... e_Yubikeys



Perhaps the question should be: "How could you revoke a Yubikey or assign a new Yubikey OTP over the old/compromised/lost Yubikey OTP?"
1. Design application software that allows 2 or 3 Yubikey OTPs, for dealing with the damaged/lost/compromised OTPs that will arise.
2. Yubico offer a Personal Yubikey management with options like: Lost, Sold/GivenAway, Reassignment, and multiple Yubikey usage as 1 ID.
3. Yubico offer the (slightly lower security) backup Yubikeys, or a keyed-alike Yubikeys.
4. Design software that can lift Yubikey OTP and image it for use as a Virtual Device.
5. Don't do a thing and call the wah-mbulance when lost/damage/stolen.

Until there's a solution, how can a person avoid the Yubikey OTP-Loss Crisis?
a. Whenever possible, don't use the Yubikey OTP.
b. Use the Yubikey only where you control/assign your own OTPs. (Using your own servers.)
c. Locusts eating the Yubikey, ah, you have bigger worries, just throw your Yubikeys down and run for colder climates!!!
d. Keep a master list of UserIDs and Passwords as the Contingency Plan, which sorta defeats the worry-free Yubikey management system...

I see this issue as a substantial hurdle to overcome, and hopefully we can find more solutions.

You could use the same setup as they use at lastpass

I wiped my Yubikey by mistake and i was using it as a 2nd factor of authentication at LastPass.com

When I wiped it I no longer could use it to access lastpass. When i want to lastpass and entered my username and password it then asked me to insert my Yubikey. But there is also a link that says if you've lost your Yubikey to click here. This sends an e-mail to me which i can then click on to disable the need to use my Yubikey to log into lastpass.

When i got my new Yubikey I then re-enabled the Yubikey access requirement and i then had my 2nd factor of authentication.

Hope this helps

Did you see that every authentication mechanism can be enabled/disabled in the clavid portal -> Account Settings -> Login Settings. That allows to fully disable password login as well as enforce YubiKey 2-factor login if a user wishes to do so.

_________________
YubiKey & OpenID/SAML => web security without compromising usability!

A suggestion: why not make it mandatory for well-behaved applications to recognize a session counter value of '0' as an indication that the current key is a replacement key?

So, if an application detects that the session counter value is '0' , the application will enter the 'replacement key' logic. That logic could be as simple as to reset the application's internal counters to allow you to use the new key - or may involve more complex re-authentication logic to suit your security needs.

Remember: as long as you don't unplug your key, the session counter will remain '0' which gives you plenty of time to visit all sites on which you use your key. Also remember that the only way for an application to detect a zero counter is if all other credentials match (e.g. AES key, public id and secret id).

That way, if you lost your key, you would simply reprogram a new one with the backup of your AES string, public id and secret ID (either the one you rolled yourself, or have obtained from Yubicom using the infamous 'sent me 2 keystrings and the paypal stuff" authentication method).

The reprogramming restores the session counter to '0' (which is already the case if you reprogram your key!). Next, you would plug in your new key and visit each and every site that requires your YK and log in with the new key. The site will detect the '0' session counter and enter the (re)authentication logic.

After you're done on all sites, simply unplug your key. The next time you will use it the program counter is automatically incremented and so the 'reset' key automagically becomes a 'regular' key.



I somewhat solved that problem in one of my webapplications by requiring the user to authenticate with a client side certificate first. Also, the secret ID of the corresponding key he/she has to present should match a hash of the distinguished names of the client side certificate. A passphrase completes the 3 factors: the identity is established by the CA ("what you are") and confimed with the matching YK ("what you have") and the passphrase ("what you know").
Good enough for me