Enable File encryption tool in XP home?

Status
Not open for further replies.

Tedster

Posts: 5,746   +14
Is there a way to unlock the file encryption tool in XP home? Sadly my laptop has home on it, not professional.
 
NO-NO-NO and you really don't want it either!

XP/Pro has that feature, but it's deadly if you change your login password.
The sole solution is a Recovery Agent -- google EFS Recovery Agent.

to protect a folder or a set of files, see the REVIEWs forum for review
 
thanks. Actually I just have XP home on the laptop. I've tried a couple of encryptions programs here at techspot. 1 even had a trojan in it which spybot resident stopped. Mostly they were too complicated to use and wanted drives to be created etc... too dangerous for my data. (Good thing I had goback!)

I just need something easy to use.
 
TrueCrypt is the best for absolute security, but if you just want a normal, secure enough (128 bit Blowfish) and pleasing on the eye application you might try HandyBits EasyCrypto with which you can encrypt files AND/OR folders and also send them in self-extracting encrypted files via email.

Both are free by the way. :wave:
 
True about EFS is that XP Home release unfortunately hasn't it enabled. I can say unfortunately, because EFS is very easy and comfortable to use and also very safe for data. You must have XP Professional then you can enable encryption.
There are several ways to implement EFS in organization (e.g. in corporation IT infrastructure) and several ways to secure against problems with encrypted files in future.
Using EFS we, as users, are interested in this, that our data will be unaccessible by intruders and that we could always decrypt our data. There is no problem when our Windows XP system works. But when we have problems and e.g. retrieve data from damaged laptop or we reinstalled system we are not able to get to our encrypted data until ... we have certificate with our private key.
I should also mention that data encrypted with EFS are very safe. XP uses AES and different FEK keys for every file. FEK is added to file and encrypted with user's public key from certificate.
There are several ways to handle recovery encrypted files ... there was mentioned EFS Recovery Agent ... such second user who's certificate is used together with user's certificate to generate FEK keys used to encrypt files ... but base way to secure ourselves against problems with EFS in future is to export certificate with private key.
I suggest to export it on some small, older pendrive (we don't need capacity) or on CD and keep it in secure place (recommended two copy). If it be enough secure place we can export it without password otherwise we should choose to secure certificate with password.
Start>Run>mmc>File>Add/remove snapin>Add>Certificates>add>My user account>OK,Close,OK
Then we go to snapin Certificate, choose Personal, riht click on certificate and choose „All tasks”>”Export” , we have to remember to add private key etc. like wizard says.
Thats all we need.
In the future, e.g. after system reinstalling we can import this certificate and then we get access to encrypted files. Thats all what need to know single laptop user.

Administrator have to learn more about EFS if want to use it on servers.
There is many other aspects of EFS. We can use it on servers in domain infrastructure (using also PKI) then we can add access and decryption ability to several users. EFS is based on certificates so it is very powerful and elastic technology. Many users can have access to single file or folder (not only one user with one password). Some users can only decrypt and read files others can decrypt and change or remove or create files etc.
Recovery agents , if we use them, can decrypt every files on computer or on all computers in domain. It depends on implementation in our IT infrastructure.

I hope it can explain a little how we can put EFS to work for us. :)
I'm using EFS on laptop and TrueCrypt on external HDD :) and I'm afraid that EFS is more comfortable and very secure if we know a little bit how it works.

On the end I have to mention, that when you use EFS you can't forget your user's password. If you do it you will need recovery agent (if you enabled it before) or you will have to boot from other Windows XP/2003 or reinstall system and import your backuped certificate if you prefer ;). But the same requirement is in TrueCrypt (you have to remember additional password for TrueCrypt files or partitions or you lose data).
Thanks to Peter Nordahla we unfortunately have another problem ... a tool to edit local passwords in Windows' SAM base. So if we want to have our local user's passwords secure we always (with EFS and without it) have to use system option to store password granting access to SAM not on computer but in our mind. I mean SysKey.
Start>Run>Syskey >Update>enable start with password>type password twice
Every start of system will need this password.

Sincerely
Pawel Stepien (PL)
 
Can you report password usage on EFS?

  1. Is access immediately granted once the user has gained User/Password login OR
  2. is the EFS Pass Phrase required? Per directory or once for all?
I much prefer OEM encryption as the pass phrase is required to open each protected file/folder,
which protects my laptop data if it were stolen or lost :)
 
EFS is integrated with system ... although to encryption is used , as we can say in short, user's public key... user is verified at the logon process , so user's password is the only password we need to encrypt and decrypt files. Whole process encryption and decryption is transparent for user. Easy and efficient.
User must care about his password, it's complexity, keep it safe and change regularly.
Additionally he have to care also about certificate (especially private key) if he makes backup of it and about access to SAM. I mentioned before about tool named Syskey to enable external password to SAM.
EFS + Syskey (SAM) password makes from Windows XP quite strong fortress and very comfortable to live in. ;)
 
