Congratulations. You have propably managed to completly destroy the advantage of salt in your usage. Using a derived salt value means, at least to my understanding of the maths involved, that you have just KILLED the effect.
Regards Thomas Tomiczek THONA Consulting Ltd. (Microsoft MVP C#/.NET) > -----Original Message----- > From: Craft, Steve [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, January 08, 2003 7:08 PM > To: [EMAIL PROTECTED] > Subject: Re: [ADVANCED-DOTNET] Salt in PasswordDeriveBytes > > > In the case of storing username/password in a database table, > I just use a "salt" of the username backwards and append that > to the password before it gets encrypted and written to the > password column. > > In normal app usage, the username is looked up and then the > backwards username is appended to the password and that hash > is compared to the password column. > > That's not the most earth-shattering way of doing things, but > it should slow down any script-kiddie that gets the password > file; he will have to append the username to every password > try on every different table row. It also makes the salt > different for each user, but is easier to maintain than a > random number (or even a well-known hard-coded number) for each one. > > > You can read messages from the Advanced DOTNET archive, > unsubscribe from Advanced DOTNET, or subscribe to other > DevelopMentor lists at http://discuss.develop.com. > You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
