The paranoid #! Security Guide | Hacker News Reader

The paranoid #! Security Guide

crunchbang.org

164 pointslampe351 comments

TrueCrypt. The most shady piece of security software I have seen. It's 2013 and there is still no public repository and no changelogs are published. Don't you expect the software you will trust all your secrets with to be at least open about these things?

People keep on saying Schneier says it's good, did he actually check each and every line of the source code? Not to mention that I read somewhere that they ban you on their forums if you ask them these questions.

Let's see the ChangeLog:

"Improvements and bug fixes:

Minor improvements and bug fixes (Windows, Mac OS X, and Linux"

Minor improvements and bug fixes :) This is how you write your ChangeLog friends!

LUKS/dmcrypt is an excellent fully open source alternative to Truecrypt.

http://code.google.com/p/cryptsetup/

Exactly; I don't see why people have such a hard-on for TrueCrypt when you get LUKS out of the box on a Debian install. It's a no-brainer.

I can send them to Windows and Mac users. Even non-technical types seem to be able to open transcript volumes.

While blowing my cover a little, here's an anecdote about LUKSfs-encrypted drives:

I was arrested sometime in early 2011 (let out after 7 hours without charges, which was a fun story in itself). In my pocket, they found two USB sticks. one was a Linux Mint LiveUSB. The other USB stick was encrypted via LUKS. The police could have booted of the LiveUSB, and then inserted the second USB to decrypt it. if they had decided to force me to divulge my password, they would have found all sorts of incriminating things to keep me for longer.

However, this did not happen; when inserted in the police's Windows PC's, they merely popped up a "This drive is not formatted. would you like to format it now?" message. Naturally, they clicked "no" and gave me back the stick. I owe a part of my freedom to Microsoft's and my local Police's devotion to the Windows OS.

TL;DR - LUKS not working in Windows OS is a feature, not a bug.

To that I add that I specified that Debian offered LUKS at install; if you're going with whole disk encryption and doing enough in Linux to care about it, you won't care about being able to read that partition in other OSes, especially ones you don't have the source code to.

it doesn't support hidden volumes (deniable).

Anyone had luck compiling this on OSX?

If the NSA has the ability to break into TrueCrypt drives, then they aren't going to tip their hat on the matter, even in the case of child pornographers. They would probably only be willing to let that information out for very high value targets, because in the meantime, people are still using it and they can still get access to it. If people know that the NSA (or whomever) can get into TrueCrypt volumes, then they stop using it.

Do they need to tip their hats, even when dealing with "high value" targets? Once you've found what you're looking for, you could easily find other damning information that could have plausibly come from somewhere else, no?

While possibly true, not every situation will lend itself to easily finding other damning information with a plausible outside source.

Just look at WW2. There were times that the Allies knew things would happen, but couldn't act on them because it would tip their hat to the Germans that there was a leak somewhere (possibly leading them to the knowledge that the Allies had cracked Enigma), and the pay-off wasn't worth the risk.

Oops: s/tip their hat/tip their hand/

There's another implementation for TrueCrypt these days, tc-play, https://github.com/bwalex/tc-play that looks promising.

DragonflyBSD is impressive and is trying to improve on modern OSes (See HAMMER filesystem). I hope tc-play becomes crossplatform.

I've been using tcplay on Debian for about a year now.

Personally, I prefer the Securing Debian Manual http://www.debian.org/doc/manuals/securing-debian-howto/

Nitpick; "shred" is a better alternative to "srm", since "shred" is always installed.

Does shred work with SSD drives?

Does srm? My understanding is that you can't really do this with SSD drives because even writing to the same file, the underlying location of the data may change due to the internal wear-leveling mechanisms. There is no way to guarantee that you are overwriting the same physical 'block' of data on the hardware.

srm and shred are both filesystem and hardware dependent, and are likely not to actually overwrite the original bits on disk for many common setups these days. Never write anything raw to disk that could complicate your life if it were disclosed to the entire world somehow.

This guy references a very very long video about "why you shouldn't use TrueCrypt hidden volumes" - the relevant question and answer is about an hour in (57 mins will do it) - http://www.youtube.com/watch?v=HHoJ9pQ0cn8&t=57m

TLDW: Appelbaum believes it's better to defend your fifth amendment right than to lie (EFF agrees, Assange doesn't). And in areas of zero freedom, it's better to have the ability to give up your password (plausible confession -- my term) than to have the adversary believe that there's a hidden volume they haven't beat out of you yet.

There's more to this long running debate, but that's the gist of Appelbaum's position.

My take: Plausible deniability gives you the option to defend the fifth, lie, or give up your data, but your confession may never be plausible. Which is better depends on the sensitivity of your data and the willingness of your adversary.

> . And in torture friendly areas, it's better to have the option to give up your password and be killed quickly than to have the adversary believe that there's a hidden volume they haven't beat out of you yet.

How will giving up the password ensure there isn't 'another' hidden volume?

how does this change if you're not american (no fifth, presumably)? or entering the uk (where not giving up the password is a crime)?

To call this a "a very very long video about "why you shouldn't use TrueCrypt hidden volumes"" is not accurate and does not do justice to a very interesting talk.

First, Part 1 is only 1 hour and 17 minutes long (though perhaps it felt much longer to you).

Second, while the subject of TrueCrypt comes up a couple of times in the Q&A period, it's not the main subject of the talk. The talk is about privacy, anonymity, surveillance, and what can be done about them.

