Open Stack

On Tue, Jan 7, 2014 at 11:01 AM, Adam Young <ayoung at redhat.com> wrote:

> On 01/06/2014 01:10 PM, Jeremy Stanley wrote:
>
>> On 2014-01-06 10:19:39 -0500 (-0500), Adam Young wrote:
>>
>>> If it were as  easy as just replaceing hteh hash algorithm, we
>>> would have done it a year + ago. I'm guessing you figured that by
>>> now.
>>>
>> [...]
>>
>> With the lack of In-Reply-To header and not finding any previous
>> messages to the list in the past few months with a similar subject
>> line, I'm lacking some context (so forgive me if I'm off the mark).
>>
>> If the goal is to thwart offline brute-forcing of the hashed data,
>> shouldn't we be talking about switching away from a plain hash to a
>> key derivation function anyway (PBKDF2, bcrypt, scrypt, et cetera)?
>> MD5 is still resistant to preimage and second preimage attacks as
>> far as I've seen, and SHA256 doesn't take too many orders of
>> magnitude more operations to calculate than MD5.
>>
>
>
> Sorry to all for the cryptic (ha) nature of this mail.  It was in response
> to an expired code review:
>
> https://review.openstack.org/#/c/61445/
>
> But I thought would benefit from a larger audience.
>
> Note that the Hashes in question are not vulnerable to many of the
> attecks, as they are used primarily on very strict sets of data (the
> keystone tokens) and only between the keystone clients and servers.   It is
> not possible to create an arbitrary token, hash it, and have that at all
> usable in  Keystone.  Which is why MD5 has not been deemed to be a problem
> for us.
>
> I like the Idea of prefixing the hashes with the algorithm, but we still
> need a way to integrate that in.   A specific Keystone server will only use
> one Hash alrgorithm, since it is useing the Hash as the unique ID for a
> database lookup.  Thus, in order for the clients and server to be in sync,
> they need a way to agree on the hash algorithm.  Identifying it in the hash
> is probably too late for most uses.


++ the current architecture requires *clients* to perform the hash, and
make requests against the server using the hashed token. So, the client
needs to know which hash to use, not just communicate the hash it chose to
the service (or have the service published hashed tokens?). Ideally, the
service would only have to index on a single hash, so it should be able to
communicate which algorithm it expects back to clients in order to provide
an upgrade path from MD5.


>
>
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 

-Dolph
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140107/8c5984e9/attachment.html>