Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 30 Jan 2012 15:38:18 +0200 (EET)
From: "Nanakos V. Chrysostomos" <>
To: "Jonathan Wiltshire" <>
Cc: "Gian Piero Carrubba" <>,,
Subject: Re: Yubiserver package ships with pre-filled identities

Upstream version is no more populated with a test account for both
versions, that is 0.1-1 and 0.2-1.


> 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