Unfortunately it would seem that we've entirely lost sight of what we're talking about, and are now at the point where we just reiterate standard sayings related to security. Can we either get back to the exact subject at hand, or just drop this discussion.
First of all, we've lost sight of what a Salt is, and what it's used for. We've addressed the fact that something that should be random, should in fact be random, and using something that is guessable (such as a reversed username) is not random. But we need to look at why a salt needs to be random. First of all, here is the definition of a salt, by an expert in the field (Bruce Schneier): "Salt is a random string that is concatenated with passwords before being operated on by the one-way function." And why do we use salt? "Salt is a way to make [a dictionary attack] more difficult." That's it. Salt is a way to protect your password database against dictionary attacks. What is a dictionary attack? A dictionary attack is a way to determine what was hashed by a one-way hash function. Because a one-way hash function is an irreversable process (or it should be at least), the approach taken is to take a set of known strings, and then compute their hashes, and store the set of string:hash pairs. Now when an unknown hash is presented, we just see if it matches any of the precomputed hashes, and if so, then we know what must have been hashed, and the problem is solved. So how does salting make dictionary attacks more difficult? Instead of a single password being associated with a single hash, a single password can have as many possible associated hashes as there are possible salts. Big bad cracker can't come along with a dictionary of precomputed hashes and simply compare it to your password file. Instead, she has to look at each individual entry in the password file and recompute the hashes for her strings, concatenated now with the salt. So now instead of cracking every entry in your password file in one broad sweep, a concerted effort must be made for each password on it's own. An important thing to note is that salting does not prevent dictionary attacks, it only makes them harder. For example, if you only use 2-bits for your salt (4 possible values), then an attacker just has to compute four times as many entries in his dictionary, and he can now use that dictionary against your entire password file. So now we'll address this clearly uneducated claim that using the username (reversed or otherwise) kills the effect of salt. Hopefully if you've followed everything so far, you'll see that it definitely does not kill the advantage of salt. It clearly prevents an attacker from using a precomputed dictionary of hashes to crack your entire password file. The attacker would clearly have to recompute the hashes for every word in the dictionary for each entry, and so a concerted effort must be made for each individual entry. In fact, assuming usernames must be unique, it ensures that a dictionary made for one entry cannot work on another entry, whereas with a random salt there is a tiny chance that the same salt will be chosen for two entries, and so one dictionary could work on both of those entries. Now, an attacker could take a list of common passwords along with a list of common usernames then create a dictionary with each of these passwords combined with each of these usernames, but the point is that the dictionary would still have to be much larger. If we have 1000 common usernames, then the dictionary would have to be 1000 times as large, simply because we used the usernames for salt. Clearly we've made a dictionary attack more difficult. Now the downside is that the number of possible salts is less than it could be were we to choose a random salt. It's the same effect as say limiting passwords to only alpha-numeric characters. You limit the number of possible keys. So supposing that usernames must be 8 lowercase characters. There are now 2.1*10^11 possible usernames, and therefore that many possible salt values. So now for an attacker to check if any of your users have a password of "abcdefg" without knowing the salt, then that attacker must precompute 2.1*10^11 hashes in order to account for every possible salted value. So having one master dictionary of every possible hash for every common password becomes much less feasible. In fact, for the sake of argument assume that every possible 8 lowercase character username is possible (obviously this is a silly assumption, but let's make beleive for a moment), then this is approximately equivalent to using a 38 bit salt that is randomly generated (note UNIX systems commonly use 12 bits of salt). Now obviously every username is not equally likely, but you can see that we have clearly not killed the advantage of using a salt. If he had said that "by using an 8 character username as a salt we have made a dictionary attack 2^64 times as difficult", then yes he'd be sitting with a false sense of security. But no claim like that was made, and in fact his salting approach does make a dictionary attack a fair bit more difficult, so it sound to me like a very decent scheme, and he should have a greater sense of security by using that scheme. I could go on about salting forever it would seem, so we'll just end it here. Hopefully this has cleared up a few things, or at least been somewhat informative for at least a few on this list. Jordan Frank eBusiness Applications www.ebusinessapplications.ca [EMAIL PROTECTED] PS: Can we please try to have even just one discussion about security without using the term script kiddy. It's a stupid term, generally used to belittle a group of people who really have nothing to do with anything related to this discussion. Plus, I think it's really silly to call anyone a script kiddy when you're in the security profession. One day, inevitably, one of these people you called a script kiddy is going to break into one of your client's system, or one of your systems. How are you going to explain to either your employer or your client that someone whom you yourself has labeled a complete idiot has outsmarted you. Better just to keep your mouth shut in the first place. Just my opinion though. ----- Original Message ----- From: "Thomas Tomiczek" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, January 10, 2003 3:57 AM Subject: Re: [ADVANCED-DOTNET] Salt in PasswordDeriveBytes IMHO there is not something like "a bit harsh" in regards of security. I accept the "security against the script kiddy" argument, but for anything else, salt should be white noise. The (false) assumption that you have a secure encryption algorythm, where in reality you do not have one, is the worst thing that you can actually have - much worse than not having an algorythm at all, because then you KNOW that you are unprotected. Regards Thomas Tomiczek THONA Consulting Ltd. (Microsoft MVP C#/.NET) > -----Original Message----- > From: Andrew Hopper [mailto:[EMAIL PROTECTED]] > Sent: Thursday, January 09, 2003 8:57 PM > To: [EMAIL PROTECTED] > Subject: Re: [ADVANCED-DOTNET] Salt in PasswordDeriveBytes > > > 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. > 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.
