This looks interesting, but I don't totally understand how it works. How is the key changed every time on the server? It looks like it requires server side support.
They have some fancier keys that support a 'universal 2 factor' standard which I think they may have had a hand in creating.
I've used mine in OATH-HOTP and HMAC-SHA1 along with KeePass to do two-factor on my password db. You do need a server-side or peer component to initially sync with to do OTP or challenge-response.
Each side has a seed value which then allows the calculation of what the current value should be.
Each Yubico OTP has a plain text public ID as the first 12 characters of the OTP. This is used to identify the YubiKey which generated the OTP without having to perform any OTP processing. The remaining 32 characters of the OTP are an AES-128 bit encrypted hash. This hash is made of the Private ID, a string known only to the YubiKey and Authentication server, to further validate the OTP.
In addition to the Private ID, the OTP also contains counters tracking how many times the YubiKey has been power cycled (usage) and how many OTP events it has preformed since it's last power on (session). These counter values are stored in the authentication server and checked for each OTP. If the usage counter is less than the value on the server, or if the session counter is less than or equal to the value on the server, the OTP is rejected as a replay attack.
This means the YubiKey OTP will not get out of sync with the validation server, as well as adding additional randomness to the OTPs generated.