Comment by nikcub | Hacker News Reader

Comment by nikcub | Hacker News Reader

Parent Full thread

Distilling tips down for regular users who don't use SSH or are intimidated by compiling KeePassX for Linux themselves, my tips would be:

1. Use a user-friendly password manager like Dashlane or 1password with a long unique password and a second factor (that isn't SMS based). Password re-use is the #1 way accounts are being compromised at the moment and there are now good password managers that are easy to use with a low barrier to entry

2. Use an extensive ad blocker like uBlock Origin and use multiple profiles in your browser to separate your serious accounts like webmail and banking from general web browsing. The other common way of being exploited is drive-by malware and web-based exploits. A combination of blocking third-party content and separating your browsing profiles will prevent a lot of it. Don't feel guilty about blocking ads - most publishers are extremely negligent with what they allow on their sites via ad networks. Bonus: switch to Chromium[0] (firefox isn't sandboxed and exploits are too common) (but alert yourself to Chromium updates with an IFTTT of the release blog to <pick your notification method>) or alternatively remove Google, Flash, Java etc.

3. Get a VPN subscription and set it up on your laptop & mobile devices. Seriously, don't use open WiFi networks or shared networks without wrapping your connections in encryption. sslstrip is extremely effective and many apps either don't verify/authenticate SSL connections or don't pin certificates. IVPN, PIA, the Sophos VPN product - take a pick.

4. Most home routers are super shit and full of holes. Upgrade to a router that supports open firmware and pick one of openwrt, dd-wrt, monowall, pfsense etc. bonus: run an UTM like Untangled (commercial) or Sophos (free up to 50 CALs iirc)

5. Encrypt your stuff - VeraCrypt is a decent TrueCrypt fork but most operating systems now have support for volume encryption - your local disk, USB sticks[1], or a file-based volume. Backups should be to encrypted media

6. Be anonymous - create a disposable email with a fake name to signup to services with. even better sinkhole a random domain name you register. No service outside of banking, insurance, health, etc. really need to know your actual identity details.

[0] https://download-chromium.appspot.com/

[1] http://www.theinstructional.com/guides/encrypt-an-external-d...

Your comment is the first time I've ever read someone recommending a browser over Firefox (when discussing security and privacy). I find it even more surprising because you're recommending possibly highly unstable Chrome/Chromium releases. I'd like to hear more from you and the HN community on this topic.

Firefox seems to be the only browser in which one can maintain privacy and security (e.g. all the privacy tweaks from privacytools.io). Chrome doesn't allow for most of the tweaks, for example WebRTC can't be disabled.

not to mention, many Chrome extensions are completely compromised by adware/malware and sniff your traffic. The only one I trust is uBlock Origin. Firefox addons have somehow managed to avoid this fate. Also, Firefox has the best security addon, NoScript.

Don't forget Policeman and uMatrix for alternative content and script blockers.

By the way, if one were already using uMatrix and NoScript, what benefit would Policeman provide?

Might I also add, Random Agent Spoofer, Decentraleyes, and Web of Trust

FWIW, uMatrix includes randomized user agent spoofing.

It doesn't appear to work properly. I read a thread on Gorhill's Github page and the whole thing seemed really convoluted. I activated the function but when I tested it my UA wasn't spoofed. Also, the list from which to choose/randomly assign is pretty short, though I think Gorhill made it so by design.

Chromium for security - for privacy it isn't great because aside from the WebRTC issue[0] it also doesn't respect proxy settings. You need to run it in a VM in an isolating proxy setup to avoid the privacy issues.

For privacy the Tor browser - but even then only in a VM because of the prevalence of exploits. Regular Firefox will just get you fingerprinted in any case.

> unstable Chrome/Chromium releases

The build site I linked to lets you switch between trunk/stable

[0] if you know what you're doing you can change the WebRTC route settings with this extension https://chrome.google.com/webstore/detail/webrtc-leak-preven...

For my own edification, can you elaborate on where/how Chromium beats Firefox on security.

The main difference is architectural. Chrome is sandboxed while Firefox isn't. There is an effort to re-architect Firefox now:

https://wiki.mozilla.org/Security/Sandbox

The second difference and a large advantage Google has is the security team they've put together to find and fix bugs. Google between project zero and engineering are probably the best team in the world. Firefox don't really have an equivalent.

Then there is the legacy code that Firefox is built on and the problems that had lead to. In Chrome a successful exploit requires the combination of 5-6 diff bugs/exploits to bypass all the controls and sandboxes, while in FF many straight forward bugs become exploits.

