FreePress Blog

Inspired by this post from Dan that links to a suggestion for keeping your passwords safe when using a computer that isn’t your own, I’ve decided to post on my idea for safe remote access, even though I haven’t actually implemented it yet.

Taking a step back, I should start by explaining the need for such measures. The basic idea is that if you are using a computer that you don’t have complete control over, you have no way of knowing what may have been done to that computer (either by its owner or some third party) in an attempt to grab your passwords.

Basically, I wanted to come up with a method that will allow you to securely use this kind of a system without fear of your passwords being compromised. To lay the ground rules, I think you have to assume the following things about the computer you will be using:

1. It may be logging every keystroke you type (via hardware, software, or both), AND the logging software is able to track which UI element has the focus when each key is pressed.
2. It may be set up to quickly make a hidden copy of anything you insert on a portable media device (such as a USB drive).
3. It may be set up to log the contents of the clipboard for copying pasting.
4. All network traffic may be monitored and/or logged.

Given these constraints, I think there is still a way to use remote systems safely without compromising yourself. Of course, it’s a bit complicated, but I think given the list above it pretty much has to be. Here are the prerequisites:

• A USB drive containing your own copies of SSH and any other remote access software you need (VNC, etc.)
• Network access from the untrusted computer to your own server, running SSH - this could be at your home or your web hosting provider.

Here are the steps involved in the process:

1. Configure your SSH server to require public key authentication only (do not allow password-only logins).
2. From a trusted host (your own computer or server) generate several sets of key pairs on the SSH server, each with their own unique strong passwords. (You could easily write a script to automate most of this process).
3. Store the public keys in one directory on your server, and then write a script that will consolidate them all and use the consolidated output to replace your server’s authorized keys file, giving these keys (and ONLY these keys) permission to login.
4. Now copy the private keys (each password protected with a strongly unique password) to your USB drive, which will also have your copy of the SSH client and any other remote access software you need.
5. Now you are ready to go log in on an untrusted computer. Insert your USB drive and use your own copy of SSH to connect to your server. Choose one of your private keys to use for the connection (and remember which one you chose).
6. To establish the connection, you will have to enter your password for that specific private key file. Yes, you will be giving up this password, as well as the key file itself (since we are assuming that the contents of your USB drive have been copied and your keys have been logged).
7. Immediately upon logging in, you go and delete the corresponding public key (to the private key you just used) from the directory mentioned above and rerun the script that will re-generate your authorized keys list on the server, which will now not include the one you just used to log in.
8. From here you can go about your business. Tunneling VNC through your SSH connection, you could log into your GUI desktop and home and do any copying/pasting on that machine without exposing it to the untrusted one, or do the change focus trick while typing passwords, since the untrusted system would not be able to tell which screen object on your remote system would have the focus (unless they’re doing something really fancy like syncing screen caps with the key log files).
9. Don’t forget that all your keys are still being logged and your local (USB) files copied.

The end result of this is that the most that the compromised system would be able to gather from you would be a set of private key files which would be useless to them without the passwords, and the valid password to only one of those private keys, which you’ve already immediately invalidated on the server so it can never be used again.

Paranoid? Yes, but at least your passwords won’t be getting stolen. Of course, I don’t consider myself an expert on any of this, so I welcome feedback and encourage poking holes in this method, so we can all learn.