Yubico Forum

Based on questions that have come up on this forum and via e-mail support, we've made a maintenance release to cover some issues:

Support for static OTPs
Although one could argue that static OTPs somewhat speaks against the whole concept of hardware tokens, there are quite a few situations where it makes sense. The primary use case is off-line and legacy systems where an authentication module integration cannot be done. It is important to know its weaknesses, but after all, a 32+ character password made up of gibberish is not that bad after all. The authentication server has not yet been updated to fully support this function as a static OTP will be treated as a replay. However, as the server will return REPLAYED_OTP rather than BAD_OTP, it can still be used as long as only BAD_OTP responses are considered to be invalid.

Random seeding of the timestamp
Instead of starting at zero and thereby having an unneccessary predictability, the 24-bit timestamp is now initiated with a random number at power up.

Counter wrapping
The session counter is now changed to automatically increment the usage counter if it wraps from 0xff -> 0x00. Previous versions increment the usage counter and clears the session counter if the timestamp wraps, whereas the session counter just wraps from 0xff -> 0x01.

We will release an updated version of the configuration tool to support static OTP configuration soon.

Effective today, anyone who have purchased an evaluation key and is interested in trying out these features can send me an e-mail with your address and we will send you a 1.3.0 Yubikey free of charge. We don't take back keys for re-programming and this offer is open to Jun 30, whereafter we plan to make this the default firmware version for all orders.

Ask for your key by sending an e-mail to jakob at yubico dot com. Don't forget the desired shipping address. We'll send with standard airmail.

All feedback is highly appreciated,

Jakob E
Hardware- and firmware guy @ Yubico

Hi,
one suggestion about the static OTP,
it will probally be 32 caracter of your 16 choice (b,c,d,...) 32 * 4 = 128 bits
would it be a option to put 32 caracter of ascii (7 bit) 32 * 7 = 224 bits

I anderstan thougt that it could not be verify in the yubico server.

Thanks, i will be a guinea pig

_________________
Patgadget
Montreal

About Counter wrapping: The sample server code indicates that bit 15 of the Session Counter was used to indicate that the OTP was invoked by CapsLock and I see that has since been removed -- changing the Session Counter from 15 to 16 bits. Does the current firmware kill the Yubikey once the Session counter sets bit 15 (as implied by Steve Gibson in the Security Now podcast) and the new firmware removes this "feature?"

When do you plan to have new configuration tools ready to support the static OTP?

Thanks,
Tom

Regarding the 15-bit usage counter and the upper trigger status bit, this has really become an issue beyond what I initially thought. We have not changed this function in the 1.3.0 firmware and I think we will keep it this way in order to maintain full compatibility with the keys that have been released and are in use.

Plans are being outlined for the next version of keys and OTP layouts and we will probably consider changing it then.

The rationale behind claiming 15 bits is sufficient is simple (or at least "was").

- 2^15 = 32768
- Asuming the key is used to generate an average of 10 OTPs per day, 365 days a year.
- That is just 3650 OTPs per year and it will then be enough for 9 years constant usage before the counter wraps

But...

- The counter is incremented at first usage after power up only
- After power-up, only the session counter is incremented
- If the session counter wraps 0xff -> 0x00, the usage counter increments

So...

- The 15-bit counter does not increment for each OTP, in practical settings much less often
- In real-world even after 10 years of constant heavy usage, the counter should not wrap
- If the device is used that heavily, it will most likely be mechanically worn-out anyway

This is a summary of the thinking and I really want to emphasize that this is NOT a part of a Machavellian inkjet-printer-and-cartridge-vendor kind of rip-off plot to build in a business-driven auto-suicidal mechanism into the device. I think it is a fair limit, but given a blank sheet of paper today, we probably wouldn't have stuffed the bits so hard. Again - the OTP layout will be extended in the future and this limit will then disappear - be sure...

Please let me know of your thoughts

Regards,

Jakob E
Hardware- and firmware guy @ Yubico

The plan is to ship the beta keys with the OTP flag set. Anyone interested in checking out the new random seeding can be used to reprogram it.

Anyone who prefer to have it cleared, i.e. to check the random timestamp seed, please let me know.

The interest so far has really exceeded my wildest expectations

Regards,

Jakob E
Hardware- and firmware guy @ Yubico

Sorry for the delay, we've really been absorbed by all ordinary shipments. The first batch was sent today.

It is sent by snail-mail and expect a week or so to the US.

Thanks for your patience,

JakobE
Hardware- and firmware guy @ Yubico

Even better than just sending only one key, with static OTP set, was the sending of 2 keys, one with Static OTP set, and one with static OTP cleared.

I received my keys a few days ago. No issues so far. The only thing you have to remember when using your static OTP key, for sites that use legacy password system, is that the site must have NO LIMITS on the length of password, and the site must NOT require digits and/or symbols and/or mixed case, to be able to use this token. (Like what are the chances that someone is going to bruteforce a 44 character base 16 password, in their lifetime, at the rate of 1 billion passwords a second.). Of course, if the system requires digits and/or symbols and/or mixed case, then enter those requirements, prior to appending the static OTP. (you can always enter that same sequence at login time, prior to pressing the OTP button.)

Because there is a CR appended by default, you must put your OTP into a notepad instance, or some other place where the CR will not disrupt entry, then copy/paste the static OTP where it is required. (That is new password, confirm new password.)