Poojan (Wagh) Blog

So, I’m basically making this post so I can share with friends/family. In this post, I will explain what I do for managing passwords, including two-factor authentication (2FA), and give some options for getting 2FA. Before I do that, I will explain how I got to the conclusion on what I am using.

For those that don’t know me, I am not a security expert. You should do your own research (and maybe consult the security experts out there). I could be wrong about some of my conclusions. And more generally, what might work for me might not work for you.

Also, the scope of what I explaining here is only for my personal accounts. My company (and most out there) has an IT policy for work accounts.

You can skip past the Intro, if you don’t need convincing on why reusing passwords is insecure. Also, I put my recommendations right up-front in the Bottom Line section, if you don’t want to read the whole article.

2008-10-01 Update
I’ve been informed by Verisign that you can only have one FOB attached to your PIP account. This is no big deal for me, since my FOB is on my keychain and you can always have a one-time password emailed or SMS’ed to you as a backup.

Personal Identity Portal (PIP) is an OpenID provider. This means that you:

1. Register an account with PIP. You’ll get a URL (i.e. example.pip.verisignalbs.com); that is your OpenID URL.
2. Go to other web sites–called OpenID clients–for example, My Yahoo, most blogs, identi.ca, army.twit.tv, etc. Instead of registering a username and password, tell them to consult your OpenID URL. Instead of giving them a username:password combination, you just tell them your OpenID URL (example.pip.verisignlabs.com).
3. The web site then consults with PIP to see if you are authenticated. This authentication is done in a very secure manner, using cryptography, so that no one can impersonate you. To do this, you are temporarily transferred to PIP’s web site.
4. You select what information (name, location, DOB) that PIP should share with the OpenID client.
5. You are now logged into the OpenID client and can go about your business. The whole time, you only had to remember one password: your PIP password.

OK: big deal. So, I don’t have to remember more than one password. Here’s the cool part: PIP can be set up so that you get a neat FOB (a keychain doohiky). Here’s a picture of mine:

When I hit they grey button, I get a John Nash-like one-time code (only I’m pretty sure I’m not imagining it). This way, no one can log into my account unless they have my key FOB. I can have only one key FOB, and they come in different form factors (including a credit-card size one that fits in your wallet). You have the option of buying them from Paypal for $5 or the cooler looking ones (credit-card size and waterproof FOB) from Verisign for $30-$40.

If you don’t like carrying it around, you can also have PIP SMS or email you a one-time password.

Here’s another cool feature: PIP also has a little javascript bookmarklet that will save passwords for other sites that don’t support OpenID (linkedin, facebook, etc). Now, I don’t use this capability because I have a pretty good solution already (KeePass), but I might someday.

A list of web sites that support OpenID is at http://openid.net/where/.

Finally, a runner-up that I’d use is Yubikey. However, being an OpenID provider isn’t their main thing right now (although they do provide it sort of as a demo/utility), and I already bought the PIP/Paypal FOB. Alternative providers (including one that works with Yubikey) are at http://openid.net/get/.

Steve Gibson and Leo LaPorte’s SecurityNow podcasts have in-depth discussions of all these technologies.

I was a little worried about WordPress login’s, and about whether the data was sent in cleartext. Besides this point, was it possible for snoop on my traffic, steal my session cookie, and then impersonate me? It turns out the answer is yes. So, I wanted to lock down my blog to prevent traffic snooping and to encrypt the login.

This class of problems has been solved. The preferred method to do this would be SSL.

To use SSL, you need two things: a unique IP and an SSL certificate. Dreamhost charges around $4/month for a unique IP. You can get an SSL certificate for around $10/year. I don’t mind paying these charges. However, I have serveral blogs at different domains. I didn’t really want all the blogs to be SSL. However, I did want to protect my logins from being sniffed/hijacked.

Note that there were a couple of ways I was accessing my blog. I use the regular WordPress web interface (which calls for a method to encrypt traffic through FireFox) and I use Winodws Live Writer (WLW). Firefox lets you use either a SOCKS proxy or an HTTP proxy. WLW allows you to specify only an HTTP proxy. However, I found that Privoxy can act as an adaptor, converting HTTP proxy traffic into SOCKS traffic.

I came up with several solutions. In chronological order:

SSH

