Yubico Forum

I, too, am pretty new to this, but here's how I understand it.

First, you can't have the Yubikey output one of GRC's passwords since the Yubikey will only output modhex characters. The modhex characters are cbdefghijklnrtuv equivalent to the hex characters 0123456789abcdef, respectively. This limited set of characters was chosen, I believe, because it is optimally consistent over keyboards in numerous languages.

You can use one of the GRC passwords as the input in Ferrix's script that's earlier in this thread. If you enter one of the GRC 64 hex character passwords, the resulting Yubikey static password output will be the 32 character modhex representation of the first 32 characters of the GRC password followed by another 32 characters that are created by the encryption process. If you use the same input into the script, you get the same result each time so there's no problem creating four identically coded static YKs. If you store the input string, you can use it at some point in the future to create additional YKs with that same static password.

If all you want to do is program static passwords, the use of Ferrix's script rather than the Yubico Personalization Tool is simpler and gives you the option of a full 64 character static password. As far as I can tell, the current Yubico tool only permits static passwords up to 56 characters.

For static password use, you might want to opt to leave off the "Enter" at the end of the password string. Since most sites/programs require you to reenter the password when you first set it, the "Enter" at the end of the string may make it impossible to get to the point of entering the verification. I would enter the password in the first blank, it would automatically generate the "Enter" and I'd get a message that the two entries didn't match. By doing away with the automatic "Enter" I was able to enter the password and the verification before manually pressing "Enter".

You mention being "on the road". If you are concerned about the possible loss of a YK that is set to static mode, you might want to consider a combination manually entered and YK entered password. For example, you type in "123456" without pressing "Enter" and then you trigger the YK. This gives you a password such as 123456cbdefghijklnrtuv...(up to 64 characters". That way, even a lost YK isn't going to get too far.

Keep in mind that once you've reprogrammed the YK to a static password, it will no longer function in OTP mode until properly reprogrammed using the Yubico Personalization Tool so that the authentication server can recognize the YK. While I've had no problem programming for static use, my efforts to reprogram one back to OTP use are, so far, without success. I point that out merely so that you realize that the reversal of the process may not be as simple as the conversion to static mode.

Dick

Thanks and more thanks.

You started out by saying that you were new to this also, but I must say that if that is new, then I would not like to see what your response would be if you were experienced.

Now if I got this right, all I need to do is get a set of 64 character passwords from GRC and put them somewhere in the script you pointed me to. From there I save the script and go through the Strat Run and browse to the script and it should go through from there - right?

Once we get that to work, can we use the YK Personalisation Tool to lock the key to prevent any reconfiguration?

You'll need to download and install the Yubico Personalization Tool in order for the script to work. You can get it from the Binary Installer Link at

http://www.yubico.com/developers/personalization/

Save the script as statickey.wsf just as it is. You don't need to actually edit the GRC password into the script. It will prompt you for the hex string that you want to use when you run the script.

If you run the script by double clicking on it, you'll be prompted for the 32-64 hex characters. This is where you can enter one of the 64 character GRC hex passwords. Just follow the instructions that will appear and you'll be all set.

If you want to eliminate the "Enter", open the script in a text editor and make the change that's shown in the comment section of the script. Resave the edited script and you should be good. I saved it as statickey_NoCR.wsf so that I have two scripts and I can use whichever one I choose without having to edit each time.

And, yes, if you like, you can then use the Yubico PT to set a password to prevent reprogramming without the password. I can only think of very limited reasons why I'd bother doing that, but perhaps I'm missing something there.

Dick

Well, I guess the time has come to try doing this so I can only hope I get it right.

The need to set the password to prevent re-programming is just that - to prevent re-programming. Since we are going to be using them in client environments we really should do all we can to protect them. In fact, you have given me a great idea of mixing the static key with a manually entered part of the password. There actually is something that we can use in that format that will make sure that the password is unique to each client location.

So it is now trial and error time so I am going to hope this whole idea of mine works.

If you read the (copious) instructions in this script:
http://s3.collectivesoftware.com/statickey.wsf

It should answer all your questions. It was specifically designed to be compatible with input from GRC passwords. It also explains how your input gets altered by the key's algorithms, and so is not going to be the exact string you start with. Finally, if you use the same input string each time, you can make identical (cloned) static keys.

Edit: I thought this was a new question based on how it looked in my RSS feed. I guess I just re-answered stuff that others already said.

Not intending to be argumentative, but rather to be more informed, I'd appreciate if you could explain a bit more how setting the reprogramming password adds to the security of the YK. Seems to me that if someone reprograms one, the only thing that would happen is that it would no longer contain the necessary password to access whatever it is that it is intended to access.

There is a possible security value to avoiding the reprogramming of the auto-navigation function, but that seems pretty insignificant.

Dick

Not argumentative at all. This is exactly how good ideas are born and grow into great and brilliant.

The logic is more based on placing another obstruction in the way of those who like to believe that they are technically aware and can do whateverr we do. Also, I am expecting that it should prevent accidental re-programming of a key.

Ah, got it. Since my retirement I have the luxury of not dealing with clients who may fiddle with things and thereby mess up what has been devised by others who know better. Prior to retirement I never could figure out a way to keep some of them from doing things despite my advice to the contrary. I therefore have a tendency to forget that aspect of why one might want to lock things up.

Dick

So now I have a key that constantly spits out a 64 character passwrod, but I have a feeling that I did something stupid because now I am not able to protect the key from reprogramming. Is it possible for me to still get the AES Key and the YK ID?

I just played with it a bit. Looks like if you want to set the reprogramming password, you have to use the Yubico PT to set the static password and the reprogramming password at the same time. The only downside to this appears to be that you only get 56 instead of 64 characters for the static password. I guess it's a trade off between the extra 8 modhex characters in the static password and the ability to set the reprogramming password.

I assume that if one were comfortable with programming, one could modify the script to add the reprogramming password. The parameters are in the Yubico Configuration - Integrators Guide.pdf at C:\Program Files\Yubico\YubiKCom SDK\Doc\.

Dick