EFS + Syskey (SAM) password makes from Windows XP quite strong fortress and very comfortable to live in. ;)
Not even :(
Unless the GPO policy to set LMHOST password is not stored OR the PW > 14 characters,
there are tools to crack LMHOST passwords and thus once login is achieved, the encryption is useless.

If one is serious about protecting specific files, EFS is not the tool of choice.
 
Term "LMHOST password" is not too good. I think you are writing about LM protocol created in DOS age and so called "NoLMHash Policy" in GPO.
Microsoft used several weak authentication protocols till now. We can mention LM and NTLM which mostly concern to our topic.
There is the youngest child of Lan Manager line - NTLMv2 and we can say that is quite OK.

Lan Manager in version LM and NTLM it is old technology. I do not see any reason in corporate networks to use it today. Even if you have older systems than Windows 2000 (e.g. NT, 98 etc.) you should do all you can to use NTLMv2 for them too.
Currently Kerberos is preferred and default authentication protocol in networks based on MS domain since Windows 2000 Server was released.
Even if you have older systems in the network (e.g. DOS, Win 98 without AD client) only they will use LN/NTLM as authentication protocol.
If you DO NOT use domain infrastructure NTLMv2/NTLM/LM is used to authenticate network users in mentioned order. It can happens in workgroups and during sharing files and folders in network without workgroup (\\ip\share folder).
At that scenario I prefer to use sftp service to share files on server or laptop than engage NTLM\NTLMv2 to authenticate users, but it is not fault and not risk to use protocol NTLMv2.
Summarising this part - Microsoft networks uses such authentication protocol in authenticating network users:
- First Kerberos (if domain infrastructure works).
- Second NTLMv2 if Kerberos is not accessible and clients accept NTLMv2.
- Third NTLM if clients not support NTLMv2.
- On the end LM (only DOS based systems, includes Windows 3.1x).

Shortly about NTLMv2:
- Difficult to break, we can say "enough secure for typical, normal use"
- uses MD5 to encrypt/hash passwords send via network (MD5 is enough secure till now)
- to use it on old systems one have to upgrade Windows NT to minimum SP4, for Windows 98/Me must be installed extension: Active Directory Client.
- locally are not stored network passwords in clear-text or weak hash but only hash encrypted with MD5 algorithm.

Practically problem with insecure LM/NTLM protocol not exists in present networks based on MS Windows systems younger than NT or upgraded to support NTLMv2.
Of course professionally we use Kerberos.

For very secure tasks and big organisations Microsoft offers combination of domain infrastructure with Kerberos authentication, integrated PKI technology, integrated EFS and IPSec. For VPN users and wider for network security L2TP, IAS (RADIUS), NPS, ... ISA Server as advanced firewall ... we can mention also System Centre (SC Configuration Manager, Data Protection Manager, Operations Manager) and Forefront (server, client and edge security).

When LM was created Microsoft was "a crawling baby" in network technology. But it is not true today. I only don't understand why new MS Windows systems haven't implemented SSH and sftp technology. FTP and telnet should be forgotten for ever :).
 
oops; You are quite correct LMHOST is bogus.

Very Nice Post :)

The GPO Policy is to not to store the LMHASH.

Yes NTLMv2 is preferable, BUT it is not compatible with Samba based systems
(eg Macintosh, Unix, Linux, and even Win/98) unless you can get those system owners to upgrade to
NTLMv2 -- which is not always possible. If you have a hetrogeneous network,
you need to keep NTLMv1 and control how Windows manages passwords.
 
Heterogeneous network based on Active Directory and Samba should use Kerberos as authentication protocol. Since Samba 3 was released it is even simple.
LM & NTLM has nothing to do in professionally managed network based on AD with domain controller Windows Server 2000/2003/2008 even if workstations works under Linux and Mac control.
Example of use:
www#interopsystems.com/LearningCenter/Using_Samba_and_Kerberos#htm (replace # with .)

We should remember that Kerberos isn’t Microsoft’s product. It was only implemented in servers. This protocol is widely used in Linux networks and applications.

By the way ... if administrator has no influence on this how workstations work and what they have installed that it is not professionally managed network and such network cannot be secure.
There are even tools like "Network Access Policy", WSUS and System Centre to simplify workstations management. E.g. admin can make policies to check if workstation meet requirements to connect with local network and to give client such network access level like is adequate to it's so called "computer/system health". There is of course much more to say about centralized workstation management.

My conclusion is that:
1. EFS is very useful, easy to use and enough secure to normal use.
2. Problem with NTLM not exists in networks correctly configured and managed.
3. “Old”, not upgraded network infrastructures, network managed incorrectly or by administrators that have incomplete knowledge will be in one or another way insecure.
 
