So, PayPal has thrown down the gauntlet on the safe browser war. According to an InfoWorld article, they have declined to add Apple’s Safari browser to their list of safe browsers due to the lack of native anti-phishing technology.
I find it interesting that one of the features they explicitly mention in the InfoWorld article as being a reason behind this is the use (or lack thereof) of the Extended Validation Certificate (EV).
Firefox 2 does not currently support this, however the possibility of having the browser warn you to a possible phishing attack is apparently enough for PayPal. According to the Mozilla developer’s, FireFox 3 will support the EV technology.
Personally I think that the automated protection schemes are great, when they work. One of the first things I did when installing IE7 on my virtual machine was to disable the anti-phishing filter. It is nice to have the automated systems, but there is nothing like a little user education to make the world a safer place. According to a NetworkWorld article:
In one study, three groups of 14 participants each received e-mail messages that included spam and phishing attacks as well as legitimate mail. Two of the groups were presented with educational material about how to prevent being phished; but only one group received the material after having fallen for the phishing e-mails and entered personal information into a fraudulent Web site.
The group that was given educational materials but hadn’t been phished were no better at spotting phishing attacks that the third group, which received no educational materials at all, researchers say.
Besides, who is to be the arbiter of whether or not the site really deserves being declared a phishing site? Sure sometimes it is patently obvious, like when the site is dressed up to look like Citibank, but the URL is really something like “www.citibank.secure.orangecrush.cz”. However, there is no such thing as a perfect system, and we don’t need to train the users to rely completely on the built-in safeguards.
My GPG key expired today, so I renewed it this morning (updated the expiration date). Download it!
I you have read my previous post, GPG Best Practices, you will know that I am a fan of setting expiration dates on my GPG keys.
This has not always been the case. As with many computer users I tend towards the lazy, and if I can keep from having to re-learn a password by never changing it, then I have been guilty of doing so.
Recently, however, I have decided that this is not the best thing to do when it comes to computer security. So while restoring my computer this weekend after a rebuild of the OS to get rid of some cruft that had built up, I decided I needed to add expiration dates to all of my GPG keys.
Now I had already established one for my work e-mail at the time I created the key, but now I needed to go back and add ones to my personal keys. After reading the man page on GPG, it looked pretty easy. Just go into edit mode for the key I wanted to change, the add an expiration date. Simple enough, right? Wrong.
Turns out the what I wanted to do was feasible, just not readily apparent. I didn’t just want to set a date relative to the current date in day, months, weeks, or years. What I wanted to do was use a specific date.
Well, after some diligent searching on Google, I found the following in a post on the gnupg-users list:
>>Is it possible to set an explicit date (e.g. 31 Dec) rather than a >>duration? I suppose I could compute the number of days, but that’s
>>annoying.
Problem solved, mission accomplished.
Like many people who have some concerns over security on the Internet, I have started to use digital signatures for all of my mail sent from my regular e-mail client on my Mac.
While there are several avenues for this, I chose to use GPG. While I know that this means jumping through a couple of extra hoops in configuring my mail client, I decided that it was worth it, because unlike the Thawte Freemail certs, using GPG on my computer also means that I can encrypt files in addition to my mail messages, should I choose to do so.
I am wondering what the thoughts are on best practices when it comes to using GPG.
Here are a couple that I have come up with (learned through hard experience):
1. Backup your keys.
I cannot stress this strongly enough. If for some reason you have a catostrophic computer failure, you will need those backups in order to decrypt your e-mail once you restore your data backup. (You do back your data up, right?)
And when you make those backups, do not rely on just a digital backup. Backup both your public and secret keys in an ASCII-armor file and print the darned thing out. Digital backups are subject to data rot and any number of other technological snafu’s, but I have printed material that is perfectly readable after more than 20 years.
2. Make a revocation certificate.
The GPG mini-howto gives a couple of excellent reasons for doing this:
For instance: the secret key has been stolen or became available to the wrong people, the UID has been changed, the key is not large enough anymore, etc.
Just remember that revoking a key is not reversible.
3. Set an expiration date for your keys.
Just like changing passwords, you should regularly change your GPG keys. Don’t worry about losing track of the data that was encrypted with a key that has expired. You’ll still be able to open that data, it just means that someone won’t be able to encrypt with the old key unless they ignore the warnings about it being expired.
What this also means is that you should hang on to the expired keys, since you might need them to access some older encrypted files. (See best practice number 1)
4. Add commentary to your keys.
If you are like most heavy computer users, you have more than one e-mail address. And if you create a GPG key for each one of those, it would help to keep things orderly if you commented on the individual keys.
For example, the key I use for my work e-mail has a comment of:
Work Address
So, do you have anymore best practices?