thanks for your prompt response.
* [Sun, Jan 29, 2012 at 11:19:37PM +0200] Nanakos Chrysostomos:
those keys are invalid and are not my real keys. It's just a sample
for the potential users of the package to see.
Ok, good for you :) .
According to yubico one in a billion or trillion I think , two
users might have/use the same credentials aka public id, private id
and aes key. I think there is no need to worry, but I might also be
While I certainly can be wrong, and surely I'm not a security
expert, I strongly disagree about it not being a problem.
First of all consider that this is not the case of two users
casually having the same credentials (anyway logging in two different
services, think as the public id should be unique for every realm),
but an authentication service that is preconfigured with known
Please refer to , Â§2.3.5:
Given the symmetric nature of the AES encryption algorithm, the
security of the Yubikey relies that the AES key is logically and
physically protected both in the key and in the server that verifies
And in Â§6.1:
The Yubikey OTP generation is made up of the following fields
[..] Private (secret) id
[..] Usage counter
[..] Session usage counter
[..] Random number
[..] CRC16 checksum
Where it is clear that the only authentication related field (apart
from the aes key encrypting the string) is the private id.
This is also reflected in your validate_otp() implementation, where
- given the decrypted otp - the only authentication check is against
private_id. The other checks that could lead to a BAD_OTP error
(namely against crc and counter) are there only for invalidating data
corruption and replay attacks.
Please at last note that the uid and the aes key cannot be retrieved
from a yubikey. This is a security feature in order to protect the
stored accounts, but as for the symmetric nature of the key it should
be applied on both sides (yubikey and validation server).