Encrypting local data

[Techknowledge]

I hear people say encrypt your local data at home. Why should I, if I physically not allow anyone to my computer, and let's say hypotethically, I am also not connected on net, do I need to encrypt data at home. Secondly, how can I encrypt data and what software is available to do so and what instances or reason am I required to encrypt data from in my HD.

 

[PrincessFrosty]

These days it's really a good idea to approach this from the opposite side and ask, "what are the reasons I shouldn't encrypt", you wont find many.

Even if you weren't connected to the net and you don't allow physical access to your computer you have 2 important problems.

1) Humans bridge the gap between networks without connectivity - that is to say, eveb a system NOT physically connected to the internet is vulnerable because of the human factor, some viruses were designed to bridge such gaps, this isn't not unheard of.

2) Local security isn't perfect, in fact physical security is among some of the worst we have, most locks are beatable, most electronics are hackable or can be disabled, getting physical things secure is actually really hard, so data theft via physical media theft is also very real.

Now a days we have CPUs with hardware accelerated AES encryption which means you can encrypt all your partitions and with a modern CPU the processing overhead for encrypting/decrypting on the fly is nominal and so doesn't impact read/write speeds.

If you're looking at data encryption then TrueCrypt is considered one of the best open source tools for this, I encrypt all my data with it.

 

[Techknowledge]

Thanks for the explanation. How are comparing TrueCrypt to Bitlocker of Windows. Which is better and why?

 

[PrincessFrosty]

TrueCrypt is arguably better, more features and open source which is important for a number of reasons, multi-platform and free.

TrueCrypt also has some features such as deniable encryption which you might rely on should you suspect you might be compelled by law enforcement or other "bad guys" to divulge your encryption keys.

 

[Savatar]

I see BitLocker as only useful when you want to encrypt the entire drive... I don't think it supports encrypting individual files or creating encrypted containers. Don't confuse BitLocker with the Encrypting File System (EFS), which can encrypt specific files and folders. See here for some clarification between the two: http://windows.microsoft.com/en-us/...r-drive-encryption-and-encrypting-file-system

