Good to know - Our proposed implementation was on W2K, as XP wasn't out at the time. I do remember our on-site Microsoft guys were very enthusiastic about EFS on XP...
Yes, EFS in the standard configuration is useless for protecting hard drives when the attacker has physical access to the machine.
EFS is designed as an enterprise tool - when used with a Windows 2000 domain in which a recovery policy is defined, it will provide a reasonable level of security and utility.
By default, it is vulnerable, but for different reasons than you mentioned: by default, the authorized recovery agent (who is allowed to read any EFS-encrypted file)is set to "Administrator" on the local machine, an account with a known SID, easily compromised by any number of offline password reset tools, all of which require some level of physical access to the machine.
A domain recovery policy moves the authorized recovery agent to the domain level, preventing the use of this particular class of exploits. Microsoft claims that password reset on the individual user is ineffective, as the password hash is used in some unspecified way in the crypto process. Note that I have not tested this; My company's proposed EFS implementation was shelved due to technical issues between EFS and offline folders, so I never got that far.
Also a caveat in the default implementation - even if there were no vulnerability to password resets, the key resides on the same machine as the encrypted data, so there's another hole. In addition, as I remember it, the crypto used by default is not incredibly secure, and would not stand up under dedicated cryptanalysis, per the report our crypto guy prepared on EFS.
Slashdot Mirror
Our crypto guy was ex-NSA, and as such, tended towards assuming worst-case scenarios when it came to encryption. Zeltar
Good to know - Our proposed implementation was on W2K, as XP wasn't out at the time. I do remember our on-site Microsoft guys were very enthusiastic about EFS on XP...
Zeltar
Yes, EFS in the standard configuration is useless for protecting hard drives when the attacker has physical access to the machine.
EFS is designed as an enterprise tool - when used with a Windows 2000 domain in which a recovery policy is defined, it will provide a reasonable level of security and utility.
By default, it is vulnerable, but for different reasons than you mentioned: by default, the authorized recovery agent (who is allowed to read any EFS-encrypted file)is set to "Administrator" on the local machine, an account with a known SID, easily compromised by any number of offline password reset tools, all of which require some level of physical access to the machine.
A domain recovery policy moves the authorized recovery agent to the domain level, preventing the use of this particular class of exploits. Microsoft claims that password reset on the individual user is ineffective, as the password hash is used in some unspecified way in the crypto process. Note that I have not tested this; My company's proposed EFS implementation was shelved due to technical issues between EFS and offline folders, so I never got that far.
Also a caveat in the default implementation - even if there were no vulnerability to password resets, the key resides on the same machine as the encrypted data, so there's another hole. In addition, as I remember it, the crypto used by default is not incredibly secure, and would not stand up under dedicated cryptanalysis, per the report our crypto guy prepared on EFS.
Zeltar