Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

How secure is the data in a encrypted NTFS folder on Windows (XP, 7)?

(The encryption option under file|folder -> properties -> advanced -> encrypt.)

If the user uses a decent password, can this data be decrypted (easily?) if it, say, resides on a laptop and that is stolen?

share|improve this question
    
The Elcomsoft "Advanced EFS Data Recovery" whitepaper says > First the program tries to do this automatically, for example trying to extract the password from cache or system files, checking simple combinations (such as password=username) and then conducts an attack using a medium-sized built-in dictionary. What's the probability that Elcomsoft can find a cached password on Windows 7? –  chris Jun 7 '12 at 14:16
    
Some vulnerabilities of EFS depending on the OS and the configuration are documented here: en.wikipedia.org/wiki/Encrypting_File_System#Vulnerabilities –  rgbflawed Nov 13 at 20:16

6 Answers 6

up vote 18 down vote accepted

How secure is the data in a encrypted NTFS folder on Windows (XP, 7)?

What is EFS?

Folders on NTFS are encrypted with a specalized subset of NTFS called Encrypting File System(EFS). EFS is a file level encryption within NTFS. The folder is actually a specalized type of file which applies the same key to all files within the folder. NTFS on disk format 3.1 was released with Windows XP. Windows 7 uses NTFS on disk format. However the NTFS driver has gone from 5.1 on windows XP to 6.1 on Windows 7. The bits on the disk have not changed but the protocol for processing the bits to and from the disk as added features in Windows 7.

What algorithm does it use?

Windows XP (no service pack): DES-X (default), Triple DES (available)

Windows XP SP1 - Windows Server 2008: AES-256 symmetric (default), DES-X (available), Triple DES (available)

Windows 7, Windows Server 2008 R2: "mixed-mode" operation of ECC and RSA algorithm

What key size does it used?

Windows XP and Windows 2003: 1024-bits

Windows Server 2003: 1024-bits (default), 2048-bits, 4096-bits, 8192-bits, 16384-bits

Windows Server 2008: 2048-bit (default), 1024-bits, 4096-bits, 8192-bits, 16384-bits

Windows 7, Windows Server 2008 R2 for ECC: 256-bit (default), 384-bit, 512-bit

Windows 7, Windows Server 2008 R2 for for AES, DES-X, Tripple DES: RSA 1024-bits (default), 2048-bits, 4096-bits, 8192-bits, 16384-bit;

How is the encryption key protected?

The File Encryption Key (FEC) is encrypted with the user's RSA public key and attached to the encrypted file.

How is the user's RSA private key protected?

The user's RSA private key is encrypted using a hash of the user's NTLM password hash plus the user name.

How is the user's password protected?

The user's password is hashed and stored in the SAM file.

So, If an attacker can get a copy of the SAM file they may be able to discover the user's password with a rainbow table attack.

Given the username and password, an attacker can decrypt the RSA private key. With the RSA private key, the attacker can descrypt any FEC stored with any encrypted file and decrypt the file.

So...

The contents of the encrypted folder are as secure as the user's password.

If the user uses a decent password, can this data be decrypted (easily?) if it, say, resides on a laptop and that is stolen?

Probably not by an adversary with a typical personal computer. However, given sufficient resources, like a GPU or FPGA password cracking system, EFS data may be vulnerable within a short period.

A random 12-character (upper lower and symbol) password may hold old for weeks or months against a password cracking system. See "Power of Graphics Processing Units May Threaten Password Security" A significantly longer password may hold out for years or decades.

share|improve this answer
    
Excellent answer. Passwords AFAIK are hashed with a salt in the SAM file, which the salt should limit the ability to use a rainbow table attack. However a brute force is still feasible if the password is weak(perhaps that's what you meant). See: security.stackexchange.com/questions/8341/… –  AaronLS Feb 10 at 20:09

It uses AES-256 in XP, and ECC in Windows 7 But if someone gets a hold of your machine and can crack your password, they can access your files. So better than nothing, but only just barely.

share|improve this answer
    
"So better than nothing, but only just barely." ... the other two answers seem to imply that for a good password, it would be pretty secure? –  Martin Oct 24 '11 at 6:42
    
Yes, that's correct :) –  devnul3 Oct 26 '11 at 0:59

It is exactly as secure as the weakest password for any account that can access the file. If that password is "7XhqL3w0,DBC1y" it's practically invulnerable. If it's "il0veu", it might as well not be encrypted at all.

share|improve this answer
2  
14 characters out of the set [A-Z a-z 0-9 ,] (63 possible characters) gives log2(63^14) ≈ 83.7 bits of entropy, given no other information about the makeup of the password. Fairly good, but not stellar, and a long way from a proper implementation of AES-256. To match AES-256 with the entropy of a completely random password, you'd need around 43 characters selected from the 63-character set (log2(63^43) ≈ 257.0 (bits)). –  Michael Kjörling Nov 8 '11 at 13:49

short answer ...

Yes, EFS is secure if (and only if) password of given user account is non-trivial.

however ...

There are better solutions, such as FDE w/ a smartcard+PIN or TPM (plus PIN and/or token). Far too often, encryption is rendered useless b/c of poorly chosen passwords, so the above rectify that. Further, FDE solves the issue of remnants of files being discovered in temp folder, paging or hibernation file, etc.

EDIT: In response to user comment ...

FDE = full disk encryption, wherein the entire disk or significant portion (i.e., disk excluding certain boot components) is encrypted via hardware- or software-based implementation

TPM = trusted platform module, referring to a hardended, tamper-resistant chip used to store cryptographic information

share|improve this answer
    
Could you please provide links for the FDE and TPM acronyms? Thanks. –  Martin Nov 7 '11 at 7:39

The password is the weakest part of the system. You would have to have a very long (more than 14 characters) and very random password to prevent it from being hacked.

The other parts are secure. The private key and encryption key are both un-crackable with today's technology.

There are still ways around this. For example, somebody might install a USB keylogger between your keyboard and machine, and steal your password that way.

share|improve this answer
    
Robert - very long I understand (if it's got more than 14 chars there's guaranteed no LM hash, so brute forcing the pwd would be necessary). Very random - what do you mean by this? I obviously won't take any single word from a dictionary, but I wonder how much randomization is really necessary !Its my DOG SAM has 15 characters and I wonder how "insecure" it really is ... –  Martin Nov 7 '11 at 7:36

Keep in mind the key to measuring security is not just entropy of the password, but the weakest link in the chain. In this case, physical security of the computer plays a part in addition to if the machine is on a windows domain.

It is fairly trivial to reset any windows password using Trinity provided that you can mount a DVD in the drive and reboot the machine. The next weakest link is other administrators on a windows domain network that can simply reset your password and gain access to the files.

share|improve this answer
    
Hi Michael. Your answer does not seem to fit with the others. Admins can reset my password, but that renders the encrypted data unusable(?) The other answers describe the decryption key being dependent on knowing the actual password. Resetting it shouldnt matter(?) –  Martin Nov 13 at 19:55

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.