Yubico Forum

I have a small design Idea: one of the problems is that with a "normal" yubi slot 1 is preoccupied by the Yubikey, while with the VIP yubikey, that one is used for the VIP credential.

Problem is, if you overwrite for whatever reason these are completely lost.

my Idea would be that instead of saving the default (id starting with "cc") YubiOTP key and/or VIP on the normal config slots to save them on a ROM "behind" those config slots and instead tell the config slots to just use the VIP/YubiCloud credential.

that's maybe a bit similar (but a lot more resticted than) the serial number which the yubi doesnt give out unless permitted.

that way you could also make a key that has both a yubicloud "cc" credential as well as a VIP one without loging the customizability and not effectively locking slot 1 because there's something you dont wanna lose inside there.

I think I push this becase I think it is really important.

because if for example your cc is overwritten and you vv key doesnt work the way it should ("'vv' prefix credentials are not guaranteed to have the same availability as production 'cc' prefix credentials.") also since yubico takes the right to remove and vv key this may get annoying if they actually do because you would need to reupload your key - provided they didn't kill the upload service altogether. if they would do that in the future (who knows but greetings from murphy's law) one could say that you have a problem.

with this Idea it would be possible to just re-enable the YubiOTP (or Symantec VIP code for the VIP keys) and a malicious individual wouldnt be able to delete/overwrite the config just to try to lock out the target.

Sorry, I really don't see a compelling argument here.

We don't sell YubiKeys with VIP credentials anymore. The only option for the general public to use a VIP credential on a YubiKey would be on a NEO or 4 with this - viewtopic.php?f=26&t=1617#p7058 (would use the OATH applet so not applicable here anyway).

It seems like you're taking our legal statement out of context (we get asked about this periodically)...

"'vv' prefix credentials are not guaranteed to have the same availability as production 'cc' prefix credentials." - This literally means if you try to upload a credential you just generated and someone has already uploaded a credential with the same prefix, it won't allow you to use that credential (otherwise it would then invalidate their credential, so what would be the point?). You'd simply generate a new one and try to upload the next one. If you try to upload an identity that already exists, you will get an error at upload.yubico.com that says "Sorry, that yubikey prefix is already in use."

And yes, Yubico reserves the right to revoke credentials at its discretion, but we've never had to do this before. This is just in case we find that someone is abusing the service. People seem to think that Yubico will arbitrarily start deleting credentials for no reason.

The configuration protection access code exists to prevent accidental or intentional deletion of slot credentials. I don't see how adding an additional layer of complexity to the design would be beneficial.

well vip or no VIP, does matter (but it would have been awesome to have a yubi with both VIP and yubiOTP) it is pretty annoying that the key it was delivered can get erased WITH NO WAY BACK and this fairly easily, ESPECIALLY considering there's no way to know what is on each slot in the config tool.

also I dont think you will probably go and kick many of them arbitrarily, but you CAN, you guys could technically even stop doing vv altogether.

also if you mean that you cannot use a prefix that exists already then it might help writing that properly, because the text talking about the availablility makes you think that the vv are "worse" e.g. handled with less priority and whatever.

alos because you say on the site that you kick keys "if the credential is loaded onto a counterfeit YubiKey"

how could you even find that out? the protocol for yubiotp is pretty open iirc so even software can emulate codes without a problem.