Encryption Questions

[Golgatha]

Does it do any good to use KeePass to store the encryption keys for a TrueCrypt encrypted drive? Or am I wasting my time and I should just give the drives less complex passwords that I'll need to remember?

My logic is this, each TrueCrypt drive I'm encrypting can have it's own unique 16+ character random key in the format of Aa1$, which is much more complex of a password than I'm capable of remembering. The KeePass password is 8+ characters with upper, lower, numbers, and special characters, but part of it could be subject to a dictionary attack, as it is a word + numbers + special characters. I also used the keyfile feature of KeePass for extra security.

Also, any reason to pick one encryption algorithm over another? I'm currently using SHA512.

Finally, is there any issue with putting an encrypted file container on an encrypted drive?

Edit: A little more info. I keep a copy of the KeePass database on the encrypted partition, which is shared out over the network from my home server for ease of use at home. To unlock the partition originally, I use a copy of the database that's stored on on a USB key and the keyfile is kept in a spot that's not obvious on each local machine. I keep a password protected copy of the KeePass database on my Cloud drive, as it's kinda important, but I don't store the keyfile there. The only flaws I have that are know to me are that I do keep a paper copy of all the KeePass passwords in our safety deposit box, for the scenario that I would die unexpectedly, and while the partition is unencrypted, the data could be grabbed over the network from one of my local machines if they were compromised. I think those two are reasonable risks that balance security and the ability for my family to get the data if I'm not around to help retrieve it. Just trying to secure stuff from the "bad guys", but I want my family to be able to access stuff in the event of my untimely demise.

 

[seepy83]

I would probably keep it simple and use a long (25+ character) passphrase that you can easily remember. Complexity and randomness are good, but length is better. Consider using a passphrase similar to this:
"4-10-1997 My son Jason was born"
That has complexity, length, is easy to remember, and (even though all of those words can be found in a dictionary) it will not be cracked by any tools that currently exist in a reasonable amount of time.

 

[smakme7757]

My personal strategy for Key management is to create random passwords between 20 and 40 characters for all encrypted drives. Unless it's a boot drive and in that case i have a special password which I have memorized. Otherwise all other non-boot drives use randomly generated passwords.

I use the same Boot-up password for my boot-drives to protected my password manager. To add in an extra wildcard i have a 2nd password which i use to protect and Ironkey which holds my passwords management data.

So all i have to remember is two passwords. The rest is in the password manager.

1. If the boot password is cracked they can start the system, but not the data drives.
2. If the Ironkey password is cracked they can open access the encrypted password manager
3. If both the Ironkey and boot/manager password is cracked they get it all.
4. If i forget the Ironkey password i loose my password manager, but i can still access my systems.
5. If i loose the boot drive password i loose access to everything.

I'm happy with that level of security. I just remember two decent passwords which i don't use with any online services and it's 100% in my head. I don't use key files as i feel it's too unpredictable.

If i get in an accident and loose my memory i won't know what I've lost anyway, so that all good .


***
You can store whatever you want in an encrypted drive. An encrypted file container is just a chunk of data. The encrypted drive doesn't care if it's encrypted or not.

SHA512 is the hashing algorithm. AES for example would be used to encrypted the data. Unless you're extremely paranoid (NSA developed SHA) then it's fine to use SHA.

 

[Savatar]

