Re^4: Opportunity to excel

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.

RIP PCW

Comment on Re^4: Opportunity to excel

Replies are listed 'Best First'.
Re^5: Opportunity to excel by jethro (Monsignor) on Aug 02, 2009 at 16:36 UTC
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	[reply]

Replies are listed 'Best First'.

Re^5: Opportunity to excel
by jethro (Monsignor) on Aug 02, 2009 at 16:36 UTC

Salt_(cryptography)

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

[reply]