Yeah, the above link has to be commended for its awesomeness and its brevity. 8 simple steps (7 for those of us running Linux) to tunnel all Pidgin traffic over an ssh connection. Excellent. And kudos to you, lordm, for the suggestion of using the Pidgin OTR plugin, a most excellent piece of code that can encrypt and authenticate IM traffic.

Definitely bookmark the above page!

Being the curious beings we are, a friend of mine and I immediately started searching for passwords to see just how much Google was indexing. It didn’t turn up much in the way of anything “secret� until we refined our search to just wp-config files (the file that contains the database connection information for WordPress installs).That worked. Since Google Code Search actually indexes the contents of compressed files like ZIP and TARBALL files, we were able to find copies of people’s wp-config files and several contained usernames and passwords.

This leads to a bit of very important advice: if you archive any type of PHP web application for backup/transfer, do not leave the archive file somewhere that Google can index it!

FreeEnigma brings cryptography to webmail, with an ingenious set of free and open browser plug-ins that work with Yahoo, Gmail, and others. The plugins implement a version of GPG (the free/open version of Pretty Good Privacy) and scramble and de-scramble the text in your webmail before you send it and after you receive it, reducing the amount of information that webmail providers have on your communications.

Those who know me know that I am a big proponent of encryption. My reasons are mainly philosophical. Email is normally sent in plain-text, which means anyone between the sender and the recipient can read that email. Add in the fact that our current administration seems to truly believe it is legal to snoop on all communication within and without this country, and you have the possibility for a very bad situation. Encrypting email might make using email a little more difficult, but it is worth it to help enhance one’s privacy.

FreeEnigma is currently doing a roll-out by invitiation. If you are interested, you can sign up for an invite on their website.

Schneier states that the debate is wrongfully categorised as a debate between privacy and security. I agree — it is not privacy versus security, it is privacy versus freedom. When one person’s privacy restricts someone else’s freedom, we have a problem.In the real world, every country has a legal system with a set of rules by which everyone must live. If someone breaks one of those rules, a police force and judicial system exists to prevent them from continuing to do so. In some cases, the rules are unjust, but generally, rules are designed to protect the freedoms of others. Take the police force and judicial system out of the equation, and you end up with anarchy.

That’s what Tor brings to the Internet. If everyone on the Internet used Tor, and no one could figure out where anyone was coming from anymore, the Internet would be a complete anarchy, even though most people would still attempt to continue their normal, honest behavior.

Whatever point Graham was going for, I think he’s 100% wrong. It is not Tor’s fault that some internet services rely on IP addresses for security. They shouldn’t. IP addresses are spoofable as it is. It is up to those internet services to figure out security models. Tor has a legitimate use: provide privacy.

Vu, who is a assistant professor in the Psychology Department at California State University, Long Beach, goes on to say that the average password is easy to crack, but access to biographical data makes guessing that much easier with favorites being birthdays and children’s names. “My colleagues and I use an easily obtained cracking device called LC4 to crack passwords,” she said. “It sources a dictionary to try words and combinations of words. It often cracks a password without knowing anything about the user. My research says that 60 percent of passwords can be cracked within a few hours, and some in less time than that.”

One of my job functions is assisting people with creating/resetting passwords. And I am continually amazed at how poor some people’s passwords are. It would be relatively easy to guess someone’s password just by knowing a little about that person. Know that Frank’s dog’s name is Kemosabe? There’s a fair chance that is his password, too. Know that Judy is a knitting nut? Her password is probably something along the lines of woolyarn or luv2knit.

I once was personally guilty of this same thing, normally using girlfriend’s names. Over the years, though, I’ve gotten much better ’bout this. Thanks to a password vault and constant access to it, I’ve abandoned the idea of creating passwords, and instead use a random password generator. I keep all my passwords in a password safe, and have a super-strong passphrase protecting the password vault. But I’m weird that way. Most people are not going to be.

With TorPark on a USB flash drive, you can bring the power and flexibility of Firefox with you when you travel — and count on Tor to keep your browsing anonymous and secure at the same time.The current TorPark package (1.5.0.2) is available as a 5.6MB self-extracting Windows archive, localized for more than 30 languages. Expand the archive and inside you will find a folder that you can copy directly onto any rewriteable medium (flash drive, hard drive, etc.). TorPark will not run from a CD, since it must write to a local directory.