As with most things to do with security, it depends on how you balance the sensitive nature of what you are protecting with the convenience of using other programs like KeePass. Either way, at some point, there has to be a relatively secure password that you remember (and that shouldn't be written down).

Regarding your selection of passphrase... the Aa1$***** kind of passwords are ideal when there is a fixed character limit (online email accounts and so on), and that is where KeePass or something similar comes in handy... but mathematically-speaking, with programs without such limits like TC, the longer the better (even if it's not as much gibberish).

 

[PrincessFrosty]

Primary strength of passwords is length, the keyspace goes up very fast with longer passwords making brute force harder. You ought to be aiming for at least 20 characters, ideally it would be random but theres obvious issues with remembering that. By far the best balance is a small phrase, several words that are easy to remember, with some substitutions so that it's not susceptible to a dictionary attack. Don't make 1337 speak substitutions.

You can turn "dontcrackmebro" into "Dont1crack2me3br0$" and that's quite a strong password, very easy to remember, quite long, not open to attack from dictionaries.

Any password management system or system of storing strong passwords locked with simple passwords really just weakens security, security is only as good as the weakest link so if you protect complex passwords with weak one then your security is weak.

*edit*

Regarding what method of encryption you use, remember that different encryption types work at different speeds, use the benchmark tool in truecrypt to see the speed at which your hardware can read/write.

AES is especially good because the newer intel chips come with hardware accelerated AES which truecrypt supports, that significantly lowers the CPU overhead of reading/writing. There's the potential for 100% CPU load and bottlenecked read/writes if you use a combination of slow hardware and CPU heavy encryption.

Lastly, I don't know how keepass works, is that sending keys in plaintext across the network? If so, that's not good.

 

[John Connor]

I have a program that can crack a Truecrypt container. If you just use a simple password like Password1234 and a key file you are good to go. The keyfile can't be cracked. Not that I know of...

 

[Golgatha]

Primary strength of passwords is length, the keyspace goes up very fast with longer passwords making brute force harder. You ought to be aiming for at least 20 characters, ideally it would be random but theres obvious issues with remembering that. By far the best balance is a small phrase, several words that are easy to remember, with some substitutions so that it's not susceptible to a dictionary attack. Don't make 1337 speak substitutions.

You can turn "dontcrackmebro" into "Dont1crack2me3br0$" and that's quite a strong password, very easy to remember, quite long, not open to attack from dictionaries.

Any password management system or system of storing strong passwords locked with simple passwords really just weakens security, security is only as good as the weakest link so if you protect complex passwords with weak one then your security is weak.

*edit*

Regarding what method of encryption you use, remember that different encryption types work at different speeds, use the benchmark tool in truecrypt to see the speed at which your hardware can read/write.

AES is especially good because the newer intel chips come with hardware accelerated AES which truecrypt supports, that significantly lowers the CPU overhead of reading/writing. There's the potential for 100% CPU load and bottlenecked read/writes if you use a combination of slow hardware and CPU heavy encryption.

Lastly, I don't know how keepass works, is that sending keys in plaintext across the network? If so, that's not good.

Thanks for the suggestions and information. KeePass does not send keys in plaintext and the drives can only be mounted on the computer you're logged into. The way I think I've fixed ease of use vs weak password issue, is that I put the KeePass database on the encrypted drive itself. I can use KeePass while the drive is mounted. If the drive gets unmounted, need to reboot, etc, I have a copy of the KeePass database in a 7-zip archive that's AES-SHA256 protected with an obnoxiously long password that has upper, lower, and special characters in it. The database in the 7-Zip archive still has the shorter password and associated keyfile protecting it as well. The keyfile has been removed from the local computers and is only accessible by attaching external storage to it now as well.

I do realize the database is accessible when the drives are mounted and shared over the network, so if someone has physical access to the computers or network, they could pull a copy of the less protected database. That's a risk I'm willing to take and it still leaves the data secured when I'm not at the house and/or the home server is turned off. I also read up about TrueCrypt a bit. As far as I understand, if you're transferring data over the network from one drive to the other, the transmission is encrypted, so at least that stops man-in-the-middle type attacks.

Thanks for all the help from the non-amateur security experts here.

 

[Savatar]

...Thanks for all the help from the non-amateur security experts here.

lol, I'm just a programmer... not formally in IT security or network security, we are just expected to be knowledgeable of certain security practices and how to properly use and implement them for work.

 

[PrincessFrosty]

The keepass database of passwords is encrypted anyway, not sure I see the point in creating a copy of that which has been zipped with another layer of encryption. Is that purely so you can use a weak key for keepass?

I think you've made things too complex and in doing so your security is probably weaker, if you have an obnoxiously strong password on your 7z file then I'm guessing that is written down somewhere?

An attacker is only going to attack the weakest point in the security chain, so ideally you shouldn't really be toying with the idea of weak passwords anywhere.

My password recommendations for creating easy to remember, but strong passwords is your best bet honestly. You ought to get into the practice of strong but easy to remember passwords which are stored no where else but in your head.

Not sure on the truecrypt network transfer you're talking about, to knowledge truecrypt data being trasnferred over the network is sent unencrypted. The encryption for partitions and containers simply protects anything written to the disk, the moment data is pulled off disk into the OS memory (for example before its sent to the network stack) it's decrypted on the fly into readable data.

Unless there's some network file sharing feature of true crypt I'm not aware of, OR unless you're actually transferring a container file. (I don't think you are?)

 

[Chiefcrowe]

I was wondering, what would happen if you somehow lost the ironkey? do you have that info somewhere else too?

My personal strategy for Key management is to create random passwords between 20 and 40 characters for all encrypted drives. Unless it's a boot drive and in that case i have a special password which I have memorized. Otherwise all other non-boot drives use randomly generated passwords.

I use the same Boot-up password for my boot-drives to protected my password manager. To add in an extra wildcard i have a 2nd password which i use to protect and Ironkey which holds my passwords management data.

So all i have to remember is two passwords. The rest is in the password manager.

1. If the boot password is cracked they can start the system, but not the data drives.
2. If the Ironkey password is cracked they can open access the encrypted password manager
3. If both the Ironkey and boot/manager password is cracked they get it all.
4. If i forget the Ironkey password i loose my password manager, but i can still access my systems.
5. If i loose the boot drive password i loose access to everything.

I'm happy with that level of security. I just remember two decent passwords which i don't use with any online services and it's 100% in my head. I don't use key files as i feel it's too unpredictable.

If i get in an accident and loose my memory i won't know what I've lost anyway, so that all good .


***
You can store whatever you want in an encrypted drive. An encrypted file container is just a chunk of data. The encrypted drive doesn't care if it's encrypted or not.

SHA512 is the hashing algorithm. AES for example would be used to encrypted the data. Unless you're extremely paranoid (NSA developed SHA) then it's fine to use SHA.

 

[smakme7757]

I was wondering, what would happen if you somehow lost the ironkey? do you have that info somewhere else too?

I have 3 Ironkeys. I use Lastpass for my internet browsing, but I use the Ironkey with a different password manager for all my hard drive encryption passwords.

The reason I do it that way is that my Lastpass gets updated frequently where as my primary encryption passwords only get updated if I have to format a disk or something like that.

So I have a copy of the database on 3 separate Ironkeys (Device type is irrelevant, but I use an Ironkey) one of which I keep at a separate location, one is on my keychain and the other I keep at home. In addition i keep a copy of the database on my file server which has its own implementation and backup strategy.

It sounds like a lot of work, but once everything is in place it's just "set and forget". If I update the information I just rotate the Ironkeys between on and off site.

The Ironkey I keep on my keychain also has Thunderbird with my email and Firefox, so it's also a tool. I just don't open the password manager on unknown PC's. Granted, someone could use a key logger to grab my Ironkey password, but if someone wants my info that badly I’ll give it to them. I highly doubt I could resist even the most modest of torture techniques: P.

 

[Golgatha]

The keepass database of passwords is encrypted anyway, not sure I see the point in creating a copy of that which has been zipped with another layer of encryption. Is that purely so you can use a weak key for keepass?

I think you've made things too complex and in doing so your security is probably weaker, if you have an obnoxiously strong password on your 7z file then I'm guessing that is written down somewhere?

An attacker is only going to attack the weakest point in the security chain, so ideally you shouldn't really be toying with the idea of weak passwords anywhere.

My password recommendations for creating easy to remember, but strong passwords is your best bet honestly. You ought to get into the practice of strong but easy to remember passwords which are stored no where else but in your head.

Not sure on the truecrypt network transfer you're talking about, to knowledge truecrypt data being trasnferred over the network is sent unencrypted. The encryption for partitions and containers simply protects anything written to the disk, the moment data is pulled off disk into the OS memory (for example before its sent to the network stack) it's decrypted on the fly into readable data.

Unless there's some network file sharing feature of true crypt I'm not aware of, OR unless you're actually transferring a container file. (I don't think you are?)

