> But a straight md5sum leaves you open to a dictionary attack.
Of course. I argue everything does.
> You want
> to add some salt by doing something like this:
>
> salt = random_4_char_string;
> encrypted_password = salt + md5sum(salt + cleartext_password);
I've always wondered about this. It just means for a dictionary attack,
instead of:
if (encpass == md5sum (dictionaryword))
you do
if (encpass == substr(encpass,4)+md5sum(substr(encpass,4)+dictionaryword))
Which obviously is just linearly slower than the normal dictionary attack.
What is the purpose of the salt in this case? I can only assume the
standard documented of using a salt is wrong, because I've never seen an
implementation that I could see increased the security over plain
hashing.
The only way I could see a salt increasing security is thusly:
salt = SomeSuperSlowAlgorithm (password)
encpass = md5sum (salt + password)
But you'd achieve as much by saying encpass=SuperSlowAlgo(password).
No matter how you obfuscate it, unless you can somehow turn it into a
O(x^n) problem, you're prone to dictionary attacks.
This is why most modern password-prompting algorithms do a "dictionary
attack" on your password and worn you. Witness:
Changing password for user postgres.
New UNIX password: (I enter "greatone")
BAD PASSWORD: it is based on a dictionary word
So basically, your only hope is to either obfuscate the argument you pass
to md5sum (or whatever hash algorithm), somehow protect your md5sum list
of passwords(note that the shadow password file on Unix systems isn't
world readable), or ensure that all passwords entered by all users are not
attackable by a dictionary attack.
Can anyone explain to me why a salt is really a good idea or if, as I
suspect, it was an idea with good intentions that really doesn't help
anything?
--
Tim Ellis
Senior Database Architect
Gamet, Inc.