Beefy Boxes and Bandwidth Generously Provided by pair Networks
Do you know where your variables are?

Opportunity to excel

by pemungkah (Priest)
on Jul 31, 2009 at 20:57 UTC ( #784996=note: print w/ replies, xml ) Need Help??

in reply to Status of Recent User Information Leak

Highly-recommended article on making password attacks unprofitable, especially "rainbow table" attacks.

Summary: make computing the hash slow. Really slow. Like 2 or 3 seconds, or more. Provos-Maziere’s Bcrypt scheme lets you make it as slow as you want. This lets you make computing the rainbow table so prohibitively slow that breaking in by password guessing is unprofitable.

(Rainbow tables are huge tables of hashes with the corresponding text that made them. Look up a hash; if you found it, you win and can get in. So "dumb" passwords are almost certainly in a big rainbow table. But! If you use a really slow hashing algorithm, it's too unprofitable to compute more than a "few". If you added on the analysis from and outright disallowed the most common "dumb" passwords, you'd be way ahead.)

There's definitely an opportunity to step on this business of "wow, those Perl guys are so clueless they stored their passwords in plaintext" hard. If I can help out, let me know.

Comment on Opportunity to excel
Re: Opportunity to excel
by Your Mother (Canon) on Jul 31, 2009 at 21:55 UTC

    I would truly appreciate any of the code that might be developed being made public; along with the process of developing it (stages, discussion, critiques). I'm okay on security but I'd like to be a rock and code/techniques for Bcrypt and salting hashes are two things that would be edifying for JAPHs everywhere.

Re: Opportunity to excel
by jettero (Monsignor) on Aug 01, 2009 at 02:28 UTC
    I don't think rainbow tables are big tables of hashes. ... they seem to have more to do with hash chains than big tables of precomputed hashes. I don't really understand it myself, but I'm pretty sure I have that much right.



Re: Opportunity to excel
by jethro (Monsignor) on Aug 02, 2009 at 12:49 UTC

    Making the hash algorithm really slow makes the hash unusable in most practical situations. If you need two seconds on a fast machine for the hash to compute, login to a website would make the server unresponsive for two seconds. Everyone could do a denial-of-service attack to that website by simply doing one (failed) login attempt per second!

    Also rainbow tables will find good passwords with the same chance as dumb passwords. Rainbow tables are precomputed lists. For every entry you hash a random password, then hash the resulting hash, and so on for (lets say) 100000 times. Store the last hash as key and the starting password as data in your database. Now do this precomputation for a year or so

    If you now want to crack a hash, just hash it, then hash the resulting hash and so on until you find a hash that corresponds to a key in your database. If you find one after rehashing less than 100000 times you have a winner. Now you only need to use the starting password of that database entry and do the rehash cycle from there again until you find the value in the chain just before the hash you got. That is your password (in reality always a collision with the original password).

    So rainbow tables in fact allow a costly brute force search, because you need to do it only once for a specific hash algorithm and can do it in preparation for the actual cracking.

    The often mentioned seeding does not prevent rainbow tables but makes them expensive again because you need a separate rainbow table for each individual seed value.

      The often mentioned seeding does not prevent rainbow tables but makes them expensive again because you need a separate rainbow table for each individual seed value.

      Hash the userid and password together.

      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.

        Hash the userid and password together.

        That would just be like a seed but with a guessable instead of a random value. Would make it possible to generate rainbow tables for common userid ranges (or if you meant usernames, for common usernames).

        Storing the seed in front of the hash value is neither expensive nor difficult and there is no reason to optimize randomness away for a clever trick to save a few kbyte

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://784996]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others avoiding work at the Monastery: (9)
As of 2014-10-23 00:02 GMT
Find Nodes?
    Voting Booth?

    For retirement, I am banking on:

    Results (122 votes), past polls