Opportunity to excel

[pemungkah]

http://www.securityfocus.com/blogs/262

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 http://www.infoworld.com/d/security-central/myspace-password-exploit-crunching-numbers-and-letters-983 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.

[jethro]

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.

[BrowserUk]

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.

[jethro]

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

[Your Mother]

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.

[jettero]

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.

oechslin