If the attacker doesn’t know any of the three, their brute force would look like:
{guess}{guess}{guess}
{guess1}{guess}{guess}
.
.
{guess}{guess1}{guess}…

If the attacker does know one or more of the salts:
salt{guess}{guess} or salt{guess}salt
salt{guess1}{guess} or salt{guess1}salt…

So you lower the amount of work they would need to do to break any one particular password by using salts they could know.

Here’s what I do:
I generated a very long random string using every kind of character. I keep it in my php scripts and that is the same for all my passwords.
Then I add another row to my users table to store a private salt for each user, which is generated and stored automatically by PHP when the user registers.

When a user logs in I take the username they entered, get the private salt with it, add the public salt, hash it and check against the stored password. A hacker would have to compromise both the php script AND the database to get both the salts.

Finally, this is all mostly useless if you’re using md5 which has been broken in oh so many ways(though not completely). I would use something like whirlpool or sha-1[if you trust the government ]

It’s true that you could build your own hash database, but would it not be prohibitively expensive (time and disk wise)? I thought the beauty of rainbow table attacks is that you precompute the rainbow table once, then you can store it indefinitely. Whereas I haven’t heard the argument that the principle of hashing in itself is flawed.

I understood that passwords were stored as salted hashes so that a rainbow table would be useless. In effect, an attacker would need to generate a new rainbow table for every user, which would be prohibitively expensive.

I think I’ll go with something like md5( username . password . domain ). It would be possible from that data to break the passwords, but it would require a *huge* amount of work.

FWIW, the largest hash database I know of is Gdata (http://gdataonline.com/). Presumably from their homepage they have 670M hashes – which is just a bit less than 64^5.

The storage cost for 64^5 is 4G just for the hashes – and for 64^6 it’s 256G, so it starts to get expensive quickly.

So simply combining the two would not provide adequate protection against rainbow attacks. Very true. But the two combined with a known constant, such as the site URL, would presumably overcome this issue. Each record would be individually unique, and the whole namespace would also be globally unique.