I highly recommend watching this video, especially for people who might not be up to date on all the latest privacy-enhancing technology or who might not be very aware of how much digital surveillance there is these days. Even if you do know about these things, it's still interesting to hear an intelligent, articulate presentation about them.

> First, Part 1 is only 1 hour and 17 minutes long

There is no such thing IMO as only 1:17 when referring to a presentation/talk. I tune out after about 10 minutes, 15 or so tops (e.g. for the git imerge discussion).

Anything that is so complicated that it requires that much exposition is something that I will read about or probably not find out at all.

I agree - the article refers to it as such (or rather, says "if you want to know why you shouldn't use hidden volumes, watch this", which is crazy - I sat through an hour of obvious stuff for the one argument I wanted to hear! :/

If you're running a web server then "maldet"[1] is a must, maybe in combination with ClamAV (clamscan).

It's insanely useful especially on "shared" web servers; much more so than chkrootkit or rkhunter.

[1] - http://www.rfxn.com/projects/linux-malware-detect/

Interesting talk that was linked to from the guide http://www.youtube.com/watch?v=HHoJ9pQ0cn8

Why people still recommend chkrootkit? It is an old tool that havent't been updated in a long while and wont find any new linux rootkits/malware.

How is rkhunter?

Out of the box it's probably useless but if you spend some time to configure rkhunter it can be a worthwhile help in finding malware. But for anything that goes beyond script-kiddie attempts I'd not count on it.

- It can verify hashes using the package manager.

- It can report use of deleted files. After clearing the false-positives this can help to detect some malware that is only in memory and already deleted on disk

- Support for unhide¹ - This should help against rootkits - but I'm not sure how reliable it is nowadays

1: http://www.unhide-forensics.info/

Is there anything like this guide specific to securing "modern cloud machines" eg. the variety of Amazon AMIs?

I think its very difficult, if not impossible to have "paranoid level" security for a machine that someone else has full physical access. The assumption here is that amazon also have paranoid level security and their employees are 100% honest and will do nothing to compromise your machine.

I am working on securing virtual machines against physical attacks (which yes, does sound impossible). Our approach requires code changes on the hypervisor level, which currently rules outs Amazon but is viable for bare-metal cloud providers. It also requires some specific CPU features and a TPM.

> The assumption here is that Amazon also have paranoid level security and their employees are 100% honest..

Add 100% competent to that too. I expect a bug is much more likely that a dishonest sysadmin or dev.

There are some good notes here, but they're relatively desktop oriented. For the truly paranoid desktop user https://tails.boum.org/ accomplishes much of this out of the box.

Alternatively, there's Whonix (https://whonix.org/wiki/Main_Page). More steps but potentially more secure. Major difference is that whonix runs in a VM (or two), is persisted (though you could use VM snapshots), and the tor proxy setup is safer (thanks to security-by-isolation and tor socks, no app can figure out the host's ip nor connect directly to the net).

Qubes OS is a new xen based OS that takes security by isolation to a new level. Still young but I'm keeping my eye on it.

The article just convinces me of the need for highly tested/developed security focused distros. There are so many ways to screw up.

I was surprised to see that you were the first one to mention Virtual Machines in these comments.

I would use a VM on a "live" system, booted from removable media, to which no data is ever written. (DVD)

But it wouldn't be any Linux distro.

BSD is what I prefer. Take your pick of the available options, NetBSD, OpenBSD, FreeBSD, *BSD.

I was wondering... would using a different keyboard layout like Colemak or Dvorak defeat keyloggers? I mean, what does keyloggers capture, the interrupts of the keyboard or the keystrokes? Would it get the keys pressed on the keyboard even if those translate to different keys on the keyboard layout or they would capture the keys as if using Qwerty, so the passwords captured would be different?

It won't because by the non password text entered I will be able to derive the layout and have good aproximation of the layout used.

Good catch

Even if you only had the text of the password, one of the first things that you'd try if your keylogged password didn't work would be to see if the characters map to a different layout. (There are only so many after all.)

If you want an excuse to try switching to Dvoraks, how about not having the semicolon on the home row?

https://twopointfouristan.wordpress.com/2011/04/17/pwning-pa...

This post linked from TFA is pretty good justification for SecureBoot, even if the protection provided by SB as it's implemented now can be bit questionable.

Would anyone here have any idea why "net.ipv4.tcp_timestamps=0" is recommended as a security enhancement?

From what I've read online, it should be possible to estimate the uptime of your machine with TCP timestamps.

I'm not sure why this would be a problem, maybe an attacker can see that you haven't rebooted to install a kernel update?

Ah, interesting. I think I recall reading that attacks against crypto can be helped by uptime estimates.

Uptime can be used as a source of "randomness" in PRNGs, so knowing that bit of information could clearly be beneficial to an attacker.

Avast doesn't like a png file being served on this site. Specifically:

http:// ompldr.org / vaG5mcQ / sudoaptgetinstallmthrfckr-610x250.png

click at your own risk..

Also, The CryptoParty Handbook: http://www.cryptoparty.in/documentation/handbook

Why do they try to give me a bunch of (ostensibly unsigned) SHA sums over an insecure, unencrypted medium? Surely anyone who could modify the content could also just as easily modify the checksum.

Can't help but think of: http://xkcd.com/538/

sorry

"Now why was this planted in front of me..."

Reply on news.ycombinator.com