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 <jmw@...ian.org>
To: Nanakos Chrysostomos <nanakos@...ed-net.gr>
Cc: Gian Piero Carrubba <gpiero@...rf.it>, <team@...urity.debian.org>,
 <oss-security@...ts.openwall.com>
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 <gpiero@...rf.it> 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] 
>> http://static.yubico.com/var/uploads/pdfs/YubiKey_Manual_2010-09-16.pdf

-- 
Jonathan Wiltshire                                      jmw@...ian.org
Debian Developer                         http://people.debian.org/~jmw

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