Open Stack

I ran this by our team for an opinion on the crypto side of things. Here is
their response:

"uuid4 is fine. All it does is take 16 bytes of randomness from os.urandom
(although a 128-bit uuid4 only encodes 122-bits of randomness since the
first 6 bits encode the version of the uuid). Using M2Crypto to generate
those random bytes is of little to no value as OpenSSL seeds its CSPRNG from
/dev/urandom on POSIX systems anyway (crypto/rand/rand_unix.c if you want to
look).

To address the statement in RFC 4122: This statement is true for any version
of uuid other than uuid4. Since you have 122-bits of RNG state encoded into
a uuid4 string you¹d expect an attacker to have 2^(-122) probability of
predicting the next token based on the value of the current token received
(assuming the underlying RNG is secure, which is a required assumption). (If
you had 2^61 simultaneously valid sessions you¹d have a good probability of
uuid4() creating the same token twice, but since storing 2^61 128-bit
strings requires 3.68934881474191E19 bytes I think we¹re probably safe)"

Thanks,
Jarret


From:  Abu Shohel Ahmed <ahmed.shohel at ericsson.com>
Date:  Monday, February 10, 2014 at 8:19 AM
To:  "openstack-security at lists.openstack.org"
<openstack-security at lists.openstack.org>
Subject:  [Openstack-security] Authentication token generation using UUID

Hi,

Currently, Keystone Token provider (both PKI and UUID) relies on uuid.uuid4
to generate token which
is used as an authentication token during its lifetime.

def _get_token_id(self, token_data):
     return uuid.uuid4().hex

My question is how secure is UUID4 token. According to RFC 4122

"Do not assume that UUIDs are hard to guess; they should not be used
   as security capabilities (identifiers whose mere possession grants
   access)"


The implementation of UUID4 relies on os.urandom() which provides pretty
good randomness. However, there are still
concerns about its randomness. See the thread here
http://stackoverflow.com/questions/817882/unique-session-id-in-python.

Should it be a security bug for keystone ? If it is, both PKI and UUID token
generation process is vulnerable.

...shohel


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140210/6e836b5f/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5551 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140210/6e836b5f/attachment.bin>