S
Shark
I'm testing XP Pro's EFS before I adopt it and ran into some
questions.
There is an interesting Wikipedia article on EFS, particularly this
passage:
"Windows can store plaintext versions of user account passphrases,
though this is no longer default behaviour; it also can and will
store, by default, the local user account passphrases in LM hash,
which can be attacked and broken relatively easily. It also stores
local user account passphrases as NTLM hashes, which can be fairly
easily attacked using "rainbow tables". To mitigate the threat of
trivial brute-force attacks on local passphrases, Windows needs to be
configured (using the Security Settings portion of Group Policy) to
never store LM hashes, and of course, to turn off Autologon (which
stores plaintext passphrases in the registry). Further, using local
user account passphrases over 14 characters long prevents Windows from
storing an LM hash in the SAM - and has the added benefit of making
brute-force attacks against the NTLM hash harder. Of course, if you
consider the fact that EFS uses Triple DES or AES to encrypt files,
you should use proper passphrase lengths (over 20 characters long) to
achieve equivalent strength against brute-force attacks."
But I didn't fully understand the part about 14 character-long
passphrases. Is this additional to configuring Group Policy (as
described) or by simpling choosing a 14 character password it will
automatically force XP to NOT cache in LM hash?
Another question is this, assuming the private key-certificate will be
exported to media outside the computer and deleted for additional
security, is it absolutely necessary for that account to have a logon
password for the encryption of the content to be secured? I'm assuming
the logon password is not used for the encryption process but rather
the private key only.
And finally I can't find the import option to import a key I
previously exported. It should be located in the certificate snap-in
for the local user but all I see are renewal options of the
certificate and Export (even though there is no key currently since it
was deleted upon successful export).
questions.
There is an interesting Wikipedia article on EFS, particularly this
passage:
"Windows can store plaintext versions of user account passphrases,
though this is no longer default behaviour; it also can and will
store, by default, the local user account passphrases in LM hash,
which can be attacked and broken relatively easily. It also stores
local user account passphrases as NTLM hashes, which can be fairly
easily attacked using "rainbow tables". To mitigate the threat of
trivial brute-force attacks on local passphrases, Windows needs to be
configured (using the Security Settings portion of Group Policy) to
never store LM hashes, and of course, to turn off Autologon (which
stores plaintext passphrases in the registry). Further, using local
user account passphrases over 14 characters long prevents Windows from
storing an LM hash in the SAM - and has the added benefit of making
brute-force attacks against the NTLM hash harder. Of course, if you
consider the fact that EFS uses Triple DES or AES to encrypt files,
you should use proper passphrase lengths (over 20 characters long) to
achieve equivalent strength against brute-force attacks."
But I didn't fully understand the part about 14 character-long
passphrases. Is this additional to configuring Group Policy (as
described) or by simpling choosing a 14 character password it will
automatically force XP to NOT cache in LM hash?
Another question is this, assuming the private key-certificate will be
exported to media outside the computer and deleted for additional
security, is it absolutely necessary for that account to have a logon
password for the encryption of the content to be secured? I'm assuming
the logon password is not used for the encryption process but rather
the private key only.
And finally I can't find the import option to import a key I
previously exported. It should be located in the certificate snap-in
for the local user but all I see are renewal options of the
certificate and Export (even though there is no key currently since it
was deleted upon successful export).