Thanks for posting and you're right on both counts. I've decided to use a long and easy to remember password on the KeePass database that includes upper, lower, numbers, and special characters. I did write this password down on a printed copy of the KeePass database along with what keyfiles to use. That's in my safety deposit box, with a tamper evident seal on it, for my wife and/or kids to access in the event of my death. Some of the more sensitive files are now in container files so I can access them securely over the network. I used a separate, but still very strong, password to zip up the KeePass database before uploading it to Amazon.com cloud storage as a backup. I also keep this zipped file on some USB keys as well.

 

[PrincessFrosty]

Just of interest how are you implementing secure container files over the network? Are you literally mounting them as a network mapped path?

Or are you copying the container file over the network, mounting it locally, making changes then transferring it back?

I ask because to my knowledge a network mounted disk is going to be transferring data in the clear, remember the data on the disk is encrypted, it's read off via the truecrypt device drivers and from then on it's data in the clear. Reading across the network would be decrypted.

http://www.truecrypt.org/docs/sharing-over-network

Remember it's only secure storage in the strict sense of the word, the moment you pull data off the disk into memory anywhere, it's read in the clear, Truecrypt simply abstracts the disk read/writes so it's transparent to the OS. As far as the OS or any services/processes running on the OS are concerned, while the volume is mounted the data is in the clear and can be read, including any file shares sending that out over the wire (or worse, wireless).

