(I'm trying for a bit more precise answer, particularly with regard to multi-factor authentication, than I received for "Safe way to use a computer that has spyware/keylogger installed?" on SU.)

Let's suppose that I am using a computer that is, for contractual/legal/policy reasons, extensively monitored. For argument's sake, let's assume that anything visible on screen and anything typed are captured (so on-screen keyboards are not secure). The policy allows me to make some personal use of the monitored computer, but not to disable or circumvent the monitoring (so I can't boot the computer into an unmonitored environment), nor to use my own personal computer. Can I use multi-factor authentication or some other method to safely authenticate to a remote service (e.g., to an OpenID provider, an email account, ssh, etc.)? By "safely," I mean in a way that will not permit someone who has access to the monitoring logs to authenticate to the remote service as me.

  • What services are you trying to authenticate with? The obvious advice here is to not authenticate with any service that hold substantial value for you. It also seems like in the threat model there signifficant latency between the time your information is recorded and the time at which it might be used. In that case simply make your password update cycle slightly shorter than the minimum time between data recording and data use. i.e. If your data is recorded on Monday and the earliest an attacker could use the information is Thursday, then update your passwords on Wednesday.
    – this.josh
    Aug 15, 2011 at 18:48

5 Answers 5


Assumptions. As I understand it, you are only concerned about eavesdropping: e.g., that the folks who are monitoring you might record everything you do, and fail to adequately secure those records. You are not worried that they will be actively malicious. For instance, they won't mount a man-in-the-middle attack on you.

Advice. Given this threat model, I think any external authenticator would likely work. For instance, here are three options, any of which should address your needs:

  • Authenticating with a RSA SecurID card would address your concerns, because the SecurID card generates a time-dependent single-use authenticator that is not useful to an attacker if it is subsequently exposed.

  • Another reasonable option would be a smartcard that stores a client cert and private key, and then authenticate using SSL client certs; this is secure, because your private key never leaves the smartcard, and even if the monitors capture the challenge-response values sent over SSL, they won't do any good to an attacker after they are used.

  • You could also use a one-time passwords. The one-time password will be recorded, but even if those records later leak, the password will already have been used and will no longer be valid, so it won't be of any use to an attacker.

  • Another possibility would be to use OpenID to authenticate to the website. That still leaves the question of how to authenticate to your OpenID provider, but if you can find an OpenID provider who will allow users to authenticate themselves by any of the three methods above, then you'd be in great shape -- this would let you log in securely to any website that supports OpenID.

  • Beyond the web, if you want to log in to another computer remotely, you could log in via SSH with public-key authentication, with your private key stored on a smartcard. SSH lets you store your private key on a smartcard, so the folks monitoring you never learn your private key (see also here, here, and here).

Basically, the common theme here is to use crypto (e.g., public-key crypto) instead of passwords for authentication.

The primary challenge is that all of these methods require some kind of support from the site you are logging into. If the site doesn't support one-time passwords, SecurID, client certs, OpenID, or SSH -- if it only supports ordinary password authentication -- you're hosed.

  • I didn't know smart cards could be used for SSH keys (I know little or nothing about smart cards)—is there somewhere you could point me for a general explanation of how this works? (I'd assume that the private key can't just be read from the card, or it wouldn't be particularly secure, so there must be some kind of interaction where the work normally done in the ssh client with the private key is done on the smart card, but my few attempts at finding an explanation haven't yielded much.)
    – Isaac
    Aug 15, 2011 at 5:41
  • If I'm not entirely mistaken the PKCS#11 is a API (considered a standard) by which an operating system can communicate with a hardware token such as smart card or HSM. You may also wish, depending on interest, read the collection of standards from ISO/IEC_7816 which describes smart card functionality. Then again, a simple browse to wikipedia gives a good overview of smart cards. Aug 15, 2011 at 10:24
  • 1
    @Isaac, it's actually pretty simple. When you want to log into a remote server and using public-key authentication, the server sends you a random challenge and asks you to sign it. Normally SSH stores your private key on the filesystem and uses it to sign the challenge, and then sends the signed response to the server. But if you use a smartcard, the private key is stored on the smartcard (not the filesystem), and never leaves the smartcard: the SSH client passes the challenge on to your smartcard, the smartcard signs it and returns it to the client, and the client relays it to the server.
    – D.W.
    Aug 15, 2011 at 20:08

One-time passwords would seem to fit the bill.