By far the easiest and best way to get security without paying for SSL is SSH. This has been well-documented elsewhere. You can tunnel your web (http) traffic in SSH. Your traffic then inherits the encryption and authentication features of SSH.
The best way to tunnel SSH is to set up a dynamic tunnel; this is the same as a SOCKS proxy. If you’re using the command-line on UNIX/Linux, this can be done with a:

ssh -D :1080 -N @.dreamhost.com

This will only listen for connections on the current machine. (The machine in which you type the above command). If you want to set up this machine as a secure SOCKS server for other machines to connect to, you type:

ssh -D *:1080 -N @

I did this on my FreeBSD machine once. I can then connect to it from other machines on my network (Windows machines for example).
I use this SSH-based SOCKS proxy in combination with the Firefox Add-On FoxyProxy. FoxyProxy lets you set pattern-based rules to determine whether to send traffic through a proxy (and which proxy).

HTTP-Tunnel

The SSH method works very well from home. Unfortunately, my employer doesn’t allow SSH traffic through its firewall. In fact, the only traffic that is allowed is HTTP traffic, through their own HTTP proxy.
I found a very promising and powerful program called HTTP-Tunnel. This program lets you set up a SOCKS server that translates all your traffic into HTTP requests.
The program is composed of a client (a Perl script running on your machine at work) and a server (which can be a perl script or a PHP script). Since the only access Dreamhost gives is FTP/SSH/telnet/HTTP, I ran the PHP version (which runs as a PHP CGI script). (The perl version listens for traffic on a specific port.)
To get this to work on Windows, I installed CygWin. I tried ActiveState Perl. However, I found the necessary packages for encryption (MCrypt & OpenSSL::RSA::Crypt, available from CPAN) difficult to find & install using ActiveState.
It was difficult to get the parameter sets (& Perl modules) set up correctly for HTTP-Tunnel to work. However, in th end, it did work. I was able to get data from firefox (once again with FoxyProxy) through the tunnel to DreamHost. Note that once I was in DreamHost’s network, I wasn’t as worried. At some level, you have to trust DreamHost not to spy on your traffic. In my case, there’s not a a lot of interesting stuff to look at. I just want unauthorized users getting access to my blog.
The main difficulty with HTTP-Tunnel is that it seems to be unmaintained for quite a while. In addition, I’m not qualified (nor do I have the time) to analyze the code to verify its security (and uncover any vulnerabilities).
One final note: I wasn’t able to use HTTP-Tunnel as a SOCKS server for SSH. (Don’t be confused with using SSH to create a SOCKS tunnel.) What I was trying to do here is run an SSH session which used the SOCKS tunnel (created by HTTP-Tunnel) as a communications channel. I tried both OpenSSH and PuTTY. Both failed because they for some reason, the HTTP-Tunnel program just stalled during SSH key negotiation.

WordPress Plugins

I found two excellent plugins that took care of web logins to WordPress.

Restrict WordPress cookies by IP

One thing about TCP/IP is that due to the 3-way handshake, you cannot spoof an IP. (You can send a SYN packet, but you can’t negotiate a link from a bogus IP address.) So, if we restrict the cookie to come from a specific address (by encoding the IP address in the cookie), we can verify that the person making a request using this cookie is the real person (i.e. has the correct IP address).
In fact, w-shadow wrote a WordPress plug-in that does exactly this. It’s even up-to-date for WordPress 2.6. Note, however, that this plug-in won’t prevent man-in-the-middle attacks. I’ve concluded that such attacks are pretty difficult to to orchestrate, since you need to be upstream from the victim.

Use OpenID

The WP-OpenID plugin allows you to associate a WordPress user with an OpenID account. I have an OpenID provider. Associating with OpenID allows me to login (using SSL) to OpenID first. Then, I automatically get access to my blog account.
Unfortunately, this scheme does nothing to help with hijacking the session. So, it should be used in combination with w-shadow’s plugin.

Encrypt the login

I found another jewel of a plug-in: Semisecure Login Reimagined. This plugin sends a public RSA key to the client (via Javascript). It encrypts (using Javascript in the client) the username/password using this public key. The server (and only the server) can decrypt the username/password.
So, merely logging in does not send your username/password in the clear.

Summary

Obviously none of the above is as good as SSL. Pretty much everything supports SSL (including the HTTP proxy at my work). However, given the cost of SSL (unique IP & certificate), I feel that the WordPress plugins (when I am not at home) and tunneling over SSH (when I am at home) give my username/password & cookies fairly sufficient protection from being sniffed/hijacked.