Yubico Forum

...visit our web-store at store.yubico.com
It is currently Tue Jan 30, 2018 5:08 pm

All times are UTC + 1 hour




Post new topic Reply to topic  [ 26 posts ]  Go to page 1, 2, 3  Next
Author Message
PostPosted: Tue Apr 28, 2009 2:14 am 
Offline

Joined: Tue Apr 28, 2009 2:10 am
Posts: 2
Any chance that alternative layouts will be supported in a near-future firmware release? Some of our users use the Dvorak keyboard layout and are forced to switch back and forth between Qwerty and Dvorak to utilize their Yubikey's....far from an ideal user experience.


Top
 Profile  
Reply with quote  

Share On:

Share on Facebook FacebookShare on Twitter TwitterShare on Tumblr TumblrShare on Google+ Google+

PostPosted: Mon May 04, 2009 12:15 am 
Offline
Site Admin
Site Admin

Joined: Wed May 28, 2008 7:04 pm
Posts: 263
Location: Yubico base camp in Sweden - Now in Palo Alto
We've got the "Dvorak question" quite a few times over the last year and it seems like we have to do anything about it.

One approach is to add a backend solution to it, where the backend makes some kind of guesswork if the OTP does not look like expected or if the authentication fails.

Another one is of course to add a configurable option to change the key to a Dvorak layout. However - how would we protect this setting from being changed by a potential saboteur ? Assume organization X issuing a set of Yubikeys to a large number of users where some have Dvorak keyboards. If we would make a "Dvorak flag" being pubilic - what if a saboteur would flip this flag ? As the issuer can't protect it, what would be the way to go ?

A third option is of course to make a special "Dvorak version" available. I'm perfectly fine with that, but from a logistical perspective it seems less favorable.

Please let me know your thoughts here. We're somewhat open to all three options.

Regards,

JakobE
Hardware- and firmware guy @ Yubico


Top
 Profile  
Reply with quote  
PostPosted: Mon May 04, 2009 2:43 am 
Offline

Joined: Tue Apr 28, 2009 2:10 am
Posts: 2
Given the multitude of keyboard layouts in use worldwide, I think that the only realistic option is to handle it serverside. As you discussed, any client-side hints open up new vulnerabilities, and special firmware sounds like an administrative nightmare. It seems like letting the SSO admin specify the accepted fall-through types for the sieve would likely alleviate any hassles.


Top
 Profile  
Reply with quote  
PostPosted: Wed Jun 24, 2009 6:04 am 
Offline

Joined: Thu May 21, 2009 1:44 pm
Posts: 2
I agree with heisenberg. To be honest i didn't knew anything about the Dvorak keyboard layout :shock:
So I checked out wikipedia. I'd like to build-in this feature into my OTP validation server.
Did someone already defined the needed "modhex"-similar mapping table?


Top
 Profile  
Reply with quote  
PostPosted: Wed Jun 24, 2009 7:57 am 
Offline

Joined: Fri Jun 19, 2009 6:06 pm
Posts: 31
JakobE wrote:
Another one is of course to add a configurable option to change the key to a Dvorak layout.
[...] what if a saboteur would flip this flag ?


My vote goes to the serverside. IMO the firmware already has too many features as it is.

While at it: may I suggest we have the option to install hardened firmware - that is: firmware that does not have all the options like capslock double-clicking, surfing to an URL etc.?

The bytes freed might be used to store a new function; one to offer better protection against malicious re-programming of the key. I suggest having the key send a string of random bytes if it receives a 'programming request'. These bytes need to be encrypted by the programming process using the key's current AES secret. The programming proces subsequently sents the encrypted string back to the key. Only if the key can decrypt the message, programming is allowed (including updating of the AES string etc.). Also, the key should cease to function for a minute if an unsuccesfull attempt was made to program it while blinking the ring in a fast pace. On the second try, the key should double the time it ceases functioning etc. [not sure if unplugging would have to stop the cycle or restart it; from a security perspective I'd say 'restart it'].

Will put this idea on the ideas page later, if someone wants to discuss it, we may need to start a new thread.


Top
 Profile  
Reply with quote  
PostPosted: Tue Aug 11, 2009 6:30 pm 
Offline

Joined: Tue Aug 11, 2009 6:03 pm
Posts: 7
The cool way to support alternate keyboard layouts would be to parse the os's keyboard mappings database, look up the yubikey's keycodes for each one, and then you'd have a comprehensive decoder ring. I did that.

