RE: Securing encrypted data in RAM vs MSSQL

["Yvan Boily" <yboily () seccuris com>]

This will not yield the password; it will yield a value that, when hashed,
will yield the same MD5 checksum.  Hashes can yeild the same result from
various inputs.  These are called hash collisions.  If you are performing a
simple MD5 hash without any additional transformations on the data then an
identified value that will yield such a hash collision would suffice as the
password.  This is why authentication using only a hash algorithm is not
always the best way to do it.

Yvan Boily
Seccuris  

> -----Original Message-----
> From: Bénoni MARTIN [mailto:Benoni.MARTIN () libertis ga] 
> Sent: Thursday, July 01, 2004 12: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... :)
>
>
>
> -----Message d'origine-----
> De : Toro, Daniel [mailto:tcvx () taconvino cl] 
> Envoyé : jeudi 1 juillet 2004 17:33
> À : Stan Guzik; Dave Andrews; webappsec () securityfocus com; 
> forensics () securityfocus com
> Objet : Re: Securing encrypted data in RAM vs MSSQL
>
> Related to point 3.A below: Is it really necessary to delete 
> the data if it's encrypted with a one-way encryption algo 
> like MD5?  There's no way to recover data from the message 
> digest produced by MD5 that I know of.  Of course, I don't 
> know everithing. :-)
>
>
>
> On Thu, 1 Jul 2004 09:24:55 -0400, Stan Guzik <SGuzik () ImmediaTech com>
> wrote:
>
> > See reply below.
> >
> > Good Luck,
> > Stan
> >
> > -----Original Message-----
> > From: Dave Andrews [mailto:dave () pint com]
> > Sent: Wednesday, June 30, 2004 8:52 PM
> > To: webappsec () securityfocus com; forensics () securityfocus com
> > Subject: Securing encrypted data in RAM vs MSSQL
> >
> > Hello All,
> >
> > Is anyone aware of a way to store encrypted sensitive data 
> in RAM for 
> > access via a web application using ASP?
> >
> > 1) You can create an ActiveX EXE that will remain in 
> memory.  When the 
> > web application loads instantiate the ActiveX EXE and 
> access it like 
> > any other dll.
> >
> >
> >   It would be posted in the same
> > manner.
> > Is storing in RAM preferable to using an encrypted 
> database, in this 
> > case SQL 2000?
> >
> > 2) It depends on the application and network environment.  
> This is a 
> > difficult question to answer not knowing more details.
> >
> > Is there anyway to securely delete or timeout the data 
> after a certain 
> > period of time?
> >
> > 3) A. If you store the data in memory you can kill the 
> instance of the 
> > object and the memory will be released.  Depending on the 
> type of RAM 
> > you have the data may or may nor remain on the chip for a 
> short period 
> > of time.
> >
> >  B. I'm not sure how to easily delete data from a SQL Server DB and 
> > not have it recovered by a forensics tool.  A difficult way 
> of doing 
> > it is to compact the SQL Server DB which will shrink the DB 
> file size 
> > and then use PGP Freespace Wipe to permanently delete any 
> residual data on the
> > hard drive.    This is a good question, anybody know of a 
> better way?
> > C. PGP Wipe is a good tool with API support to delete files so a 
> > forensics tool can't recover the data.
> >
> > If you discard the data are there potential problems with 
> California 
> > SB
> > 1386 and being able to track intrusions and possible data 
> compromise?
> > I'm not a developer, but want a better solution than what the 
> > developers and client have proposed.
> >
> > Thanks in advance
> > Dave Andrews
> > PINT, Inc
> > 2105 Garnet Ave. Suite E
> > San Diego, CA 92109
> > TEL 858.270.2086
> > FAX 858.270.0410
>
>
>
> --
> TCV