what is the practical purpose of encryption in winXP?

[Special K]

I read the FAQ and the windows help file, but I don't quite understand when encryption should be used. If you don't want a user to access your data, you can just deny them permission to a particular folder. How does that differ from encryption (in practical terms)? When would someone want to use one instead of the other?

 

[Abzstrak]

lets say someone steals yours computer, maybe your laptop. If they dont know your password its hard to login and get anything, especially if U have a bios password.... However all they need to do is pop the harddrive out and read it in another system... but if its encrypted thats not possible

 

[Special K]

What is the encryption generated from? The computer's hardware configuration? If I were to upgrade some major hardware component (MB, for example), would I lose access to any encrypted data on my HD?

 

[bsobel]

The key isn't hardware specific, it's part of your user account.
Bill

 

[CTho9305]

Originally posted by: bsobel
The key isn't hardware specific, it's part of your user account.
Bill

how secure is it? can administrator read it?

 

[Derango]

No, an admin cannot read files that you have encrypted, at least with his own account. He'd need access to your account to read them.

 

[Woodie]

No, an admin cannot read files that you have encrypted, at least with his own account. He'd need access to your account to read them

Not exactly...
If you leave the default EFS recovery policy in place, (where LOCAL\Administrator is the Recovery Agent) and
If the Administrator account is from the same install as your account, then "Yes", the Admin can read your encrypted files. Note: If the HD is loaded in a second machine, then part 2 is FALSE.
Alternatively, if it's a Local Admin, he can reset your password, login as you, and then he's "in like Flint".

Read the FAQ on this.
Based on my research for enterprise implementation:
1. Do export your EFS certificate (with private key) to a secure file area (CD, floppy, server), and document the password!
2. Change the EFS Recovery Policy to point to a non-local ID, or at least export and delete the recovery key from each individual workstation.
3. Do export your EFS certificate (with private key) to a secure file area (CD, floppy, server), and document the password!
4. Do NOT use EFS on temp directories, \Docs & Settings\USERID, \autoexec, and \winnt.
5. Did I mention? Do export your EFS certificate (with private key) to a secure file area (CD, floppy, server), and document the password!
6. EFS Recovery policy is only evaluated at workstation boot time. EFS Recovery policy is a machine attribute, not a user attribute.

There are many pitfalls in implementing EFS, and even more in the Microsoft PKI. Read the FAQ/docs. If you have AD-Domain questions, PM me.

 

[Mrburns2007]

There's plenty of freeware encryption tools on the download.com and there bit more robust.