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.
> Use unique SSH keys for each service (sharing a SSH key on your GitHub/Gitlab account, network router and AWS/Azure instance is a very stupid idea); use ssh-keygen -t rsa -b 4096 to generate a 4096 bit RSA SSH key.
I tried this. Turns out to be a bad idea. SSH will walk through each private key and attempt to authenticate with it in order. That means a lot of bad login attempts which in turn leads to getting locked out. SSH public keys are public for a reason.
What attack is this even preventing - that someone will be able to reverse ssh public keys and get the private? A better approach is to generate a unique key per client so that if you lose access to a device you can remove only its public key.
> Also, you should download the source code, compile it (using a Linux machine) and always look over the source code for rogue functions
So I becoming an Underhanded C Contest judge is the price of admission to using the internet? Can anyone really be expected to do that? Can we blame anyone who gets owned because they didn't?
The solution to that is to use the IdentityFile directive in your ~/.ssh/config with username / hostname expansion.
I use:
Host *
# Disable SSHv1
RSAAuthentication no
# Only use a key explicitely provided by an IdentityFile directive
IdentitiesOnly yes
# %h expands to the hostname, and %u to the username
IdentityFile ~/.ssh/%h/%u.key
This ensures that at most one key is used, and prevents me from having to modify my config every time I generate a key for a new host.
I think the thought is the security practice of compartmentalization. If you lose the private key you use for GitHub, Amazon, DigitalOcean, your home servers, etc... you've effectively given root away.
Now if my laptop is compromised, it doesn't matter if I have one key or ten, I've lost them all. But if there's something heartbleed-esque that allows individual private keys to be stolen when pushing commits to GitHub, I've at least isolated damage to my GitHub account.
> What attack is this even preventing - that someone will be able to reverse ssh public keys and get the private? A better approach is to generate a unique key per client so that if you lose access to a device you can remove only its public key.
I don't think this is about security. Just about privacy.
Some people don't like that they can be identified by their public key. eg (I think) github allows public viewing of a specific users public key, and that allows other services you use with your public key to know your github account etc.
It's not a mainstream privacy concern, but there are some privacy oriented people that worry about it.
I highly recommend using KeepassX as a password manager, secured using a key file and not a password.
I like KeePassX as well, but prefer to unlock using a password. I have a Yubikey programmed to output a 32 random password that I generated and I append to that a 16 character password that's in my head. I keep the Yubikey and the SD card on which I have the password vault separate. The SD card itself is encrypted* and the version of KeePassX I run is on the card and is one I compiled myself.
Not sure I'd be getting additional protection with a key file. But perhaps I am wrong.
*I did that so that someone couldn't just copy the KeePassX database off it when I wasn't looking and run some offline attack against it. The SD card also has a kind of social engineering defence mechanism on it to dissuade the curious from playing with it... I wrote the word INFECTED on it.
I have found my YubiKey quite nice for password sercurity, but I use it in a slightly different way.
I use password-store, which is a git repository of GPG encrypted passwords. While I'm on my main laptop, which has Qubes, I can access passwords using a key stored in my keys vault using Qubes split GPG. Encrypted passwords are synced through SSH to my serwer. On my other computers, I can decrypt passwords with my YubiKey as a gpg smart card. This is probably way overcomplicated, but it works.
I am security conscious but not as conscious as jgc, I am doing the same with the database on the drive and the drive is encrypted. I have a "smaller" password in the head plus a Yubikey password which is appended to my smaller password. For each website I am using a randomly generated password.
What is important is that in my daily life, this is working perfectly well and I do not feel at all the annoyance of the added security against using the same dadada password on all the websites.
I really recommend a head stored + hardware generated password too, this is working wonderfully.
Just had a look at KeePassX, as it looks as though it has a sleeker UX, when compared with KeePass2.
It may be considered a faux pas, but I have come to like the http plugin, for KeePass2, which allows Firefox to reach into my database when I come to sign into an online account.
> 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.
I'm not sure that this actually possible in any reasonable sense. Its not that hard to throw in an obfuscated back door into source code, especially in a complex system (ignoring the build chain and the whole trusting trust thing.)
Even if there are a small number of people who have the time and expertise to audit such systems, it just doesn't scale.
This is overboard and paranoid for the average user. You are almost certainly not a target for your government and probably not a criminal and so don't need to worry about full disk encryption, your google search history, a judge compelling you to unlock your phone, etc.
Most people should just use an adblocker and strong passwords.
It is scary to realize that there is no realistic real-life way to be at least close to keeping information secure. We are just closing holes in a sieve.
If you're seriously concerned that someone will break into your house and remove the screws on your laptop to mess with it, you have problems way beyond what strong passwords and ad blockers can solve.
A lot of people regualary take their laptop through American airport security, where there are multiple reported cases of laptops being messed with.
Regarding hibernation/locking: many people leave laptops unatteded in more risky situations than at home and at the office. As a trivial example, imagine somebody going around a university library, infecting any unatteded laptop with a virus.
I'd rather a fingerprint to lock my phone and always lock on screen blank, than a pin so complex I'll hardly ever lock my phone.
If you're living as some kind of enemy of the state maybe it's just time to stop developing software. And do you really need to holiday in North Korea?
I'm not convinced this localization argument holds so much water. Consider the following:
Case 1: If you're using a search engine not based in the US, and you're not a US person, then the NSA probably can't use any legal tools against you (depending on country). However, the NSA is allowed to use the full range of its capabilities to collect against you (PPD28 notwithstanding). They can infiltrate that service by technical or human means and carry out espionage activity without legal restriction (Title 50/EO12333). Further, they can retain the data unredacted for a long time.*
Case 2: On the other end of the spectrum, if you're a US person and you're using a US-based search engine, surveillance activities against you are far more complex. Warrants, NSLs, and/or other legal paperwork is involved, and there are strict rules on data retention, sharing, and minimization. That's not to say that there isn't surveillance, just that it comes with substantially more overhead. Meanwhile, most of the NSA's technical exploitation approaches are off-limits, and any collection/exploitation activity must be carefully managed.
Case 3: The intermediate case, where you're a non-US person using a US service, is a bit more hairy but still is better than the first case. While the NSA/FBI can utilize a range of legal tools (again, warrants, NSLs, etc) against you, because your data is likely entangled with US-persons data, it must also deal with all the overhead of minimizing and redacting that data (same as case 2). Similarly, the use of technical means against US providers is heavily restricted, so you won't be fighting against the same capabilities as you would be in case 1.
At the end of the day, which do you think is easier for the engineers at NSA: exploiting, entering, and just taking everything (case 1) or filling out a huge amount of paperwork and carefully handling the redacted scraps of data that comes back from the provider eventually (cases 2 and 3)?
I think you can make an argument for either side, but I tend to believe that technical exploitation is easier than legal, for now.
*Caveat here is that this intelligence data is hard[er] to use in US law enforcement activity against you. It's worth noting, however, that NSLs and FISA data are also non-trivial.
I'd recommend this as well. When I did my big migration to LastPass about a year ago (i.e. logged in to every site I ever remember having used and changing the password to a randomly generated one), I thought I was all set. But the site has reminded me at least three times that I registered to alot of BBS-style message boards and maybe only made one or two posts before abandoning them forever and forgetting I ever registered.
Those are concerning, because I'm positive that something I registered for in 2006 and never used again probably used a weak, re-used password.
It was interesting when I found my name there the first time on service I did not even remember using. But I did and I just forgot about it. Luckily at time when I was already using different passwords everywhere.
Originally it was glitter nail polish http://motherboard.vice.com/blog/itll-take-more-than-glitter... ... the idea wasn't just to mark the screws to show if there'd been physical access, but to make a mark that's easily verified but very hard to reproduce, so you also know if your whole laptop has been replaced by the 'evil maid'. You need to photograph it to check!
Use unique SSH keys for each service (sharing a SSH key on your GitHub/Gitlab account, network router and AWS/Azure instance is a very stupid idea)
I don't see how this makes sense. Assuming your private keys all live on the same machine (presumably with 0600 in /.ssh), then if your machine is stolen and your user password compromised, access to one private key is the same as access to all of them.
The sad thing about this and other otherwise good privacy guides is that it can be properly applied only by a small fraction of all people who really need this privacy in their everyday work and life. Especially I like the "look over the source code for rogue functions" part.
What about mobile privacy? which OS? which Phone? which app? the author forgot there is even more privacy info we could lose via mobile with its built in sensors and features.
CyanogenMod without Google apps (gapps) is good enough (for normal life, not a Snowden-style situation, obviously). microG is a great open source replacement for gapps.
If you do want Google apps, at least turn off all the creepy features like Google Now, location history, etc.
I assume everything is hacked/unsecure and any information put on the net will be able to be accessed by all sorts of bad actors.
I laugh when websites etc ask for a phone number to help secure. My first thought is great idea so now when you get hacked you can give up my phone number too!
Internet has been and always will be Mos Eisley spaceport to me.
[+] [-] nikcub|9 years ago|reply
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...
[+] [-] georgehotelling|9 years ago|reply
I tried this. Turns out to be a bad idea. SSH will walk through each private key and attempt to authenticate with it in order. That means a lot of bad login attempts which in turn leads to getting locked out. SSH public keys are public for a reason.
What attack is this even preventing - that someone will be able to reverse ssh public keys and get the private? A better approach is to generate a unique key per client so that if you lose access to a device you can remove only its public key.
> Also, you should download the source code, compile it (using a Linux machine) and always look over the source code for rogue functions
So I becoming an Underhanded C Contest judge is the price of admission to using the internet? Can anyone really be expected to do that? Can we blame anyone who gets owned because they didn't?
[+] [-] radialbrain|9 years ago|reply
[+] [-] Tepix|9 years ago|reply
[+] [-] bjt2n3904|9 years ago|reply
I think the thought is the security practice of compartmentalization. If you lose the private key you use for GitHub, Amazon, DigitalOcean, your home servers, etc... you've effectively given root away.
Now if my laptop is compromised, it doesn't matter if I have one key or ten, I've lost them all. But if there's something heartbleed-esque that allows individual private keys to be stolen when pushing commits to GitHub, I've at least isolated damage to my GitHub account.
[+] [-] antod|9 years ago|reply
I don't think this is about security. Just about privacy.
Some people don't like that they can be identified by their public key. eg (I think) github allows public viewing of a specific users public key, and that allows other services you use with your public key to know your github account etc.
It's not a mainstream privacy concern, but there are some privacy oriented people that worry about it.
[+] [-] jgrahamc|9 years ago|reply
I like KeePassX as well, but prefer to unlock using a password. I have a Yubikey programmed to output a 32 random password that I generated and I append to that a 16 character password that's in my head. I keep the Yubikey and the SD card on which I have the password vault separate. The SD card itself is encrypted* and the version of KeePassX I run is on the card and is one I compiled myself.
Not sure I'd be getting additional protection with a key file. But perhaps I am wrong.
*I did that so that someone couldn't just copy the KeePassX database off it when I wasn't looking and run some offline attack against it. The SD card also has a kind of social engineering defence mechanism on it to dissuade the curious from playing with it... I wrote the word INFECTED on it.
[+] [-] thia|9 years ago|reply
[+] [-] Loic|9 years ago|reply
What is important is that in my daily life, this is working perfectly well and I do not feel at all the annoyance of the added security against using the same dadada password on all the websites.
I really recommend a head stored + hardware generated password too, this is working wonderfully.
[+] [-] mr_sturd|9 years ago|reply
It may be considered a faux pas, but I have come to like the http plugin, for KeePass2, which allows Firefox to reach into my database when I come to sign into an online account.
[+] [-] bestnameever|9 years ago|reply
[+] [-] zeroxfe|9 years ago|reply
I'm not sure that this actually possible in any reasonable sense. Its not that hard to throw in an obfuscated back door into source code, especially in a complex system (ignoring the build chain and the whole trusting trust thing.)
Even if there are a small number of people who have the time and expertise to audit such systems, it just doesn't scale.
[+] [-] globisdead|9 years ago|reply
Privacy Settings: https://addons.mozilla.org/en-US/firefox/addon/privacy-setti...
Decentraleyes: https://addons.mozilla.org/en-US/firefox/addon/decentraleyes...
[+] [-] jeffreyrogers|9 years ago|reply
Most people should just use an adblocker and strong passwords.
[+] [-] amq|9 years ago|reply
[+] [-] pavel_lishin|9 years ago|reply
[+] [-] vladharbuz|9 years ago|reply
[+] [-] wongarsu|9 years ago|reply
Regarding hibernation/locking: many people leave laptops unatteded in more risky situations than at home and at the office. As a trivial example, imagine somebody going around a university library, infecting any unatteded laptop with a virus.
[+] [-] lozf|9 years ago|reply
[+] [-] mavhc|9 years ago|reply
If you're living as some kind of enemy of the state maybe it's just time to stop developing software. And do you really need to holiday in North Korea?
[+] [-] Tepix|9 years ago|reply
If you are privacy conscious you should configure your browser to
a) block 3rd party cookies (all browsers except Safari have them enabled by default, even Firefox)
b) delete all cookies when the browser is closed.
Make it a habit to close the browser every now and then.
[+] [-] peteretep|9 years ago|reply
[+] [-] barking|9 years ago|reply
[+] [-] Tepix|9 years ago|reply
[+] [-] spartango|9 years ago|reply
Case 1: If you're using a search engine not based in the US, and you're not a US person, then the NSA probably can't use any legal tools against you (depending on country). However, the NSA is allowed to use the full range of its capabilities to collect against you (PPD28 notwithstanding). They can infiltrate that service by technical or human means and carry out espionage activity without legal restriction (Title 50/EO12333). Further, they can retain the data unredacted for a long time.*
Case 2: On the other end of the spectrum, if you're a US person and you're using a US-based search engine, surveillance activities against you are far more complex. Warrants, NSLs, and/or other legal paperwork is involved, and there are strict rules on data retention, sharing, and minimization. That's not to say that there isn't surveillance, just that it comes with substantially more overhead. Meanwhile, most of the NSA's technical exploitation approaches are off-limits, and any collection/exploitation activity must be carefully managed.
Case 3: The intermediate case, where you're a non-US person using a US service, is a bit more hairy but still is better than the first case. While the NSA/FBI can utilize a range of legal tools (again, warrants, NSLs, etc) against you, because your data is likely entangled with US-persons data, it must also deal with all the overhead of minimizing and redacting that data (same as case 2). Similarly, the use of technical means against US providers is heavily restricted, so you won't be fighting against the same capabilities as you would be in case 1.
At the end of the day, which do you think is easier for the engineers at NSA: exploiting, entering, and just taking everything (case 1) or filling out a huge amount of paperwork and carefully handling the redacted scraps of data that comes back from the provider eventually (cases 2 and 3)?
I think you can make an argument for either side, but I tend to believe that technical exploitation is easier than legal, for now.
*Caveat here is that this intelligence data is hard[er] to use in US law enforcement activity against you. It's worth noting, however, that NSLs and FISA data are also non-trivial.
[+] [-] lnalx|9 years ago|reply
https://duckduckgo.com/privacy
[+] [-] jsingleton|9 years ago|reply
[+] [-] whamlastxmas|9 years ago|reply
[+] [-] redwards510|9 years ago|reply
[+] [-] xgbi|9 years ago|reply
[+] [-] chinathrow|9 years ago|reply
https://haveibeenpwned.com/
[+] [-] AdmiralAsshat|9 years ago|reply
Those are concerning, because I'm positive that something I registered for in 2006 and never used again probably used a weak, re-used password.
[+] [-] weavie|9 years ago|reply
[+] [-] czechdeveloper|9 years ago|reply
[+] [-] libeclipse|9 years ago|reply
[+] [-] bazzargh|9 years ago|reply
The actual bit in the 30c3 talk where this was discussed is here: https://www.youtube.com/watch?v=KV4XnvE2p34#t=54m24s
[+] [-] crummy|9 years ago|reply
[+] [-] tillinghast|9 years ago|reply
[+] [-] msh|9 years ago|reply
https://www.wired.com/2013/12/better-data-security-nail-poli...
[+] [-] ybroze|9 years ago|reply
I don't see how this makes sense. Assuming your private keys all live on the same machine (presumably with 0600 in /.ssh), then if your machine is stolen and your user password compromised, access to one private key is the same as access to all of them.
[+] [-] Tepix|9 years ago|reply
[+] [-] acqq|9 years ago|reply
Just imagine that somebody can request from you the ssh key to just one of the services you access. Then he gets the access to all of them.
[+] [-] deanclatworthy|9 years ago|reply
[1] https://wiki.mozilla.org/Security/Guidelines/OpenSSH#Key_gen...
[+] [-] ComodoHacker|9 years ago|reply
[+] [-] veeragoni|9 years ago|reply
[+] [-] raldu|9 years ago|reply
[+] [-] dandelion_lover|9 years ago|reply
[+] [-] floatboth|9 years ago|reply
If you do want Google apps, at least turn off all the creepy features like Google Now, location history, etc.
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] Mendenhall|9 years ago|reply
I laugh when websites etc ask for a phone number to help secure. My first thought is great idea so now when you get hacked you can give up my phone number too!
Internet has been and always will be Mos Eisley spaceport to me.