LM & NTLM has nothing to do in professionally managed network based on AD with domain controller Windows Server 2000/2003/2008 even if workstations works under Linux and Mac control.

We should remember that Kerberos isn’t Microsoft’s product. It was only implemented in servers. This protocol is widely used in Linux networks and applications.

By the way ... if administrator has no influence on this how workstations work and what they have installed that it is not professionally managed network and such network cannot be secure....There is of course much more to say about centralized workstation management.

My conclusion is that:
1. EFS is very useful, easy to use and enough secure to normal use.
2. Problem with NTLM not exists in networks correctly configured and managed.
3. “Old”, not upgraded network infrastructures, network managed incorrectly or by administrators that have incomplete knowledge will be in one or another way insecure.
All very true for a commercial I.T. department, but the majority of this community is home user and
thus the skills and tools to manage A system (let alone one or more subnets of systems) can be daunting.
We need solutions for the least common denominator and it's not
what the typical naive user cares to learn -- after all, most people use PCs for a job skill, not to learn systems/network administration.

Best wishes
 
EFS was explained in this discussion enough good that every user could decide if it is solution for him or not and how to prepare system to provide access to encrypted data independently on potential troubles with system.
 
In jobeard's post https://www.techspot.com/vb/topic71107.html is repeated false information that in some situations only recovery agent can recover access to encrypted data. If one made copy of his user’s certificate with private key and keep it in safe place without additional password protection (I mean additional password to forget), he can always use it to decrypt data and do not need recovery agent. I do not say that recovery agent isn’t useful but one do not have to configure it if doesn’t want.
I see that there are a lot of articles, even on Microsoft Web sites, describing recovery agent as the only solution to recovery encrypted data but it is not true.

If we write about small networks and small community I'd like to notice that small Windows' LANs can be divided into two types:
- networks with centralised users management based on Active Directory and Microsoft Domain (e.g. Small Business Server as a Domain Controller),
- networks based on workgroups technology or just based only on IP communication.

First type need administrator. Administrator manages such network and decides about its components. Basic and default network configuration cancel out using in such LANs any of NTLM for hosts since Windows 2000 and older than NTLMv2 for older Windows hosts beyond Win 3.11.
For Linux and Mac hosts recommended Samba configuration also cancels out using NTLM as Kerberos is much better technology.
This type of network need administrator and admin would have to make some effort to make such network less secure than standard configuration by using NTLM.
So EFS users are secure in such network if admin is in right mind.
Small networks do not need tools to manage workstations because administrator has personally contact to each user.

Second type it is Workgroup network or network based only on IP communication. In such networks users do not use centralised credentials. Every access to local resource requires use of local user account on this host which serve given share. So there caching passwords do not exists at all. Every user need to know many local user/passwords combination to access to different resources shared by different hosts.


There are two attiudes to security one can meet in small networks.
First says that network is endangered only from outside and inside everything is common. Security aspects are limited to isolating from outside. People often know each other passwords. In such networks NTLM can be used and EFS is used to secure data in case of loosing notebook or disk.
Second is traditional and says that everyone secures his own data. NTLM can't be used.

I think that even in 2005 danger of using EFS was very limited, limited to networks which were dangerous in many other aspects.

EFS is not secure in centralised networks which need administration but are not correctly managed. But, as I wrote, such networks are dangerous in many other aspects too. Not updated systems are easy targets for viruses and exploits so such network should be treated as dangerous as internet. Every user should isolate his computer from such network as much as he can, using the same tools like against internet intruders. I mean firewall, antivirus, not sharing files and folders and using sftp and even ftp instead of sharing folders, installing system security updates, even using local user account for local computer and domain account only for resources on servers, not adding computer to domain.

We have to remember that security of our data is so strong as the weakest part of our defence.
If one uses strong cryptographic tools and do not care about e.g. system security updates his effort has no sense because one day some exploit will install him backdoor and script kiddie will get all info about his keyboard activity and then his passwords and in the end all his secret data will get to kiddie's hands.
The same is true in situation that one uses TrueCrypt to encrypt data but authenticates on servers via NTLM or using clear text. Attacker do not need deep knowledge to catch his password and take control over his computer to monitor keyboard and in next step get TrueCrypt password and access encrypted data.


I apologise Tedster for this long discussion not exactly answering his question.
It would be interesting to answer the question how to force XP Home to support EFS.
 
In jobeard's post https://www.techspot.com/vb/topic71107.html is repeated false information that in some situations only recovery agent can recover access to encrypted data. If one made copy of his user’s certificate with private key and keep it in safe place without additional password protection (I mean additional password to forget), he can always use it to decrypt data and do not need recovery agent. I do not say that recovery agent isn’t useful but one do not have to configure it if doesn’t want.
I see that there are a lot of articles, even on Microsoft Web sites, describing recovery agent as the only solution to recovery encrypted data but it is not true.
Then argue with MS :)
 
Status
Not open for further replies.
Back