<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 7, 2014 at 11:01 AM, Adam Young <span dir="ltr"><<a href="mailto:ayoung@redhat.com" target="_blank">ayoung@redhat.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 01/06/2014 01:10 PM, Jeremy Stanley wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 2014-01-06 10:19:39 -0500 (-0500), Adam Young wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If it were as  easy as just replaceing hteh hash algorithm, we<br>
would have done it a year + ago. I'm guessing you figured that by<br>
now.<br>
</blockquote>
[...]<br>
<br>
With the lack of In-Reply-To header and not finding any previous<br>
messages to the list in the past few months with a similar subject<br>
line, I'm lacking some context (so forgive me if I'm off the mark).<br>
<br>
If the goal is to thwart offline brute-forcing of the hashed data,<br>
shouldn't we be talking about switching away from a plain hash to a<br>
key derivation function anyway (PBKDF2, bcrypt, scrypt, et cetera)?<br>
MD5 is still resistant to preimage and second preimage attacks as<br>
far as I've seen, and SHA256 doesn't take too many orders of<br>
magnitude more operations to calculate than MD5.<br>
</blockquote>
<br>
<br></div>
Sorry to all for the cryptic (ha) nature of this mail.  It was in response to an expired code review:<br>
<br>
<a href="https://review.openstack.org/#/c/61445/" target="_blank">https://review.openstack.org/#<u></u>/c/61445/</a><br>
<br>
But I thought would benefit from a larger audience.<br>
<br>
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.<br>


<br>
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.</blockquote>

<div><br></div><div>++ 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.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div><br></div>-Dolph
</div></div>