Assuming you aren't being filmed, you could have a list printed out.

  • 1
    But if they have such control over the machine, they can just rip the session id out of memory.
    – Jeff
    Aug 14, 2011 at 22:37
  • 1
    @Jeff: That would only allow them access at the same time as me, but not after I'd logged out, right?
    – Isaac
    Aug 14, 2011 at 22:41
  • 1
    @Isaac: yes (assuming the site you're logging into does session management properly). But if they're watching you like a hawk, chances are they can see that you access mail.google.com (either from tls host info or dns) and might have some "malicious" service that then scrapes your cookies. This is a well know issue of "is it possible to create a trusted platform on top of an untrusted one?" so in this case (they control everything on the machine), there really isn't much you can do. This also applies to multi factor auth. Besides, do you even know if the browser is using an intercepting proxy?
    – Jeff
    Aug 15, 2011 at 0:34
  • @Jeff: I don't know any details of the platform. In practice, I'm not particularly worried about direct risks from the owners of the computer, but rather risks coming from not properly securing the collected data, so that a theft of that information would compromised my personal accounts.
    – Isaac
    Aug 15, 2011 at 1:25

What a question!

Ok, so, does multi-factor authentication help? Yes. You can't intercept what's produced on your average bank card-reader without some serious technological wizardry (or a particularly well placed camera). So that login information can only be intercepted; the next time you come to authenticate, the token should be different.

However, and this is a big one. We are assuming (I think) that every communication with this remote service is monitored and that you do not re-authenticate for every given action. In which case, if it is possible to intercept and hijack that session, you will be able to do whatever the service allows.

That might include altering authentication credentials such as the password component. That will certainly lock you out of your remote service next time you come to log in to said remote service, but for repeated access the attacker requires that physical token or the algorithm it uses. We can safely assume they can acquire an appropriate card-reader, but unless they can acquire the card and the PIN, they won't be able to re-authenticate.

So, when the first factor is compromised security then falls on the second factor, the physical number generator or whatever that is, and the security of the session in progress. Your bank probably has this covered too in all likelihood; if I want to make a payment, I also now have to authorise that with my card-reader, because whilst anyone could hijack my session, they won't have access to my physical card (in theory). The same, on my bank, goes for making credential changes. However, it is a different matter for your email account, say.

Let's consider other possible ideas too: the problem with biometric data is that it doesn't change over time. This means, like a password, once it is intercepted, it's valid forever. It's absolutely fine to use in place of a password; in fact, stored appropriately it might even be better, I'm not really sufficiently well read on the topic to say, but it has the same constantness that a password is likely to have.

So, basically, Douglass gets there. One time passwords are a very good choice; in this case, what appear to be one time passwords generated by a card reader based on input from a card protected by a PIN.

It is worth noting, however, that credit card security is an often-discussed topic on Light Blue Touchpaper, the Cambridge University Computer Security Lab, where the implementation security of Chip and PIN frequently comes under fire.

All in all, it's a balance game. To what extent do you think the controllers of this computer are likely to perform such an attack on you? To what extent is their ability to access your email or whatever a concern? There's an equation that says something like severity = likelihood x risk - evaluate concerns in that way and decide whether or not, for your particular circumstances, the risk is one you are willing to take.

  • In practice, I'm not at all worried about what the owners of the computer will do, but rather am worried that the collected information will not be properly secured, so that a theft of that information would compromised my personal accounts. As such, I'm less worried about session hijacking, which (I think) would only work at the same time as I'm using the service. In terms of specific multi-factor authentication, I'm thinking something like one-time passwords via Yubikey or via Axsionics Internet Passport.
    – Isaac
    Aug 14, 2011 at 22:54
  • @Isaac I think it's safe to say the monitoring would have to be fairly intrusive to capture passwords and session information anyway. But I've heard of YubiKey before, if not the internet password, and both would add an extra level of difficulty to any attacker assuming they are supported and available in your remote service of choice. I've picked on the cardreader model as an example, but the YubiKey also provides one time passwords. Provided you can't get at that YubiKey and its algorithm is secure, it (or the other alternative, with the same caveats) really ought to be fine.
    – user2213
    Aug 14, 2011 at 23:00

Out-of-band authentication may fit your situation. Phone authentication is one type (disclaimer: I do this for a living at PhoneFactor). OpenID can be paired with phone authentication to achieve a similar effect; myopenid.com includes phone verification as an option.

  • 1
    MyOpenID/PhoneFactor was definitely one of the things I had in mind (that's been my primary OpenID provider and I've used PhoneFactor with it for a while now).
    – Isaac
    Aug 15, 2011 at 4:53

Google Authenticator. Make sure you set it up out of band (not on your work comp) and have it on your smart phone. This way someone would need access to your smartphone in order to auth as you to whatever service accepts it.


However, if they have full control of the computer, they have access to the cookies used to authenticate your session. You must make sure that the application invalidates the cookies when you logout, or they could be used until they expire.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .