Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery
 
PerlMonks  

Re: Opportunity to excel

by jethro (Monsignor)
on Aug 02, 2009 at 12:49 UTC ( #785235=note: print w/ replies, xml ) Need Help??


in reply to Opportunity to excel
in thread Status of Recent User Information Leak

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.


Comment on Re: Opportunity to excel
Re^2: Opportunity to excel
by BrowserUk (Pope) on Aug 02, 2009 at 14:39 UTC
    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

        I didn't mean instead of a seed. By all means keep your random seed, but if you're going to store that in plain text, it is just as vulnerable as a plain text password once you have been compromised!

        You always have two pieces of information--userid and password--making the hash dependant upon the combination, means the bad guys have to build rainbow tables for every combination of userid and password. Ie. You're back to massive combinatorics.


        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.

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others taking refuge in the Monastery: (4)
As of 2014-11-28 00:19 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My preferred Perl binaries come from:














    Results (190 votes), past polls