This is most reflected in two places: First the pwn2own contest where FF does poorly[0] and second in the price of 0day between Firefox and Chrome. The Chrome exploit price has never been less than $100k and at the moment $1M+ is being turned down, while OTOH Firefox started at $5-10k and at the moment is $25-30k and are common (common in a browser exploit sense).

The idea situation would be a Chromium fork that is built with the Firefox UI / extensions / settings / profiles etc. built on top of it. I've wanted to build this project for a long time and have a privacy/security specific browser but have never had the chance to do it. I hope at some point somebody does - it's really complicated today to recommend both a secure and private browser.

[0] http://www.extremetech.com/computing/178587-firefox-is-still...

Thanks

Curious, who is "compiling KeePassX for Linux themselves" when it's in the Ubuntu and Debian repos? I haven't checked Arch or other distros but KeePassX is a widely used and active project, and I suspect it is available in many package managers. I wasn't aware that people were having to compile it from source (and I agree this would be more intimidating to new users).

> Curious, who is "compiling KeePassX for Linux themselves" when it's in the Ubuntu and Debian repos?

It's in the OP:

"I highly recommend using KeepassX as a password manager, secured using a key file and not a password. Also, you should download the source code, compile it (using a Linux machine) and always look over the source code for rogue functions, you CANNOT afford a vulnerability inside the password manager."

Thanks, I saw that but was hoping people would not actually bother - that's deep into 'tinfoil-hat' territory. If you are already running a Linux distro and trusting the repos for OS updates, it isn't a big stretch to assume their build of the password manager is exactly as safe as the OS updates, and trusting one but not the other is pure folly.

KeypassX 2.0 was in alpha for years (though I never noticed a bug). I don't think it was available in distribution packages until quite recently.

That being said, I'm decent with C++, and yet auditing its code is a little daunting.

This is also exactly my intuition here, but I'm hoping for others to comment here as well.

> always look over the source code for rogue functions

I don't really understand the reasoning behind that - so rather than trusting a proven OS and its packages with lots of eyes on the critical code, I should rather read the code of a cryptographic product and then make a decision based on that? Common advice is not to write crypto code yourself, but reading it and deciding that there might be a backdoor based on gut feeling is right? And having identified some stuff I don't understand, then decide for another program that is goofy but easier to read, and compromise security?

It's more about looking over the source code of the KeepassX app and just that (not all applications you use, of course we have to trust some of them), the code changes are (when there are changes) ~10 lines a month, not a huge amount to check.

What about all its dependencies? What if someone made some unsuspicious changes in a UI library that it uses that have a side effect on the security of KeepassX?

https://github.com/keepassx/keepassx If libgcrypt, QT, zlib get compromised I guess it's game over, but it's a long way to go, it will get noticed.

But that's the same argument that I was making about KeepassX itself before. So if I'm trusting for the dependencies to get watched well for not being compromised, why then look into KeepassX itself, wouldn't that apply for the app itself as well?

Because KeepassX is way less used (and its source code checked) than ... QT for example, so rogue functions added into KeepassX will be have less visibility than one added into zlib.

Ok, fair enough. Sorry, didn't mean to troll, was just curious. Still sounds like bad advice for the majority of users who can't really make that call, but for those who can it's consistent.

Don't worry about it :) Not all the steps are mandatory and not all are suited for the majority of Internet users. Everybody picks a base and starts from there.

When it comes to security, I usually worry about people creating complexity that scares people away, and therefore weaken the overall security of all. Over-complex and annoying password procedures are one everyday example that force many people to just go for some stupid password that follows the rules but is easy to crack.

So if there are rules to improve the privacy of users, I would worry about making it look to complex or extreme. I suspect rather than picking some parts that work for them they will go "ok this i can do, this I can do, and .. wait compile it myself and read the source?! - ok, I'll stick to post it notes".

Why is it a good idea to use a key file instead of a password? Any malware I catch could use the key file to access all my passwords or is there something I'm not understanding?

I'd recommend both, keepass supports that. Keepass supports using a secure desktop to prevent keyloggers[1], but you never know with some of the usb keyboard exploits[2], and good old fashioned looking over your shoulder. While keepass has protection against dictionary attacks[3], why not use a keyfile? you can put it on a flash drive, and now noone can access your passwords without that usb key. (obviously make sure you have multiple copies of your keyfile :)

1. http://keepass.info/help/base/security.html#secdesktop 2. http://arstechnica.com/security/2014/07/this-thumbdrive-hack... 3. http://keepass.info/help/base/security.html#secdictprotect

>why not use a keyfile?

Because you're always just one burglary away from passwordocalypse?

I would personally use a combination of both. If you keep the key file on a USB thumb drive that you only insert when you need to unlock your files I guess it works out well then.

That sounds like a better idea, but I still don't really see the upside as compared to remembering one long passphrase.

