Re: Yubiserver package ships with pre-filled identities

["Nanakos V. Chrysostomos" <nanakos () wired-net gr>]

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 () rm-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 () debian org
> Debian Developer                         http://people.debian.org/~jmw
>
> 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51