On Sun, Apr 20, 2008 at 2:36 AM, Michael B Allen <[EMAIL PROTECTED]> wrote:
> On Sat, Apr 19, 2008 at 6:24 PM, Isaak Malik <[EMAIL PROTECTED]> wrote: > > 'What exact attack scenario is this "static [salt] which is located > > outside of your web root" supposed to protect against?' > > > > This will increase the difficulty of cracking your hashes with brute > force > > when the hacker has access to your database, by only using the salt > stored > > in the database it will be the same for the hacker as if no salt was > used to > > hash the password. > > I don't even understand this statement so it's hard to comment. But I > have a feeling that you don't understand how the hashing methods we're > talking about actually work. It's possible that I'm going a bit off-topic as I didn't read every email on this subject. But to explain what I'm talking about: let's say for example the attacker has a dictionary containing the following: password password123 passw0rd p4ssw0rd Password If the webmaster makes use of randomly generated salts the attacker would have more trouble cracking since the cracking software probably won't find duplicate hashes in the database. I guess that what you are talking about is that the attacker generates different wordlists for every salt before starting the attack, what I'm talking about is that the attacker is "smart" enough to use or create a software that automatically prepends and/or appends the salt to the word from the list if given and then compared to the password hash from the database. Let's say that the attacker found the login details for the database, which you probably think is very unlikely since you find the static salt useless. I'll mention a common example: --- The webmaster stores the database connection details in database.inc and loads the details via the ZFW Config class then connects to the database, the clever or lucky attacker found the database.inc file and is able to see its contents because the webserver displays it as plain text by default. This far the attacker wins the battle. --- Note: The above example is not necessarily put in practice because the webmaster uses the ZFW, I'm just pointing out a very common way of storing important data in a very insecure way and put it in context with the ZFW since we are discussing this subject on their mailing list. Since we now both agree (at least I hope so) that this can happen the static salt would be an extra layer of protection since the attacker either doesn't know about it or doesn't have access to it so his wordlist wouldn't be much help. This time the webmaster wins the battle. > > > "Have you read it? You have to calculate an individual dictionary for > > every password." > > > > Yes I did read it, even if a password has been cracked it won't be much > > trouble for the hacker to crack a duplicate even if it has another salt, > > unless we're talking about a dictionary containing millions of words. > > Ahh, yes, you definitely don't understand how these hashing methods work. > > A password salt is a randomly generated value that is computed anew > every time someone sets their password. Even if the same user sets the > same password twice the salt and thus the hash will be totally > different every time. To crack one single password the attacker would > have to compute a dictionary of passwords with that specific salt just > to crack that one password. That's not likely. An additional "static > salt" does not help unless the attacker has the password database but > not the "static salt" which is also not very likely. > <http://www.ioplex.com/> > That was exact the same thing I said.. Except for that you take it into context when the attacker generates a dictionary of passwords combined with the salt before commencing the attack, I'm talking about, which I also mentioned above, that the attacker creates the hashes live and then comparing to the hashes, perhaps this is a method less used by professional crackers since this requires more CPU resources but it is certainly possible. This should explain why the static salt would be of use. -- Isaak Malik Web Developer