Since you want other people to have access to your passwords in the event of your death the safety deposit box is probably the only good solution for that.

 

[Golgatha]

Just of interest how are you implementing secure container files over the network? Are you literally mounting them as a network mapped path?

Or are you copying the container file over the network, mounting it locally, making changes then transferring it back?

I ask because to my knowledge a network mounted disk is going to be transferring data in the clear, remember the data on the disk is encrypted, it's read off via the truecrypt device drivers and from then on it's data in the clear. Reading across the network would be decrypted.

http://www.truecrypt.org/docs/sharing-over-network

Remember it's only secure storage in the strict sense of the word, the moment you pull data off the disk into memory anywhere, it's read in the clear, Truecrypt simply abstracts the disk read/writes so it's transparent to the OS. As far as the OS or any services/processes running on the OS are concerned, while the volume is mounted the data is in the clear and can be read, including any file shares sending that out over the wire (or worse, wireless).

Since you want other people to have access to your passwords in the event of your death the safety deposit box is probably the only good solution for that.

I'm mounting the file container from a network share on the local computer.

From your link above:

Advantage: Data sent over the network will be encrypted (however, it is still recommended to encrypt it using e.g. SSL, TLS, VPN, or other appropriate technologies to make traffic analysis more difficult and to preserve the integrity of the data).

I realize the data is in the clear when the drives are mounted. I take the normal firewall/MAC filtering/encryption for wireless transfers precautions on my network, and user accounts are specified for the shares. At some point useability has to come before security. The only truly secure data is encrypted with the computer powered off. Not to useful from a practical standpoint if I don't have access to the data.

 

[John Connor]

I never use Lastpass, I commit everything to memory.

 

[PrincessFrosty]

I'm mounting the file container from a network share on the local computer.

From your link above:

I realize the data is in the clear when the drives are mounted. I take the normal firewall/MAC filtering/encryption for wireless transfers precautions on my network, and user accounts are specified for the shares. At some point useability has to come before security. The only truly secure data is encrypted with the computer powered off. Not to useful from a practical standpoint if I don't have access to the data.

If you're mounting locally that's actually OK, it'll basically stop traffic snooping if someone gets on your network.

Careful with wireless networks, is easy as pie to monitor traffic, find MAC addresses that are allowed through firewall rules and spoof them, wireless access points also have security issues a lot of the time, make sure WPS is turned off as that's vulnerable, make sure you've got a good wireless password, as WPA is susceptible to offline dictionary attacks.

Other than that, sounds tight from a data point of view. Trust me I know the balance between security and useability all too well, I'm a sysad for a small business, it can be a nightmare

 

[Golgatha]

If you're mounting locally that's actually OK, it'll basically stop traffic snooping if someone gets on your network.

Careful with wireless networks, is easy as pie to monitor traffic, find MAC addresses that are allowed through firewall rules and spoof them, wireless access points also have security issues a lot of the time, make sure WPS is turned off as that's vulnerable, make sure you've got a good wireless password, as WPA is susceptible to offline dictionary attacks.

Other than that, sounds tight from a data point of view. Trust me I know the balance between security and useability all too well, I'm a sysad for a small business, it can be a nightmare

This is the last of my learning.

First, I changed the router's password to something extremely long and secure. WPS isn't a feature on my router so I'm safe there. The wireless traffic is protected by WPA-PSK 256bit encryption and the Windows HomeGroup sharing also encrypts network data at 128bit, so the wireless encrypted data is re-encrypted. I'm thinking that's pretty safe. On the wired LAN the data is 128bit encrypted and secured by the HomeGroup passphrase. I figure if the "bad guys" have access to my wired LAN on a terminal with the desktop unlocked, I've probably lost the secrecy battle. On the software side, all hard drives are 512bit AES encoded with keyfile + ridiculously long passphrase. If any of my computers are stolen, the data on the drives is pretty well secured.

Thanks again to all for the feedback!