The folder contains a portable build of Firefox 1.5, a pre-configured Tor installation, and the Torpark.exe executable. Running Torpark.exe establishes an encrypted circuit to the distributed anonymous network of Tor routers, then launches Firefox. You can test whether TorPark is running by pointing the browser at a Web site like whatismyip.com; the IP address reported by the site should be different in TorPark than it is in a native browser.

So I sat down yesterday and did some digging. And I found a great guide for configuring OpenSSH to use RSA/DSA keys on IBM’s Developer Works Library. The first step is, of course, to generate your keypair. From the article:

% ssh-keygenGenerating public/private rsa1 key pair.
Enter file in which to save the key (/home/drobbins/.ssh/identity): (hit enter)
Enter passphrase (empty for no passphrase): (enter a passphrase)
Enter same passphrase again: (enter it again)
Your identification has been saved in /home/drobbins/.ssh/identity.
Your public key has been saved in /home/drobbins/.ssh/identity.pub.
The key fingerprint is:a4:e7:f2:39:a7:eb:fd:f8:39:f1:f1:7b:fe:48:a1:09
drobbins@localbox

Easy enough, and anyone who has used gpg will have a feel for what’s going on here. A public/private key pair is created in this step. The private key (identity in this example) is created and stored in the user’s .ssh directory. A matching public key (identity.pub) is also created.

The second step of the process is also fairly simple. You have to copy the contents of the public key into the .ssh/authorized_keys on the remote computer. One can use scp or ssh to do this. The beauty of public keys are that they can be freely shared. If someone grabs your public key, there’s not much they can do with it. And they definitely can’t use it to break into the remote machine. The most they can do is copy it onto a machine, then try to get you to log into their computer instead of the remote machine. But that still doesn’t gain them much.

But I digress. After the public key is added to the remote computer’s authorized_keys, ssh will no longer prompt for a password when connecting to the remote computer. It’ll attempt an RSA or DSA authentication, and – assuming you have the correct private key – you’ll be logged on passwordlessly.

