<div dir="ltr">If these tokens are variable length up to 4k, it will make the search space much to large to construct any kind of useful table. They become infeasible for A-z0-9 variable-length password sets above 10 chars if you include every permutation. Assuming the tokens are generated in a very predictable manner that exclude a ton of possibilities, we shouldn't have to worry about rainbow tables.<div>

<br></div><div>--</div><div>Kevin Benton</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jun 13, 2014 at 12:52 AM, Robert Collins <span dir="ltr"><<a href="mailto:robertc@robertcollins.net" target="_blank">robertc@robertcollins.net</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On 12 June 2014 23:59, Sean Dague <<a href="mailto:sean@dague.net">sean@dague.net</a>> wrote:<br>
<br>
> The only thing it makes harder is you have to generate your own token to<br>
> run the curl command. The rest is there. Because everyone is running our<br>
> servers at debug levels, it means the clients are going to be running<br>
> debug level as well (yay python logging!), so this is something I don't<br>
> think people realized was a huge issue.<br>
><br>
>> Anyway I have sent a patch for swiftclient for this in :<br>
>><br>
>> <a href="https://review.openstack.org/#/c/99632/1" target="_blank">https://review.openstack.org/#/c/99632/1</a><br>
>><br>
>> Personally I don't think I like much that SHA1 and i'd rather use the<br>
>> first 16 bytes of the token (like we did in swift server)<br>
><br>
> Using a well known hash means you can verify it was the right thing if<br>
> you have access to the original data. Just taking the first 16 bytes<br>
> doesn't give you that, so I think the hash provides slightly more<br>
> debugability.<br>
<br>
</div>Would it be possible to salt it? e.g. make a 128bit salt and use that.<br>
The same token used twice will log with the same salt, but you won't<br>
have the rainbow table weakness.<br>
<br>
The length of tokens isn't a particularly strong defense against<br>
rainbow tables AIUI: if folk realise we have tokens exposed, they will<br>
just use a botnet to build a table specifically targetting us.<br>
<br>
-Rob<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Robert Collins <<a href="mailto:rbtcollins@hp.com">rbtcollins@hp.com</a>><br>
Distinguished Technologist<br>
HP Converged Cloud<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div>Kevin Benton</div>
</div>