Re: Securing encrypted data in RAM vs MSSQL

[exon <exon () home se>]

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