Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Mon, 30 Jan 2012 11:56:22 +0000
From: Jonathan Wiltshire <>
To: Nanakos Chrysostomos <>
Cc: Gian Piero Carrubba <>, <>,
Subject: Re: Yubiserver package ships with pre-filled identities

On 2012-01-30 06:43, Nanakos Chrysostomos wrote:
> Hi again,
> I found another reason for not shipping the package with an example
> account. I think you are certainly right. If you haven't filled a bug
> please do so, in the meanwhile I will upload to mentors a new version
> with an empty database that resolves the problem. Thanks.

This populated database is also shipped in the upstream tarball, 
oss-security should be consulted to see whether a CVE identifier should 
be issued.

Adding to CC; oss-sec please see below:

> On 30 Ιαν 2012, at 1:25, Gian Piero Carrubba <> wrote:
>> Hi Nanakos,
>> 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  
>>> wrong.
>> 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 
>> credentials.
>> Please refer to [0], §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 
>>> the OTP.
>> And in §6.1:
>>> The Yubikey OTP generation is made up of the following fields
>>> [..] Private (secret) id
>>> [..] Usage counter
>>> [..] Timestamp
>>> [..] 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  
>> the
>> 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).
>> Ciao,
>> Gian Piero.
>> [0] 

Jonathan Wiltshire                            
Debian Developer               

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51

Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