Re: efs and "encryption" overall... help?

From: Steven L Umbach (n9rou_at_nospam-comcast.net)
Date: 10/15/04


Date: Thu, 14 Oct 2004 21:34:26 -0500

What I referred to was that the only way to make totally sure that the EFS
encrypted files are safe is to export/delete the certificate and private key
to a .pfx file. Then to access the files again the user would have to import
the certificate/private key back into their computer which can be done by
accessing the .pfx file which will start the wizard to import them and
require the user to enter the password used to protect the private key. The
.pfx file could be stored on a floppy or possibly USB drive which of course
should be separate from the computer.

Realistically, many users will not be religious about deleting and importing
their EFS private key all the time as it is somewhat inconvenient. Disabling
the storage of lm hash and using complex passwords or passphrases would
still go a long way to protecting the private key. --- Steve

<jjd228@NOSPAMoptonline.net> wrote in message
news:56Dbd.8699$Fe6.2916361@news4.srv.hcvlny.cv.net...
> thank you both! few issues: i encrypted a file, then exported and deleted
> the cert. logged off and then back on and could not access the file. this
> is because the cert is gone i assume. but Steve said to be absolutely sure
> a person should export and delete the cert. im confused. could you comment
> on this please?
>
>
> "Steven L Umbach" <n9rou@nospam-comcast.net> wrote in message
> news:Okqd%23QisEHA.2800@tk2msftngp13.phx.gbl...
>> Just to add to Mike's advice that in addition to using strong passwords
>> that require password complexity and at least eight characters be sure to
>> disable storing of lm hash on the computer. It is easy to reset the built
>> in administrators password on any computer that a hacker has full
>> physical access to. If that happens the attacker could use something like
>> LC5 to crack the users password to access their EFS private key. Lm
>> hashes are extremely easy to crack.
>>
>> http://support.microsoft.com/default.aspx?scid=KB;EN-US;q299656& -- how
>> to disable lm hash. Note that password must be changed to erase existing
>> lm hash.
>>
>> To be absolutely sure that an attacker can not access EFS encrypted files
>> the user must export and delete their EFS certificate and private key to
>> a .pfx file. If Windows 2000 requires the use of a Recovery Agent while
>> Windows XP Pro does not. A Recovery Agent private key left on the
>> computer could also be used to decrypt a users EFS files. XP Pro also
>> uses much stronger encryption to encrypt EFS files, not that it would be
>> easy to crack Windows EFS files without a LOT of horsepower and a very
>> long time. Long enough to probably make the data long obsolete. Keep in
>> mind that with XP Pro that more then one user may be able to decrypt the
>> file if the original user added other users to the list and their private
>> keys exist on the computer. Efsinfo can list what users and Recovery
>> Agents can decrypt a specific file. --- Steve
>>
>>
>> <jjd228@NOSPAMoptonline.net> wrote in message
>> news:bLvbd.6321$Fe6.1690871@news4.srv.hcvlny.cv.net...
>>> what can a person do if they want to encrypt the contents of their
>>> harddrive so that even if someone physically removed the drive, nothing
>>> would be readable?
>>>
>>> heres how i understand the EFS as it works with ms windows....
>>> i can encrypt a file, folder, or even a whole drive. at the time of the
>>> first encryption a certificate is created that is used to decrypt those
>>> file. if you remove the certificate, then log off and back on, you will
>>> not have access to the previously encrypted files, all good so far? but
>>> what good is this if the certificate is stored on the same drive? im
>>> sure it could be obtained and used to decrypt files if the drive was
>>> removed. obviously even the strongest password on your user account does
>>> nothing to help if you dont use encryption because again, physically
>>> removing the drive and connecting it to another machine will get around
>>> the logon password. so my question, again, is: how can a person encrypt
>>> the contents of a harddrive in such a way so that the ONLY way to access
>>> the files on it would be to successfully logon as the user who
>>> originally encrypted the files? in this way a strong password would make
>>> it mathematically unlikely that your files would be read by anyone.
>>> thanks in advance
>>>
>>>
>>
>>
>
>



Relevant Pages

  • Re: securing folder on external disk(s)
    ... > where the encryption comes in I think). ... > If, as you advices, I'd use the EFS. ... The key is a self-signed certificate that is generated the first time ... them _as long as the private key is unknown_. ...
    (microsoft.public.security)
  • RE: Relative Security Provided by Cached Domain Credentials?
    ... certificates assigned to them, with each certificate having a set number ... smart card management tools which provide private key archival for smart ... AND the cert is also valid for EFS, they likely would be able to do ... What you probably could get to work for local file encryption, ...
    (Focus-Microsoft)
  • Re: Corrupted Admin Profile
    ... > My view on EFS: ... > Do not to use encryption unless you are in a domain and you know ... as well not having created a Recovery Agent (with backup of the ... > Q241201 How to Back Up Your Encrypting File System Private Key ...
    (microsoft.public.windowsxp.security_admin)
  • Re: EFS Private Keys
    ... It's possible to have a cluster that was in use that couldn't be wiped. ... > syskey was to EFS in W2K, ... >>> the private keys are protected however the key to the private key is ... >>> stronger encryption available for EFSfiles permanently if you don't. ...
    (microsoft.public.win2000.security)
  • Re: Corrupted Admin Profile
    ... > My view on EFS: ... > Do not to use encryption unless you are in a domain and you know ... as well not having created a Recovery Agent (with backup of the ... > Q241201 How to Back Up Your Encrypting File System Private Key ...
    (microsoft.public.windowsxp.security_admin)