Yubico Forum

Hi guys,

The static password mode is I think a good idea, and will allow much wider adoption of the YK. The issue I have is with the password it generates. Now my YK's firmware is too old to allow me to play with this, but I've been reading through the forums, and listening to Steve Gibson and made some "assumptions" that I'd like to share with everyone...

1) The SP (static password) is long, as it should be, but not many websites / programs will allow the use of such a long password. If you live in an AIX world, 8 characters is the maximum length.. Anything longer gets ignored.

2) The character set is limited. Many sites / programs require the use of "strong" passwords. We all know the YK is very strong, but if a little script on a server somewhere is looking for the number of numbers and upper case characters you have in your password, the our YK SP will fail.

3) You can not set your own password. You enter a hexadecimal key into the personalization tool, and it works out the password for you, so you end up with something you don't really know what it is.

=======================================
Here is my proposal :-

1) Develop a "separate" personalization tool just for the Static Password configuration. This tool should allow criteria to be selected as to what makes up a strong password, based on strong password parameters that you can define that's available in AIX, Active Directory, NDS, VMS, Linux, etc.

2) Allow the personalization tool to generate a new password for you based on your parameters. You don't ever have to see it, but you'll know it will x characters long, will have y uppercase characters, and z number of numbers, etc.

3) You have memory in the device (ie the Auto Navigation mode, etc). Use that instead to store the static password. That way what ever the user wants his password to be will be the password, not the AES memory that has to be decoded to some arbitrary long code that you can't use anywhere except your Truecrypt volume

4) Allow the user to select the keyboard layout / scan code types. I know you have the issue with different keyboards and scan codes, but I think it should be up to the user to decide through the personalization tool. If we've opted for our own strong password, I don't believe it should be difficult to use our common character set to build that strong password, maybe you could add a few more characters that are common, or, should the user choose, don't use the common character set, and hope that he doesn't travel to another country with a different keyboard.

5) What are the chances you'll take your YK to another scancode keyboard? That is very slim, and although you're focusing in making the YK generic all over, this one "feature" may potentially cripple the potential growth of the product. I'd love to hear from others that traveled overseas with their YK to work on another computer/keyboard scan code and use the YK. I know when I travel, I take my laptop with me anyway...

=================
Cheers

Phil

Responding to your assumptions by reference to your numbers based on my experimenting with one of my YKs in static mode:

1) I've not had any problem with the long static passwords, but admittedly I don't live in an AIX world. You can program the YK to use less than the full 64 possible characters for the static password. While I'm sure there would be problems on some sites or with some programs, I haven't generally found that the number of characters was excessive for the sites or programs that I've tried.

2. Mostly I've gotten advice that my static password is weak because it didn't contain "strong" characters, but not refusals to accept it. If you need some "strong" characters, you need only create a password by typing a few such characters and then triggering the static password from the YK. For example, &(@$?cbdefghijklnrtuvcbdefghijklnrtuv.

3. While you can't entirely control the static password that you will end up with, there's no problem knowing what your password is. You merely open a text editor and trigger the YK. It will display the password so that you can, if you wish, store it safely. That way if you were to lose your YK, you'd still be able to log on by typing the password manually. A bit tedious, but doable.

Frankly, while I like the ability to use the static password mode, it seems ultimately limited by the fact that I don't want to use the same password, regardless of how long and/or strong, on multiple sites and don't want to end up carrying a keychain full of YKs. I feel that the primary YK attraction is still the OTP authentication and that we shouldn't elevate the static password generation to more than a useful side benefit of the basic OTP concept. If I were focusing on a solely static password storage device, I'd want it to be able to store numerous passwords and to choose between them as needed. This seems beyond a reasonable expectation for the YK in the foreseeable future.

Regards,

Dick

A possible idea perhaps is a Yubikey Lite which stores a user definable string which is emitted when the button is pressed. This could be a URL, password, whatever. The firmware would (I suppose) be minimal and we would have 2 Yubikey variants, lite for static applications and regular for OTP.

For truly uninspired users, the static programming tool could have an option to generate a password satisfying criteria such as mix of character types, length etc.

We have a problem in environments which require you to change your password periodically but this problem exists for current static Yubikeys. I guess it means that static Yubikeys are not particularly suitable for these environments without e.g. some means of periodically issuing replacement Yubikeys ahead of the system forcing a password change.

Ed

There is an easy solution for the system requiring periodic password changes. two yubikeys. One contains your current password, and the other gets personalized with a new aes key (and/or static ID and/or secret ID), resulting in a new password. When the forced change comes up, if you program the yubikeys to not press enter automatically, you could put old key in, for original password, then new key in for new password/confirm password.

Once the password is changed, you then just reprogram the original key, and use the new key for entire duration that you use your password before next periodic change.

One of many solutions, using them as part of a 2-factor scheme where only the user-specific password was changed would be much easier to manage.

The more feasible solution would be to convince the security bods that Yubikeys were sufficiently secure in OTP mode that forced password changes were not necessary or even desirable (for cost reasons).

I see static keys as most useful for environments where you want an difficult to crack password but might not be able to access an authentication server, e.g. offline use, true-crypt, accessing websites hosted by 3rd-party providers ...

What we need is a secure authentication server, which appears to be an issue in itself (e.g, the password reuse problem viewtopic.php?f=3&t=251)

Ed