I use a combination of password and key file so that I can worry less about someone shoulder surfing or otherwise observing the input of my password.

My password database is stored on a USB key that I carry with me, with a regular copy made and securely stored.

Key file is stored on devices I use, in a directory restricted to my own access and on a drive which is encrypted. An encrypted copy is also stored on the USB key with the password database; this can be decrypted using a GPG, key stored on a yubikey and also carried; if a device can be trusted enough, this is how I move the key file around.

Access to the database requires 3 things rather than two. A long passphrase could be recorded by an observer, who could then take my USB key. The key file ensures that they still do not have all that they need.

The idea is, if the <attacker> doesn't have the key file, it doesn't matter what password they try, they wont get in.

Only got in the Ubuntu repos lately and not everybody uses Debian and derivatives.

1. Honestly I made bad experiences with PW managers. After having a corrupted PW database a couple of times I stopped using them.

2. I do that. In addition I use this: http://winhelp2002.mvps.org/hosts.htm I have a python script that builds a host file from several sources.

4. Most readers here should be able to build their own router with a banana pi and IPfire

I completely agree re: password managers. Lots of options and competition but nobody has yet really, really nailed it.

I eventually got many not-so-technical family members and friends to adopt Dashlane - which is easy to use and provides great support.

> 2. I do that. In addition I use this: http://winhelp2002.mvps.org/hosts.htm

That's a good idea - you can also configure a local bind/dnsmasq/unbound server to block based on these lists with ACL's (sure if you google each you'll find tutorials, like this one: https://github.com/jodrell/unbound-block-hosts)

Some of the better home router distros will also do this at the local network level

> nobody has yet really, really nailed it.

I don't see how you could do better than something like 1Password. What is missing in your opinion?

1Password relies upon a single, strong password for your "vault", which is vulnerable to sniffers and intermittent surveillance.

I don't understand why they don't offer (at least) 2-factor key for the vault.

Also, they support TouchID on iOS devices, very useful. But in the US, at least one case of someone being legally required to unlock via TouchID, whereas offering up a passcode is still debatable.

So at least offer a short PIN-and-TouchID, and support some 2-factor like Googly Authenticator.

They must have at least considered these things. I don't understand any security issues with this. Implementation is work, and perhaps a support hassle for them.

What are the technical reasons?

>single, strong password for your "vault"

This is pretty much the nature of password managers. That password is only ever entered locally. If an attacker can grab local keystrokes, it's game over anyway.

>they don't offer (at least) 2-factor key for the vault

Neither TOTP nor any kind of push/SMS token can be used to secure data at rest. These are mechanisms to authenticate to a server. You could have "2 factor" for data at rest by storing part of the key separately, but there'd be nothing dynamic about it; copying the key material once would be sufficient to use it forever.

LastPass offers 2-factor to authenticate to the LastPass website, but your vault is cached encrypted on the client side, and such a cached copy can be opened using only the master password. (IIRC there is an option to disable this, which works by erasing the cached copy at the end of a session. Hardly bulletproof, and precludes having any sort of backup resilient to the failure of LastPass itself).

Thanks. I must think more about this.

I can understand that TOTP cannot be used for encryption.

But the app is asking for authentication. Zero-knowledge proof game might apply. Of course the local app must have the decrypted key in memory.

I wish we could defend against the Evil Maid...

One defends against the Evil Maid with physical security techniques. And by doing your own cleaning :).

The app is not asking for authentication, it's asking for encryption. Else an attacker could bypass the app's logic and read its data directly.

Open source would be nice. So I can, you know, check it's not dodgy.

> That's a good idea - you can also configure a local bind/dnsmasq/unbound server to block based on these lists with ACL's (...)

Take a look on FreeContributor [1]

[1] https://tbds.github.io/FreeContributor/

Instead of a VPN subscription, I'd recommend a self-managed VPN solution. One can easily fire one up thanks to Streisand (https://github.com/jlund/streisand)

Well, then you depend on your VPS company.

Its important that you dont host any domains on the VPS you run the VPN on.

Security might not be top priority at the VPS provider.

All your requests come from the same IP address (and the VPN provider might very easily give out your private info).

I think a VPN from a reputable provider (like f-secure) is better for most users.

It depends on your goal. For privacy, a self-hosted VPN is a nightmare. To prevent sniffing and/or modification of content, a self-hosted VPN is great (your VPS company is less likely to target VPN traffic than a dedicated VPN provider).

I think a reputable VPN provider offers the better tradeoff, but there are legitimate reasons for self-hosting a VPN.

could you please explain why a self-hosted vpn is a nightmare for privacy? i am running a streisand server and the disk is fully encrypted

