Yubico Forum

WHY does that feature only work in windows?

What is the ykFLAG_SEND_REF for any configuration flag? What does it do?

What do you mean with "first part" and "second part" regarding the ykFLAG_APPEND settings?

_________________
The YubiKey Server Guy

Auto navigation works by the means of sending Win-R <url> <enter> as a series of keystrokes. Given that the key is programmed with an URL in the form of http://xxx, Windows will launch the current registered browser (which does not need to be IE) and navigate to that URL. Optionally, an OTP can be automatically appended to the URL, allowing direct authentication, i.e. http://www.mysite.com/login?otp=clefcei ... bjeevvkdtg<enter>

Making it this way makes it a Windows specific feature. Maybe there is a Mac shortcut for doing the same, but then it would be a Mac specific feature.

Furthermore, this feature also requires configuration of the keyboard layout into the Yubikey. This means that if a key that is configured to work on a US keyboard is brought to France, it won't work.

It is a pretty cool function, but to me these issues are somewhat a turn-off...

The configuration flag ykFLAG_SEND_REF is used to prefix the OTP with the reference modhex string cbdefghijklnrtuv. This feature was added if there would be any problems with any keyboard layout that did not fit well with the modhex scheme. The server would then simply use the reference prefix string to make proper substitution of the characters in the OTP string. AFAIK, it seems like this feature is not needed.

Regards,

JakobE
Hardware- and firmware guy @ Yubico

How do you prevent someone from programming the equivalence of "rm -rf /"?

Having a token in effect execute arbitrary commands upon insertion is scary, since there is no reasonable way to detect and prevent it... or is there?

The intention is that only the yubikey owner can do this programming, and he can type 'rm -rf /' on the machines he access anyway.

Or more detailed, only the person that knows the programming password can do this programming. We are changing our process so that all yubikeys that we ship have a programming password set from factory. Right now, all keys are open to re-programming without a password.

/Simon

So: in reality, a Yubikey is a executable program. The user has *no way* of knowing whether
a script executes when you first insert the key.

With a CD or DVD, the user can reasonably expect autorun. With an authentication device, no.

This is a tremendous obstacle to overcome for corporate deployment.

I don't agree that is true. The yubikey doesn't contain any programs. Corporates can and sometimes already do have software that prevents employees from inserting USB memory sticks that can spread trojans or similar.

Restricting USB access to USB keyboards seems less useful, the employee will not be able to connect any normal keyboard to her laptop when she's travelling and so on.

So it is possible to exclude USB memory sticks but enable the yubikey to work.

I do agree it needs to be discussed with each customer. If they have a policy of physically destroying all USB outlets on machines, they will need to change their policies in order to use the yubikey.

/Simon

I beleive it needs to be sorted out very explicitly in order to avoid any misconceptions. Please find some "axioms" listed below:

a) The Yubikey identifies itself as a HID device (HID = Human Interface Device, i.e. Mouse, Keyboard, Joystick etc) only.

b) Although the form factor reminds of an USB memory stick, there are no possibilities whatsoever for it to work as a mass-storage device, even less for it to expose a file system. There are no secret tweaks or smart hacks that could change this. Nothing, nada, nil - period.

c) The autorun feature offered for mass-storage devices, such as a CD requires the USB mass-storage class and a file system. There is nothing like that in the Yubikey.

d) As there is no file system, the device CANNOT spread viruses or trojans

e) The auto navigation function is just an automated keyboard input, just like if someone would add a second keyboard and type in the same information.

f) There are organizations that blocks the usage of USB memory sticks. That typically involves a short-circuit of the USB mass-storage driver and that does not affect the Yubikey - it will still work even if the mass-storage driver is gone.

g) Killing the HID driver would also kill the ability to attach a mouse or an external keyboard. I cannot see anyone wanting to do this.


Regards,

JakobE
Hardware- and firmware guy @ Yubico

Is there a way to turn off the auto navigation without losing the OTP capabilities of the Yubikey? I assume that I could do it by reprogramming to a static PW, but can I do it without doing that?

Dick

ATTN: always
If your working in the corporate or scholastic field then you should know how to kill the U3.

Go here to uninstall the autorun U3 Launchpad.
http://u3.com/uninstall/


Now here's a heads up for all, the next U3 headache is called StartKey (formerly: KeyChain)...
http://www.u3-info.com/sandisk/microsof ... eplacement
http://www.everythingusb.com/microsoft- ... 14376.html


Reference
http://en.wikipedia.org/wiki/U3

Edit: PS. Remove U3 at own headaches/problems, but I'd just use SandBoxie.

Unless I'm missing something, the auto-navigation isn't dependent on the autorun function nor USB device characteristics, but rather on the fact that a Yubikey set up for auto-navigation sends a Win+R and then keystrokes for a URL which results in opening the designated browser and navigating to the URL. At least that's the way that it's done on the MashedLife Yubikey which, when you plug it in, takes you to that website and enters your Yubikey generated OTP.

I know that I can do some key redirection to kill the Win+R function, but was wondering if I could reprogram the Yubikey to remove the auto-navigation without completely wiping its OTP capability.

Dick