RE: Securing encrypted data in RAM vs MSSQL

["Michael Silk" <michaels () phg com au>]

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.

        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.

-- Michael

-----Original Message-----
From: Dean Saxe [mailto:Dean.Saxe () DigitalInsight com]
Sent: Friday, 2 July 2004 3:35 AM
To: 'Bénoni MARTIN'; Toro, Daniel; Stan Guzik; Dave Andrews;
webappsec () securityfocus com; forensics () securityfocus com
Subject: RE: Securing encrypted data in RAM vs MSSQL


Shouldn't a salt value added to the plaintext before hashing effectively
make this kind of a dictionary attack much more difficult, if not
impossible, to perform since you would have to recover the salt and
plaintext?

-dhs

-----Original Message-----
From: Bénoni MARTIN [mailto:Benoni.MARTIN () libertis ga]
Sent: Thursday, July 01, 2004 1:19 PM
To: Toro, Daniel; Stan Guzik; Dave Andrews; webappsec () securityfocus com;
forensics () securityfocus com
Subject: RE: Securing encrypted data in RAM vs MSSQL


Well, there is always a way to recover the real password or login from a
hash...the matter's is the time it will take!


The method to "dehash" a hash is quite simple: as theorically a hash_1 can
be produced by a single pass_1/login_1/..., we can create a huge amount of
random pass_2/logins_2/..., hash them with MD5/SHA-1/... and then compare
each of them with our hash_1. ASA the two hashes are the same, we can pick
up the pass/login/... which produced hash_2. Quite simple but really long to
perform.

BTW, Cain & Abel, John the Ripper and Crack can perform such recoveries...
:)


This email message and accompanying data may contain information that is confidential and/or subject to legal 
privilege. If you are not the intended recipient, you are notified that any use, dissemination, distribution or copying 
of this message or data is prohibited. If you have received this email message in error, please notify us immediately 
and erase all copies of this message and attachments.

This email is for your convenience only, you should not rely on any information contained herein for contractual or 
legal purposes. You should only rely on information and/or instructions in writing and on company letterhead signed by 
authorised persons.