Open Stack

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.

--
Kevin Benton


On Fri, Jun 13, 2014 at 12:52 AM, Robert Collins <robertc at robertcollins.net>
wrote:

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



-- 
Kevin Benton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140613/22490ed4/attachment.html>