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 , §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