Even then, as PrincessFrosty pointed out, BitLocker offers more features like hidden containers (basically an encrypted container within an encrypted container that people shouldn't be able to see) which gives a person plausible deniability when coerced to divulge an encryption password either by physical threats/torture or a court order.

I would even argue that TrueCrypt's file/folder encryption is much superior to EFS since EFS is only tied to a user account (as far as I know - once the account is compromised, the EFS contents can be read)... and Windows user accounts are relatively easy to dump and crack (given that they are one of the most common targets of password cracking). Someone please correct me if I'm wrong.

 

[PrincessFrosty]

I believe Savatar means TrueCrypt in his 2nd paragraph, not BitLocker?

Windows account are indeed fairly easy to crack, if you have LM passwords enabled (default in windows version prior to Vista) then a password of any complexity or length can be broken in a few minutes.

NTLM the successor used in Vista onwards is also weak and can be attacked with rainbow tables, you can grab passwords of any complexity up to length 8, in a few hours. Although 9 onward start needing real investments of cash to break in any reasonable time frame.

If you're relying on a windows password under NTLM you better make sure it's at least 12 characters long and uses characters from every character set (upper, lower, numeric, special) for a half decent chance of keeping it safe.

 

[mikeymikec]

@ PrincessFrosty
Re: NTLM brute forcing - isn't what you're saying only applicable in a network + Windows file sharing environment?

@ TechKnowledge

First of all, you need to decide what you're trying to protect your data against.

For example, for home users I generally recommend against Windows passwords unless the main concern is someone (say a family member) using their computer, ie. guarding against surreptitious access by someone who doesn't have particularly malicious intent. Against non-surreptitious access, the Windows password provides very little protection. One can take a hard disk out of the machine and access the files without any trouble at all, or boot an alternate OS and reset the Windows password quickly and easily. So say if a burglar wants your computer, they would have to be an utter idiot not to have some way to circumvent this protection. I would liken it to putting a cable tie around the computer chassis and then regarding the machine as secure.

Against encryption, if data access is the goal, duping the user into installing say a keylogger or connecting a dodgy hardware device would be the easiest way forward IMO.

Theft is probably the biggest blind-sider to computer security.

I wonder whether I'll be advising customers to use TrueCrypt to encrypt their password storage. I'm hearing more stories these days about passwords being targeted through the physical approach.

 

[PrincessFrosty]

NTLM is the windows authentication protcol it's used for basic user level accounts as well as corporate network and file sharing, it basically does all windows based authenticating. If you have password protected your windows account then the hash can be pulled from the disk or memory and brute forced, within certain realistic time frames/limits.

*edit*

Just to add to this, the basic premise is that encryption is only as strong as the password used to create the key for the encryption, encryption passwords should always be exceptionally strong.

The reason for this is that not only is NTLM weak vs brute force attack, but most encryption for real time use is designed to be as fast and efficient as possible, which means brute force attack against the encryption keys is also fast/efficient, and with modern computers getting exponentially faster we're getting the capability to brute rather complex passwords in realistic time frames.

So this isn't something that's specific to NTLM, if you had a weak password and you're using truecrypt you'd be equally as stuffed, always pick exceptionally strong passwords for any encryption, or any passwords anywhere really.

Currently the tinfoil hatters will recommend 20 characters being enough, but realistically unless your adversary has extended access to super computer clusters, 12 characters is probably enough. (no patterns, words, and use large charsets)

 

[Savatar]

I believe Savatar means TrueCrypt in his 2nd paragraph, not BitLocker?
....

Yes, sorry, I meant TrueCrypt there. I'll edit the post to fix that.

 

[Savatar]

NTLM is the windows authentication protcol it's used for basic user level accounts as well as corporate network and file sharing, it basically does all windows based authenticating. If you have password protected your windows account then the hash can be pulled from the disk or memory and brute forced, within certain realistic time frames/limits.

And I might add that dumping the hashes is not very hard (though some virus scanners do a decent job at blocking some of the more popular methods to do this, but again, if the user's an admin then a virus scanner won't be very effective)... most user accounts have admin access, so you should assume they can get at everyone's hash who has logged on to the local environment.

 

[PrincessFrosty]

And I might add that dumping the hashes are not very hard (though some virus scanners do a decent job at blocking some of the more popular methods to do this, but again, if the user's an admin then a virus scanner won't be very effective)... most user accounts have admin access, so you should assume they can get at everyone's hash who has logged on to the local environment.

Yep, a lot of systems, especially older OS's you can simply plug in a USB key with autorun enabled and without touching the input device autorun an app that pulls the keys from memory/disk, newer OS's are better at stopping this and anti-virus can help as well. Remember though anti-virus largely work off definitions, so custom written apps may not be caught.

HOWEVER if your adversary has physical access then it's more or less game over, they can simply plug in a USB, floppy or CD which has boot sector, boot off a custom OS and run their own apps to read the disk and dump the hashes which is nice and passive.

Some tools do the opposite, they can write values back into the SAM database on the disk, of hashes for known passwords. Once you've done that you've essentially forced the password on the box to be whatever you want. Using this method you can reset the local admin password on that box (including re-enabling any disabled local admin accounts) and once you're admin and can boot into the OS you can disable anti-virus and grab the hashes.

Or at the very, very least you can pop the case and yank the drive and take it with you, or whatever, clone/mirror it, replace it.

Also for any admins out there, it's worth noting that the PCs local SAM database by default holds hashes for all users even ones on the domain, if a domain controller is active and can be reached then auth attempts are always pinged there and checked, but if that's offline (for example someone takes their corporate laptop home with them) then windows queries the local SAM database.

The upshot of this is that all users who have ever logged into that machine will have NTLM hashes stored on the machine, and you've almost certainly used admin creds on the box at some point, if nothing else just to join the domain in the first place.

Tips for sys-ads, I believe you can force disable local creds caching and rely solely on the domain controller, you can also force-disable LM hashes across a network using group policy, both worth doing. Min password requirements should be a min of 9 characters, that will stop most brute force attacks including rainbow tables. I believe switching to Kerberos auth is good practice to help increase security. Exercise caution as some of these changes have potential drawbacks for compatibility and usability.

 

[Savatar]

...
HOWEVER if your adversary has physical access then it's more or less game over, they can simply plug in a USB, floppy or CD which has boot sector, boot off a custom OS and run their own apps to read the disk and dump the hashes which is nice and passive.
....

Very nice post... I just wanted to add that BitLocker (or any drive encryption), as was discussed here, does a pretty good job at stopping this method of booting from a CD or USB to dump the hashes. You won't be able to read the drive contents (at least not easily). While most regular users don't use drive encryption, a lot of companies do.

 

[PrincessFrosty]

Any full disk encryption will indeed stop you from simply reading the hard drive when the machine is off. However this requires a pre-boot password to be used in order to boot the machine and may not be practical for some deployments.

You also have the issue that while a machine is actually running with full disk encryption it might be vulnerable for other reasons, the encryption keys need to reside in memory to encrypt/decrypt on the fly so any vulnerabilities in the OS could lead to attack vectors to acquire the keys.

Despite this encryption (FDE) is definitely one of the better security mechanism when implemented well, I use it on my personal laptop so if someone steals it they literally cannot read anything without knowing my pre-boot password, that keeps the all the data safe including any other passwords or password hashes stored on the machine (NTLM, browser saved pw's etc)

 

[Mushkins]

Tips for sys-ads, I believe you can force disable local creds caching and rely solely on the domain controller, you can also force-disable LM hashes across a network using group policy, both worth doing. Min password requirements should be a min of 9 characters, that will stop most brute force attacks including rainbow tables. I believe switching to Kerberos auth is good practice to help increase security. Exercise caution as some of these changes have potential drawbacks for compatibility and usability.

Your last sentence is probably the most important part of that statement. Turning off local caching of domain credentials/profiles *is* more secure in practice, but this is definitely where you need to start weighing your own use-case against "do I need moar security!!!?" If someone steals a PC and tries to get those credentials at home, or knows credentials and tries to log in, great. They're stopped and you can sleep easy. If your DC goes down/stops responding and you cant log into your workstation to use your admin tools to help you troubleshoot, get ready for a lot of hair pulling frustration, especially if it's a DC in a remote site and you need to RDP into a workstation on their local network to help you test. The risk of this kind of password attack on a business desktop is less "cleaning people stealing a desktop" and more "malicious corporate espionage" levels of risk, whereas the risk of that DC eventually giving you a hard time over something is considerably higher.

For lets say, FBI.gov? Turn that cache off. For your local small business? You're probably better off leaving it on.

 

[PrincessFrosty]

It's a trade off that's for sure, removing LM support can break some backwards compatibility with old software and OS's, domain caching could be a pain if your DC fails or if your users want to take domain enabled laptops and remote devices on/off site. Users may also do stupid things to make 9 char passwords easy to remember (making security weaker), all these things are for each admin to balance up.

Ideally run a backup domain controller and don't rely just on RDP for remove support, that's another discussion though