With a VPS-self-hosted VPN all your connections to the outside originate from a static, unique, unshared IP, making it trivial to track and correlate your behavior across all protocols. Instead of containable identifiers like cookies, your IP has become a guaranteed unique identifier.

To leverage this, it's fairly easy to detect you're on a self-hosted VPN: your IP is in an IP range assigned to a hosting/colocation provider, is not a TOR proxy (there is a public list of those) and doesn't belong to any remotely popular VPN (easy to enumerate for a little money, lots of lists exist).

In exchange for that you have eliminated your ISP (or public wifi) as a threat but instead added the hosting provider to the list of threads. And for any adversary that stands above the law, the routing infrastructure of your hosting provider is already a valuable target.

thanks. so basically there is no way to hide the addresses i access through my vpn from the provider of my dedicated server? would it help if i used non logging encryped dns server?

Because you're moving the "exit" from your non-anonymous local ISP to your non-anonymous colo provider. If you want to hide your traffic or at least make your adversary work a little to determine who you are, shared VPN endpoints are better.

How is that any different? ISPs don't let just anybody know who the subscriber is at a given IP (though if you do reverse lookups, many ISPs so leak a lot of locality information, so still a good idea to use some VPN instead of no VPN).

My Streisand hosted on AWS looks to the outside like anybody else's Streisand hosted on AWS, doesn't it?

Similarly, my f-secure egress looks like anybody else's f-secure egress, so what's the difference?

I don't really know, I don't use a VPN. Really asking.

ISPs don't let just anybody know who the subscriber is at a given IP

They certainly let law enforcement and intelligence agencies know, often without a warrant.

Please read my comment as if the threat model includes panopticon governments, not common skids running aircrack-ng.

And reputable VPN vendors resist efforts by nation states to procure information about subscribers? I would expect to have to pay a handsome fee for that.

(I'm not saying you're wrong; again I've not really thought about having to thoroughly anonymize my own traffic.)

"Its important that you dont host any domains on the VPS you run the VPN on."

Why is that is I may ask? I have the impression that the great firewall blacks a lot of domains by default and they are allowed/blocked after a review after somebody tries to access them the first time. I may be paranoid but often I try to open an obscure site. It is blocked. I have to use a VPN. A few days later the site can be accessed. Why not use a VPN sever with a nice website that makes it look harmless?

I see three issues:

- You might forget private whois and expose your identity. - There might be issues with the private whois that exposes your identity. - The contents of the website might expose you.

You could set up a box at home to route through.

Not if its your home connection you want to protect.

True, but most of the advice given here seems to be about preventing MITM-type of attacks and general traffic sniffing

> even better sinkhole a random domain name you register

What does this mean? I've tried to figure it out from context, the article, and a quick google search, but It's not clear how dns sinkholing is going to help me stay secure.

Pretty sure he means take a domain you've registered and use it for anonymous e-mail thus making it so you can't use it for anything personal in the future since it can be connected back to your anonymous email.

regarding a secure router, the .cz tld operator cznic (authors of knot dns) are building high-security high-performance opensource hw/sw router (coming in October) https://www.indiegogo.com/projects/turris-omnia-hi-performan... https://www.turris.cz/en/

Adding the URL (or application name), or rather part of it, to a secure password also makes for a good way to not use the same password everywhere, imo. In case of not wanting to use a password manager.

https://support.mozilla.org/en-US/kb/create-secure-passwords...

But it's still easily derivable. If someone buys the LinkedIn dataset and finds that your password is "123456linkedin", the next thing he will try is "123456facebook", "123456googlemail" and "123456bankofamerica". It might help against highly automated attacks that don't look at the actual password string, but anything involving a human hacker will be as bad as the same password reused.

Is it likely that someone is actually going to look at your password in a breach that may contain several million accounts? On top of that, if it even gets cracked (if it was stored and encrypted properly in the first place).

If you're really personally targeted, then I agree with you. But for a casual person it's probably an easier thing to convince them of doing this instead of installing a password manager.

>Password re-use is the #1 way accounts are being compromised at the moment and there are now good password managers that are easy to use with a low barrier to entry

What accounts? At least for financial fraud this is certainly not true, phishing remains #1 by far.

I'd also hazard to guess that botnet logs result in far more hijackings than password reuse.

Actually you're right - it's malware #1 and then password resuse somewhere down the line. The reuse issue was just fresh on my mind because i've been dealing with it the past few days with the MySpace and LinkedIn dumps.

What about smartphones? Should I use my real identity or is that safe?

Safe from who? I think smartphones are some of the least safe things when trying to avoid law enforcement/3 letter organizations. I don't feel they're particularly safe at all really, but I'm sure someone can elaborate more.

Reply on news.ycombinator.com