Of course, ssh on the local machine will prompt you for the passphrase for your private key every time it is accessed. This is both a good thing (it provides even more security for your private key) and a bad thing (it is a pain in the ass to have to enter a long passphrase over and over and over.

The solution? ssh-agent!

ssh-agent, included with the OpenSSH distribution, is a special program designed to make dealing with RSA and DSA keys both pleasant and secure (see Part 1 of this series for an introduction to RSA and DSA authentication.) ssh-agent, unlike ssh, is a long-running daemon designed for the sole purpose of caching your decrypted private keys.

ssh includes built-in support that allows it to communicate with ssh-agent, allowing ssh to acquire your decrypted private keys without prompting you for a password for every single new connection. With ssh-agent you simply use ssh-add to add your private keys to ssh-agent‘s cache. It’s a one-time process; after using ssh-add, ssh will grab your private key from ssh-agent, rather than bugging you by prompting for a passphrase. (IBM Developer Works Library)

In other words, ssh-agent caches your passphrase: enter it once, and ssh-agent remembers it for the rest of that log-in session. Which is definitely a step in the right direction. But there’s two problems with ssh-agent: first, when you log out of your current session, your cached passphrase is gone. Log back into your local computer and you have to run ssh-agent again. Second, shell scripts and other utilities can’t access the ssh-agent session, so they can’t take advantage of ssh-agent.

So there’s one more piece to add to the puzzle: keychain!

To solve these problems, I wrote a handy bash-based ssh-agent front-end called keychain. What makes keychain special is the fact that it allows you to use a single ssh-agent process per system, not just per login session. This means that you only need to do one ssh-add per private key, period. As we’ll see in a bit, keychain even helps to optimize the ssh-add process by only trying to add private keys that aren’t already in the running ssh-agent‘s cache.

Here’s a run-through of how keychain works. When started from your ~/.bash_profile, it will first check to see whether an ssh-agent is already running. If not, then it will start ssh-agent and record the important SSH_AUTH_SOCK and SSH_AGENT_PID variables in the ~/.ssh-agent file for safe keeping and later use. Here’s the best way to start keychain; like using plain old ssh-agent, we perform the necessary setup inside ~/.bash_profile: (IBM Developer Works Library)

One note: if you use the example in the IBM link, the directory that they give in the last step of the example is incorrect. The newest versions of keychain create the file to source in ~/.keychain; the filename format is %HOSTNAME%-sh. So if your local machine hostname is ubuntu1, you’d want the following line in .bash_profile:

source ~/.keychain/ubuntu1.sh

With that done, you have a fairly-secure solution. You enter your passphrase once, and the combination of keychain and ssh-agent caches that passphrase until you tell it not to. You can log in and out of your remote machine without needing to re-enter your passphrase. Shell scripts can access this to perform passwordless connections. And, as long as your local machine isn’t compromised (e.g. someone gains physical access to your computer), it’s fairly secure.

Oh, there is one last step: turning off password authentication for ssh. This ensures that the only way someone can make an ssh connection to the remote computer is if they have an RSA/DSA key listed in the authorized_keys file on the remote computer. I haven’t done this yet, because it does mean that no one can connect, not even me! I have to make sure I have a way to get to my computers from anywhere before I do this. I’m thinking I’ll probably get a cheap USB key, copy my private key onto it, and then take it with me.

I’ll post an update here once I turn off password authentication.

So you have your tax software do its job, you submit the claim electronically, you print out your forms, and then you have the software save the tax files in case you ever need them. The tax software has done its job, and can then be removed from your computer. All that you need for your own records is the actual tax files the program created.

But there’s one major problem here, something that the tax software doesn’t even try to address: security. These files contain an awful lot of very important personal data. If they were to fall into the wrong hands, you can kiss your identity goodbye. Social security number, address, employer, salary, it’s all right there in one easy-to-handle package. Good for filing your taxes, bad for security.

So what do you do? Personally, I used GnuPG to deal with this mess. GPG isn’t exactly intuitive, nor user-friendly, though, so I’d also recommend adding in kgpg (or whatever it’s Gnome equivalent is) to help with creating/maintaining keys.

But I digress. GnuPG (gpg for short) is an open-source public/private key encryption application. It is the open-source equivalent of Pretty Good Privacy (PGP), and provides encryption that is at least as good as PGPs.

(Note: It is outside of the scope of this article to explain public/private keys.)

The basic idea is this: You create a personal private key that is only ever stored on your computer. This key is protected with a passphrase (think a password on steroids) that you generate. Any file that is encrypted using your public key can then only be decrypted using your private key + your passphrase. Assuming you are careful with your private key and passphrase, this should keep anyone but you from being able to access the file.

So I used kgpg’s Konqueror plugin to encrypt my tax files, then used kgpg to shred (securely delete) the original files (after verifying that I could decrypt the original files, of course). Instantly, the security on my tax files has gone way up. Since I don’t have my gpg passphrase stored anywhere on my computer, I am safe, even if someone steals my computer. (Unless they are either lucky enough to guess my passphrase, which is highly unlikely, or they are willing to dedicate some serious computing horsepower to hacking the passphrase.)

The general steps to follow are:

1. Install gpg
2. Install kgpg
3. If you don’t already have a public/private key pair, choose the Generate Key Pair option in kgpg. Be sure you choose a strong passphrase that you can remember. Single words are bad. Dictionary words are bad. A passphrase like “frankie” is going to be broken into. A better passphrase is “Frankie is 33 next week!” An even better passphrase is “Frankie l0vz Pf dS0tM!” How would you remember that? Say to yourself, “Frankie loves Pink Floyd’s Dark Side of the Moon!” It’s up to you to remember which letters are upper-case and which are replaced with numbers.
4. In Konqueror, right-click on the tax file (e.g. mytaxes.tax). Go to Actions, and you should see an option to Encrypt the file. Clicking this will fire up kgpg’s front-end. The defaults are fine, so you can choose OK.
5. kgpg’s window will close, and you’ll now have a new file, mytaxes.tax.asc (per our example). This is the actual encrypted file.
6. Copy this new file to an easy-to-find location.
7. Navigate to this directory, then try to open the file. You should be presented with kgpg’s window, requesting that you enter your passphrase (unless you are using gpg-agent, which stores your passphrase in memory). Either way, the file should decrypt.
8. Check the now-decrypted file (mytaxes.tax in our example) to make sure it still works.
9. Once you’ve verified everything works, right-click on the original file and choose the Shred option. Shred will ask if you are positive you want to do this. Assuming the above test worked, it is safe to say yes.
10. Make sure that you Shred all decrypted copies of the file. Shred copies random data multiple times over the part of the disk where the file was stored. On most filesystems, this ensures that the file cannot be recovered
11. Save and backup the encrypted file (mytaxes.tax.asc in our example).

Yes, this procedure is a bit involved. But it is more than worth the time it takes.