EFS (Encrypting File System): security concern: aren't password-related hashes stored on the hard drive

The following youtube video does a pretty good job at summarizing how EFS works. For those interested in a summary of the contents of such windows I have attached it below. However this leaves me with one question concerning security:

When a user logs on in Windows, presumably a hash is computed from the password (or alternatively from the password plus the username and perhaps other data such as a salt). When a user first creates a password, such hash must be stored somewhere on the hard drive if I am not mistaken. At least, old Unix systems used to work in such manner (with such has stored in /etc/passwd). Thus when a user logs on, the password hash is computed and compared to what is stored in such file in order to authenticate the user. If the hashes match, the user is logged in.

So far so good. If the above mechanism is the one used (on modern Windows systems), this means that when someone hacks into a Window system, they can read such password hash, and thus, using the special Microsoft symmetric encryption algorithm (as described below) which is stored on the hard drive and thus can be learned by a hacker, the password hash plus the Microsoft special symmetric algorithm plus knowledge of where the encrypted private key is stored on the hard drive allows the hacker to decrypt it, thus obtaining the private key. And once the private key is obtained of course, then all data encrypted using the public key in the certificate can be decrypted by the hacker.

Can someone please point out the flaw in my reasoning? Presumably the flaw is due to a misunderstanding of mine concerning how Windows authentication is carried out.

Thanks.

http://www.youtube.com/watch?v=YxgWsa-slOU

Summary of the contents of the above video: - EFS (available in the NTFS file system) is designed to allow users to encrypt files and folders so that nobody except for the person encrypting such file or folder can access it. Administrative accounts on stolen machines can be created with minimal hacking knowledge, and can thus gain access to virtually any files contained on the hard drive. Symmetric key encryption algorithms work about 100 to 1000 times faster than public key encryption algorithms. right-click -> Properties -> General -> Advanced... -> Encrypt Contents to Secure Data and click on Apply, (you can then choose between encrypting just the file or encrypting the file and its parent folder and then click on OK). Windows will turn the file green and we will still have full access to the file. Once this someone logging in with an administrator account will not be able to see the file. You can in fact access the certificate manager with the "certmgr" command, and from there you can view the contents of the Personal -> Certificates application folder, which can start out as empty. When we encrypt a file in the above manner, a symmetric key called a DESX algorithm file encryption key (FEK) is generated and then the certificate's public key is used to encrypt the FEK and store it with the encrypted data. In the certificate contained in the certificate store you can get access to the public key but not the private key (the cerificate attests that user such and such are who they say they are and displays the user's public key). The certificate also points to the private key, but such private key is stored in a special location on the hard drive, and is encrypted using a special Microsoft symmetric key algorithm generated master key, where the master key is generated using a hash component from the username and password of the user every time the user logs on, and the resulting symmetric key is not stored anywhere on the hard drive (i.e. it must be kept somewhere in memory).

Solution

The hash value that is used to access the private key, which unlocks the symmetric key, is not the same as the hash value that is stored (used for authentication). Both hashes are derived from the password, but they are not computed the same way. Neither are reversible, and they cannot be used interchangeably.

To access your files, they need you to either be logged in already, or they need your password.

Also note that EFS normally designates the administrator or domain administrator as the "recovery agent". When the private key is stored, it also stores a copy that can be accessed by the administrator.

As shown in Figure 15.9, encryption with EFS requires the presence of at least two certificates in the certificate store on the local computer: one for the user (file owner) and one for a recovery agent account.

You can disable this feature by setting another of your accounts as the recovery agent, but in a domain, normally your domain administrator will set this policy and not allow you to disable it. So, the administrator can still access your files.

As long as an attacker doesn't gain the password for the recovery agent's account (or yours), your data should still be safe from an attacker, assuming the attacker isn't the same person as the recovery agent.

It's important to have strong passwords, keep them safe, and avoid running malicious software that could access the data directly.