RE: Protecting sensitive files on a Windows file server

["Roger A. Grimes" <roger () banneretcs com>]

-See replies below. 

Roger

*****************************************************************
*Roger A. Grimes, InfoWorld, Security Columnist 
*CPA, CISSP, MCSE: Security (2000/2003/MVP), CEH, yada...yada...
*email: roger_grimes () infoworld com or roger () banneretcs com
*Author of Professional Windows Desktop and Server Hardening (Wrox)
*http://www.amazon.com/gp/product/0764599909
*****************************************************************



-----Original Message-----
From: paul.johnson8 () gmail com [mailto:paul.johnson8 () gmail com] 
Sent: Tuesday, June 20, 2006 7:54 PM
To: Roger A. Grimes; security basics
Subject: Re: Protecting sensitive files on a Windows file server

We discovered with Office 2003, using the default Office 97/2000
compatible encryption type to protect the files, it is possible to
recover the passwords/data using software such as Elcomsoft Password
recovery (which can also break EFS) and online password/data recovery
services no matter how long the password or complexity in under 5 mins.

-It's worse than that. Office passwords can always be removed (set to
blank) because the password is stored in a known and editable location.

-Elcomsoft does not "crack" EFS private keys. It breaks the
Administrator account password (or uses the logon Administrator
credentials) to programmatically gain access to the otherwise protected
EFS private key. If the intruder breaks your Admin password or is able
to get logged on as Administrator, it's always game over...and cracking
EFS keys is only one your problems.

How are others protecting this information in their place of work?

-Most aren't. Just read the papers. Of those that are, most are using
EFS (again most users aren't), PGP, RSA, or some other commercial
solutions. There are dozens of commercial encryption solutions, and
kudos to you for looking into this.


On 21/06/06, Roger A. Grimes <roger () banneretcs com> wrote:
> There are many great commercial solutions, like PGP Desktop, but EFS 
> is free and works well if you handle key archival seriously.
>
> EFS works well, but it is not as eloquent as many of the other 
> solutions (don't forget TrueCrypt for a free solution). For example, 
> EFS only encrypts data while its stored on the hard drive, but the 
> data is decrypted (using EFS alone) when copied across the network or 
> down to other media. PGP Desktop, with NetShare, allows the files and 
> keys to be managed easier and to remain encrypted where ever they
ended up (i.e.
> USB key, CD-ROM, etc.); and with a single encryption key.
>
> Office 2003 encryption isn't good encryption; easy to bypass.
> Winzip leaves unencrypted recoverable temp files.
>
> Just my one-half cent. I haven't tried the RSA solution.
>
> Roger
>
> *****************************************************************
> *Roger A. Grimes, InfoWorld, Security Columnist *CPA, CISSP, MCSE: 
> Security (2000/2003/MVP), CEH, yada...yada...
> *email: roger_grimes () infoworld com or roger () banneretcs com *Author of 
> Professional Windows Desktop and Server Hardening (Wrox)
> *http://www.amazon.com/gp/product/0764599909
> *****************************************************************
>
>
>
> -----Original Message-----
> From: paul.johnson8 () gmail com [mailto:paul.johnson8 () gmail com]
> Sent: Monday, June 19, 2006 7:39 PM
> To: security basics
> Subject: Protecting sensitive files on a Windows file server
>
> We are looking for a secure way to store very sensitive files on our 
> Windows servers.  The data is shared. We will turn on full auditing, 
> create hidden shares and a security group.
>
> Which type of protection would be most suitable:
>
> Office 2003 encryption
> Windows EFS
> Winzip 9.x encrypted archives
> RSA SecurID Windows Agent (2 factor authentication) PGP Desktop Pro
>
> Our concern with the Windows/Office encryption types is that it could 
> be cracked - ie. someone could get hold of the file and run some kind 
> of password recovery on the file and access the data.
>
> Any ideas on how to approach this would be much appreciated.