> Recommended EFS procedures call for the encryption of a direcory, not
> file-by-file as the procedure indicated by Berglind suggests. If you copy
an
> unencrypted file and paste it into an encrypted directory, the file and
the
> temporary file are both encrypted.
>
> This is actually covered in the docs regarding EFS.
Ahem. Been seeing alot of this.
RTFM is actually not the correct response to a security hole--among other
things, "the docs" is insufficient information for me to determine which is
the canonical and mandatory docs I'm supposed to address as The One And True
Docs.
If you ask me, the user interface itself is the most important
documentation--it's the only thing that, if it's incorrect, is *guaranteed*
to lead to the wrong thing being done.
The user interface states that a file can be taken from an insecure state to
a secure state by checking "encrypt file". That's it. You get a warning,
and the warning states that unless the folder as a whole is encrypted, a
change in the file might lead to decrypted content being saved.
That's it.
I think my real problem with people running to the docs is that, quite
frankly, the *reason* for something to be recommended is *critical*.
According to the UI itself, the reason folder-crypto is superior is because
"modified files might be saved in cleartext." According to the "Step By
Step Guide To EFS" (http://www.microsoft.com/technet/win2000/efsguide.asp),
the reason it's recommended is "because many existing applications are not
aware of encryption and can therefore render the file in clear text."
Assume I've read both pieces of documentation--if I don't plan to modify the
file and if I'm using non-legacy applications, I should be safe. After all,
if the real recommended reason was "use of this feature will render the
encryption completely irrelevant to anyone with a sector editor", why, the
feature wouldn't even be in Windows, wouldn't it?
MS is failing to overwrite, even once, either the original file or the .tmp
file that EFS creates. That's a bug. It's not *nearly* as significant as
the possibility that MS was plaintext writing *everything*, and just
converting to encrypted form in the background(which is exactly what I
thought it was doing), but it's an issue and they're likely to address it.
Simply recommending a given pattern of behavior is irrelevant. Nobody
should be faulted, not even slightly, for passing over the recommendations
given that they were given without reasons that Rickard made clear.
Yours Truly,
Dan Kaminsky
Cisco Systems, Inc.
http://www.doxpara.com
