Date: Mon, 30 Jan 2012 15:38:18 +0200 (EET) From: "Nanakos V. Chrysostomos" <nanakos@...ed-net.gr> To: "Jonathan Wiltshire" <jmw@...ian.org> 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 Upstream version is no more populated with a test account for both versions, that is 0.1-1 and 0.2-1. Thanks. > 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 , Â§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. >>> >>> >>>  >>> 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
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