Re^2: Opportunity to excel

[BrowserUk]

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

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

[BrowserUk]

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.

[jethro]

The userid has to be stored in plain text as well. The ONLY function of the seed (or in this case usually called Salt_(cryptography)) is to prevent rainbow (or similar library) attacks. There is nothing intrinsically "vulnerable" about a visible random seed/salt

If you replace "userid" with "random seed" in your second paragraph, the sentence is still correct. Your userid scheme is cryptographically nothing but a random seed with much less randomness