Gosh, that's being a bit harsh. He already admitted that it's not as secure as a random salt. While it's true that using a derived salt is not as secure as a random salt, it is definitely more secure than using no salt at all. With this approach, it is required that A) the "black hat" know your salt algorithm (which, unfortunately, is not terribly complicated in this case but is still better than nothing) and B) the "black hat" generate a hashed dictionary using the now-known salt and a non-hashed dictionary. Again, this approach is nowhere near as secure as when using a random salt, but he is correct in stating that it will slow down, if not keep out, script kiddies.
-Andy Hopper ----- Original Message ----- From: "Thomas Tomiczek" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, January 09, 2003 3:08 AM Subject: Re: [ADVANCED-DOTNET] Salt in PasswordDeriveBytes 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. You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
