Michael Silk wrote:
> Hi,
> Yes, but assuming that the attacker has gained access to where
> the password and hash are stored, he will be able to access the
> salt (or algo for salt) anyway.
>
> A potential protection against this form of attack is to totally
> slow-down the attacker by, say, hashing the result of your hash
> 50 times.
>
That doesn't really add anything to security. It would still be
vulnerable to dictionary attacks, even though the computation power
needs to be about tripled for the attacker to handle it in the same
amount of time a single hashing would require.
> In this fashion the attacker would need to call a sha-256 or whatever
> hash function 50 times! This would be seriously slow, and (let alone
> the size of sha-256) would hopefully rule out the possibility of a
> brute-force approach.
>
Password policy enforcing is a much better way to go. Forcing passwords
that contain characters from the four different classes (uppercase,
lowercase, digits, special) and are a between 10 and 30 chars long makes
bruteforcing the hash totally unrealistic, since;
pow(92,10) = 43438845422363213824
and
pow(92,30) = 81966203577338201924328653819419157670749425717340457140224
John the Ripper computes about 16000 hashes / second on a dual P4
2.8Ghz, with hyperthreading enabled and 2Gb RAM. If all users were to
choose passwords with 10 characters it would take 8608979 _YEARS_ to
compute all the possible hashes (with 30 chars it would take roughly
10e36*the_age_of_the_universe years). I'm fairly sure the user whose
password gets cracked is long since dead by the time that's over and
done with, even if we all agree that faster computers get built every day.
> -- Michael
>
/exon
Received on Jul 02 2004
Intro
