Yubico Forum

We've got quite a few questions regarding the dual configuration feature introduced with Yubikey 2. Apparently, the quick introduction was not that self-explanatory

The background is the large number of users who want to use their Yubikey for multiple purposes, primarily an OTP based service and also for legacy login (long static password).

We therefore created the dual configuration feature, where each Yubikey 2 effectively acts as two Yubikey 1s. The two independent and identical configurations can be managed by two different “owners”, each configuration having its own configuration protection password.

There have been lengthy discussions how to best select which configuration that is to be used when the button is pressed. Everything (?) seems to have been up - multiple buttons, optional client software, double-tapping, Morse-like tapping…

We finally decided to go for the short and the long button press. This had the implication that we need to change the current behavior slightly. With the Yubikey 1 where only one configuration is available, holding the key for more than 0.5 seconds triggers the OTP release. In the case of a multi-use, the distinction between a short and a long press has to be done when the key is released. This means: hold – wait – release and the OTP is emitted. A short press is set to be 0.3 to 1.5 seconds. A long press is set to be 2.5 to 5 seconds. This means that holding and releasing after 2 seconds won’t trigger anything. We believed it was a good idea to have a “window” between the short and long time to foster the correct behavior.

We’ve got a few comments and it seems like our users likes it. We’re of course keen to get more feedback. If there is anything that should be changed, be made configurable or be made in an entirely different way, we’ll consider it.

For the people who are not interested in the dual usage, we decided to make the default behavior where only one configuration exists to be exactly like with Yubikey 1. Just hold and wait until the OTP appears. (A short press-wait-release will work as well). This means that no information is needed for users who are used to the Yubikey 1 and get a Yubikey 2 as a replacement.

The Press-wait-hold behavior is enabled when the second configuration is set. If only the second configuration is set, it will be triggered by a press-wait_long-release action.

Finally, we anticipated that some people who don’t care about a second configuration might be upset that there is suddenly a possibility open to change the behavior of the Yubikey by writing to the second configuration. If this is a concern, a new flag has been introduced that allows the “owner” of configuration #1 to prevent configuration #2 from being set or changed. Conversely, we’ve added a possibility for the “owner” of configuration #2 to prevent the “owner” of configuration #1 from blocking/locking its configuration by setting this bit. We believe this should make everyone happy.

In summary, we believe we’ve got a good functional enhancement without sacrificing usability or increasing production cost. There is however “hundred ways to skin a cat” and there may be things that we should improve or change as time goes by.

All feedback is highly appreciated.


The complete Yubikey 2 documentation is available at http://www.yubico.com/files/YubiKey_manual-2.0.pdf


With the best regards,
JakobE
Hardware- and firmware guy @ Yubico

I tried the Yubikey Personalization Tool 0.0.1d for Mac. It's probably not as good as the Windows version though (haven't tried that out)
After some experimenting, I guess I want to use config #2 for yubico auth server for now.
I also tried unsetting config #2 but had the protection bit enabled so I had to clear out #1 first. I'm not sure what the idea of having a protection on it has.
After switching the exact OTP config from #1 to #2, I found out that yubico auth server only returned REPLAYED_OTP.
I tried using the Yubico AES Key Upload page but that returned "Sorry, that yubikey prefix is already in use". Instead of generating a new prefix, I decided to increase the session count of the yubikey which fixed authentication again.
It would be nice if the AES upload page has a mode to reset the counters for the given yubikey. It has everything to verify that, right?
And what's the serial number used for anyway?

We don't permit this for security reasons -- it would be too simple for someone other than you to reset your counters. At least I don't see any way to make it secure against that kind of attack.



It is not used for anything. Perhaps we should remove it to reduce confusion.

/Simon

I'm going to try and be as diplomatic as I can with this. I've spent the last several hours reading and re-reading just about every piece of documentation you offer on your website, reading through over 100 topics in these forums, watching your various YouTube videos. And at this point I still have no clue what I am supposed to do in order to get the most out of your product. I have it seemingly working as intended with LastPass and that's about it. To be perfectly blunt, your documentation is horrendous. Particularly when I am sitting here and of the mindset that one wrong move on my part and I will have made myself a very expensive shim to even out one of the legs on my kitchen table. Now to give you some reference regarding my technical expertise, I'm not a CCIE or anything, but I do have roughly 25 years experience in professional IT work with the appropriate alphabet soup on my business cards.

The primary reason I ordered one of your devices is that I'm trying to determine if I should order 200 of them for my agency. I am impressed with the capabilities, but as of now I am far from sold on the implementation aspects and any ongoing maintenance for a roster of 200 users.

So do I need to upload AES keys? If so why? What are all of the fields I need to fill in? Like I said I've read and re-read yet these questions are still unanswered for me. Proper documentation and some step-by-step instructions would have prevented this. Configuring a Cisco ASA is more straight forward than this.

Sorry to hear that you're not happy with what we provide in terms of documentation. It would of course be very much appreciated if you could be a bit more specific what we could improve.

The Yubikeys we sell one-by-one over the web are pre-configured to allow authentication with our on-line authentication server. We leave the Yubikeys unprotected so anyone who would like to re-configure them for their own application are allowed to do so. If a configuration is unintentionally blasted, a new configuration can be generated and then be uploaded on a one-by-one basis using our simple web interface.

Maybe the question is more generic - what can I do with an authentication token, like the Yubikey? The generic topic is a bit too broad to answer, so please be a bit more specific what you want to do, and we'll do the best we can to answer. If you prefer to take the discussion off-line, please send me an e-mail at jakob at yubico dot com

With the best regards,
JakobE
Hardware- and firmware guy @ Yubico

Well I finally just took a chance and went through what I thought would be the proper steps in order to make a second configuration with a static password. See if you're going to have warnings about permanently destroying or altering something, that means you need to have explicit and clear documentation.

The existing documentation is probably great for the cryptographer. There is no lack of specification and detail as to how the device works on a technical level. For somebody like me, I need some demonstrative examples of how this is going to fit into my enterprise network. For instance, I did see some information, including a video, on integrating Yubikey with Google Apps. That's fantastic for as we're currently migrating to Google Apps. It isn't so clear how I can integrate Yubikey into the various machine login mechanisms that we utilize - Microsoft Active Directory, Microsoft non-domain member workstation, and Linux workstation (I assume using PAM). Surprisingly it would appear as though the Linux integration will be the easiest of them all. Perhaps I am asking too much of the Yubikey, but what I am hoping for is making it a requirement for logging in to operating systems, Google Apps, LastPass Enterprise, and as a strong static TrueCrypt password.

Like I said in my first post, I'm impressed with your product so far as it's capabilities and particularly the price. But I think that the documentation could use some expanding and clarification. There is a tremendous amount of vernacular that the unititiated needs to wade through, and it can be quite distracting when trying to figure out how this whole system is supposed to work. I get the feeling that if someone sat down with me and explained it all while answering some specific questions I had, at some point I would have the light bulb go off above my head and instantly understand it all.