People who use dvorak are already used to changing their keymap before they enter their password (e.g. for the YK2 long password mode). But if an attacker changed a future YK's keymap it would simply be wrong all the time, the user would probably be confused.


Last edited by dholth on Thu Aug 13, 2009 5:56 am, edited 1 time in total.

Top
 Profile  
Reply with quote  
PostPosted: Tue Aug 11, 2009 9:07 pm 
Offline

Joined: Tue Aug 11, 2009 6:03 pm
Posts: 7
I wrote a little program that changes the keyboard layout and asks X11 for the keycode -> character mapping. Here are the results for a few layouts. The code is a Python dictionary of {[unicode characters,] : [layouts,]} that would be easy to incorporate into a more sophisticated modhex decoder.

ؤﻻيثبلاهتنمىقفعر ['ar']
cbdefghıjklnrtuv ['tr']
ъфаеожгстнвхишкэ ['bg']
jxe.uidchtnbpygk ['dvorak']
сивуапршолдткегм ['ru', 'uz']
cbdefghijklnrtuv ['be', 'fr', 'dk', 'hr', 'jp', 'de', 'sk', 'it', 'cz', 'en_US', 'br', 'us_intl', 'es', 'cz_qwerty', 'pt', 'no', 'lt', 'us', 'lv', 'mt', 'fr-latin9', 'ro', 'pl', 'gb']
цбдефгхијклнртув ['mk']
ܤܧܝܖܒܠܐܗܬܢܡ܀ܩܦܥܪ ['syr']
แกำดเราสพะอ ['th']


Last edited by dholth on Thu Aug 13, 2009 5:56 am, edited 1 time in total.

Top
 Profile  
Reply with quote  
PostPosted: Wed Aug 12, 2009 7:05 am 
Offline

Joined: Tue Aug 11, 2009 6:03 pm
Posts: 7
More layouts! I went ahead and wrote some JavaScript to translate the input from 400+ keyboard layouts to modhex. This ought to go into the server. The server should check more than one modhex interpretation of the otp in the rare case that's necessary.

Try it at http://dingoskidneys.com/~dholth/yubikey/


Top
 Profile  
Reply with quote  
PostPosted: Thu Aug 27, 2009 7:10 pm 
Offline
Site Admin
Site Admin

Joined: Tue May 06, 2008 7:22 pm
Posts: 151
dholth, thanks for your work here. I agree that the best is to integrate support for this in the validation server. Before I spend too much time on this, maybe I can learn from what you have done. For example, is it possible to write a function that takes a string and returns a "guessed" correct string by doing only string operations? That would be the easiest to implement in the validation server.

Alas, I suspect the function needs to use the database as an "oracle" into whether a particular guessed OTP is OK or not, and then iterate through all the guesses it have, before deciding which is the best guess. This is also possible to implement, but more work.

Anyway, I'd like to invite you to look at the validation server code, to see if you can find a place to add this code conversion. Check out the project and source code at:

http://code.google.com/p/yubikey-val-server-php/

In particular:
http://code.google.com/p/yubikey-val-se ... verify.php
http://code.google.com/p/yubikey-val-se ... common.php

After testing, this is something we definitely would consider deploying on our main servers. It looks feasible to me.

/Simon


Top
 Profile  
Reply with quote  
PostPosted: Fri Aug 28, 2009 2:57 pm 
Offline

Joined: Tue Aug 11, 2009 6:03 pm
Posts: 7
I had sincerely hoped to avoid doing any Unicode coding in PHP, but porting the JavaScript OTP decoder (see demo web page) to PHP (and Java, and Python, ...) should be straightforward.

http://dingoskidneys.com/cgi-bin/hgwebdir.cgi/yubikey/ is the source code. You can install Mercurial and do an "hg clone" on this url to get a local copy with full history.

If you play with the demo page at http://dingoskidneys.com/~dholth/yubikey/ you will see that in almost every case there will be only one possible interpretation of an OTP. As long as all 16 characters appear in an OTP (for the supported layouts), there will always be only one way to interpret it except in certain Armenian layouts where there will always be 2 ways to interpret the OTP. That gets you pretty far without having to check 2 OTPs in one request.


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 26 posts ]  Go to page 1, 2, 3  Next

All times are UTC + 1 hour


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group