Open Stack

Right, because your 'site' service catalog is encoded in them, they are
big, of unpredictable length, and they are going to be differently
seeded for every installation out there.

Which is why rainbow tables didn't seem to be a valid threat to me.

	-Sean

On 06/13/2014 05:09 AM, Kevin Benton wrote:
> 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 <mailto:robertc at robertcollins.net>> wrote:
> 
>     On 12 June 2014 23:59, Sean Dague <sean at dague.net
>     <mailto: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 <mailto:rbtcollins at hp.com>>
>     Distinguished Technologist
>     HP Converged Cloud
> 
>     _______________________________________________
>     OpenStack-dev mailing list
>     OpenStack-dev at lists.openstack.org
>     <mailto:OpenStack-dev at lists.openstack.org>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> 
> -- 
> Kevin Benton
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


-- 
Sean Dague
http://dague.net

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140613/92422cff/attachment.pgp>